2011-02-23 10:52:22 +00:00
|
|
|
/*
|
2010-03-21 01:14:04 +00:00
|
|
|
* $Id$
|
2007-12-24 18:27:28 +00:00
|
|
|
*
|
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2007-12-24 18:27:28 +00:00
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2007 Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* Contributor(s): Blender Foundation
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
2011-02-25 14:04:21 +00:00
|
|
|
/** \file blender/windowmanager/intern/wm_event_system.c
|
|
|
|
* \ingroup wm
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include "DNA_listBase.h"
|
|
|
|
#include "DNA_screen_types.h"
|
2.5
Smaller jobs, all in one commit!
- Moved object_do_update out of view3d drawing, into
the event system (currently after notifiers).
Depsgraph calls for setting update flags will have to
keep track of each Screen's needs, so a UI showing only
a Sequencer doesn't do objects.
- Added button in "Properties region" in 3D window to set
or disable 4-split, including the 3 options it has.
(lock, box, clip)
- Restored legacy code for UI, to make things work like
bone rename, autocomplete.
- Node editor now shows Curves widgets again
- Bugfix: composite job increased Viewer user id count
- Bugfix: Node editor, not "Enable nodes" still called
a Job, which didn't do anything
- Various code cleaning, unused vars and prototypes.
2009-02-11 16:54:55 +00:00
|
|
|
#include "DNA_scene_types.h"
|
2007-12-24 18:27:28 +00:00
|
|
|
#include "DNA_windowmanager_types.h"
|
2009-02-08 12:16:35 +00:00
|
|
|
#include "DNA_userdef_types.h"
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
|
|
#include "GHOST_C-api.h"
|
|
|
|
|
|
|
|
#include "BLI_blenlib.h"
|
2011-01-07 18:36:47 +00:00
|
|
|
#include "BLI_utildefines.h"
|
2011-10-14 08:06:59 +00:00
|
|
|
#include "BLI_math.h"
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
#include "BKE_blender.h"
|
2008-12-18 02:56:48 +00:00
|
|
|
#include "BKE_context.h"
|
2.5: added support for setting RNA properties in keymap item,
which will then be set when the operator is called, example:
kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0);
RNA_enum_set(kmi->ptr, "dir", 'h');
kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0);
RNA_enum_set(kmi->ptr, "dir", 'v');
There is a hack I had to do here, since properties are defined
as member of wmOperator, will try to fix later, committing now
so it can be used already.
2008-12-15 13:10:29 +00:00
|
|
|
#include "BKE_idprop.h"
|
2007-12-24 18:27:28 +00:00
|
|
|
#include "BKE_global.h"
|
2009-10-07 21:39:24 +00:00
|
|
|
#include "BKE_main.h"
|
2008-12-29 13:38:08 +00:00
|
|
|
#include "BKE_report.h"
|
2.5
Smaller jobs, all in one commit!
- Moved object_do_update out of view3d drawing, into
the event system (currently after notifiers).
Depsgraph calls for setting update flags will have to
keep track of each Screen's needs, so a UI showing only
a Sequencer doesn't do objects.
- Added button in "Properties region" in 3D window to set
or disable 4-split, including the 3 options it has.
(lock, box, clip)
- Restored legacy code for UI, to make things work like
bone rename, autocomplete.
- Node editor now shows Curves widgets again
- Bugfix: composite job increased Viewer user id count
- Bugfix: Node editor, not "Enable nodes" still called
a Job, which didn't do anything
- Various code cleaning, unused vars and prototypes.
2009-02-11 16:54:55 +00:00
|
|
|
#include "BKE_scene.h"
|
2010-02-07 23:39:44 +00:00
|
|
|
#include "BKE_screen.h"
|
2011-01-07 19:18:31 +00:00
|
|
|
|
2010-02-21 18:01:41 +00:00
|
|
|
#include "BKE_sound.h"
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
#include "ED_fileselect.h"
|
2009-08-19 12:35:40 +00:00
|
|
|
#include "ED_info.h"
|
2008-01-07 18:03:41 +00:00
|
|
|
#include "ED_screen.h"
|
2010-12-23 04:16:31 +00:00
|
|
|
#include "ED_view3d.h"
|
2009-01-31 19:40:40 +00:00
|
|
|
#include "ED_util.h"
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2008-11-21 19:14:38 +00:00
|
|
|
#include "RNA_access.h"
|
|
|
|
|
2008-12-29 13:38:08 +00:00
|
|
|
#include "UI_interface.h"
|
|
|
|
|
2009-12-10 17:41:03 +00:00
|
|
|
#include "PIL_time.h"
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
#include "WM_api.h"
|
|
|
|
#include "WM_types.h"
|
|
|
|
#include "wm.h"
|
|
|
|
#include "wm_window.h"
|
|
|
|
#include "wm_event_system.h"
|
|
|
|
#include "wm_event_types.h"
|
2010-03-22 11:59:36 +00:00
|
|
|
#include "wm_draw.h"
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2011-10-21 08:16:15 +00:00
|
|
|
#ifndef NDEBUG
|
|
|
|
# include "RNA_enum_types.h"
|
|
|
|
#endif
|
|
|
|
|
2010-11-04 12:59:03 +00:00
|
|
|
static int wm_operator_call_internal(bContext *C, wmOperatorType *ot, PointerRNA *properties, ReportList *reports, short context, short poll_only);
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
/* ************ event management ************** */
|
|
|
|
|
2008-01-19 17:54:05 +00:00
|
|
|
void wm_event_add(wmWindow *win, wmEvent *event_to_add)
|
2007-12-24 18:27:28 +00:00
|
|
|
{
|
2011-09-20 17:07:33 +00:00
|
|
|
wmEvent *event= MEM_callocN(sizeof(wmEvent), "wmEvent");
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
*event= *event_to_add;
|
|
|
|
BLI_addtail(&win->queue, event);
|
|
|
|
}
|
|
|
|
|
2009-06-13 20:58:43 +00:00
|
|
|
void wm_event_free(wmEvent *event)
|
2007-12-24 18:27:28 +00:00
|
|
|
{
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
if(event->customdata) {
|
|
|
|
if(event->customdatafree) {
|
|
|
|
/* note: pointer to listbase struct elsewhere */
|
|
|
|
if(event->custom==EVT_DATA_LISTBASE)
|
|
|
|
BLI_freelistN(event->customdata);
|
|
|
|
else
|
|
|
|
MEM_freeN(event->customdata);
|
|
|
|
}
|
|
|
|
}
|
2007-12-24 18:27:28 +00:00
|
|
|
MEM_freeN(event);
|
|
|
|
}
|
|
|
|
|
|
|
|
void wm_event_free_all(wmWindow *win)
|
|
|
|
{
|
|
|
|
wmEvent *event;
|
|
|
|
|
|
|
|
while((event= win->queue.first)) {
|
|
|
|
BLI_remlink(&win->queue, event);
|
|
|
|
wm_event_free(event);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
/* ********************* notifiers, listeners *************** */
|
|
|
|
|
2010-03-14 22:30:57 +00:00
|
|
|
static int wm_test_duplicate_notifier(wmWindowManager *wm, unsigned int type, void *reference)
|
|
|
|
{
|
|
|
|
wmNotifier *note;
|
|
|
|
|
|
|
|
for(note=wm->queue.first; note; note=note->next)
|
|
|
|
if((note->category|note->data|note->subtype|note->action) == type && note->reference == reference)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-12-03 13:44:16 +00:00
|
|
|
/* XXX: in future, which notifiers to send to other windows? */
|
2009-02-21 18:33:09 +00:00
|
|
|
void WM_event_add_notifier(const bContext *C, unsigned int type, void *reference)
|
2008-01-07 18:03:41 +00:00
|
|
|
{
|
|
|
|
wmNotifier *note= MEM_callocN(sizeof(wmNotifier), "notifier");
|
|
|
|
|
2009-01-01 13:15:35 +00:00
|
|
|
note->wm= CTX_wm_manager(C);
|
|
|
|
BLI_addtail(¬e->wm->queue, note);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
note->window= CTX_wm_window(C);
|
2009-01-01 13:15:35 +00:00
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
if(CTX_wm_region(C))
|
|
|
|
note->swinid= CTX_wm_region(C)->swinid;
|
2008-12-27 16:09:56 +00:00
|
|
|
|
|
|
|
note->category= type & NOTE_CATEGORY;
|
|
|
|
note->data= type & NOTE_DATA;
|
|
|
|
note->subtype= type & NOTE_SUBTYPE;
|
|
|
|
note->action= type & NOTE_ACTION;
|
|
|
|
|
|
|
|
note->reference= reference;
|
2008-01-07 18:03:41 +00:00
|
|
|
}
|
|
|
|
|
2009-10-07 21:39:24 +00:00
|
|
|
void WM_main_add_notifier(unsigned int type, void *reference)
|
|
|
|
{
|
|
|
|
Main *bmain= G.main;
|
|
|
|
wmWindowManager *wm= bmain->wm.first;
|
|
|
|
|
2010-03-14 22:30:57 +00:00
|
|
|
if(wm && !wm_test_duplicate_notifier(wm, type, reference)) {
|
2009-10-07 21:39:24 +00:00
|
|
|
wmNotifier *note= MEM_callocN(sizeof(wmNotifier), "notifier");
|
|
|
|
|
|
|
|
note->wm= wm;
|
|
|
|
BLI_addtail(¬e->wm->queue, note);
|
|
|
|
|
|
|
|
note->category= type & NOTE_CATEGORY;
|
|
|
|
note->data= type & NOTE_DATA;
|
|
|
|
note->subtype= type & NOTE_SUBTYPE;
|
|
|
|
note->action= type & NOTE_ACTION;
|
|
|
|
|
|
|
|
note->reference= reference;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
static wmNotifier *wm_notifier_next(wmWindowManager *wm)
|
|
|
|
{
|
|
|
|
wmNotifier *note= wm->queue.first;
|
|
|
|
|
|
|
|
if(note) BLI_remlink(&wm->queue, note);
|
|
|
|
return note;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* called in mainloop */
|
|
|
|
void wm_event_do_notifiers(bContext *C)
|
|
|
|
{
|
2008-12-18 02:56:48 +00:00
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
2009-08-19 12:35:40 +00:00
|
|
|
wmNotifier *note, *next;
|
2008-12-27 17:43:05 +00:00
|
|
|
wmWindow *win;
|
2011-03-11 05:23:56 +00:00
|
|
|
unsigned int win_combine_v3d_datamask= 0;
|
2008-12-27 17:43:05 +00:00
|
|
|
|
2009-01-23 17:42:36 +00:00
|
|
|
if(wm==NULL)
|
|
|
|
return;
|
|
|
|
|
2009-02-07 19:37:29 +00:00
|
|
|
/* cache & catch WM level notifiers, such as frame change, scene/screen set */
|
2008-12-27 17:43:05 +00:00
|
|
|
for(win= wm->windows.first; win; win= win->next) {
|
|
|
|
int do_anim= 0;
|
|
|
|
|
2009-02-07 19:37:29 +00:00
|
|
|
CTX_wm_window_set(C, win);
|
|
|
|
|
2009-08-19 12:35:40 +00:00
|
|
|
for(note= wm->queue.first; note; note= next) {
|
|
|
|
next= note->next;
|
|
|
|
|
2009-02-18 13:29:54 +00:00
|
|
|
if(note->category==NC_WM) {
|
|
|
|
if( ELEM(note->data, ND_FILEREAD, ND_FILESAVE)) {
|
|
|
|
wm->file_saved= 1;
|
|
|
|
wm_window_title(wm, win);
|
|
|
|
}
|
|
|
|
else if(note->data==ND_DATACHANGED)
|
|
|
|
wm_window_title(wm, win);
|
|
|
|
}
|
2009-02-07 19:37:29 +00:00
|
|
|
if(note->window==win) {
|
|
|
|
if(note->category==NC_SCREEN) {
|
2.5: Text Editor back.
There was very little structure in this code, using many globals
and duplicated code. Now it should be better structured. Most
things should work, the main parts that are not back yet are the
python plugins and markers. Notes:
* Blenfont is used for drawing the text, nicely anti-aliased.
* A monospace truetype font was added, since that is needed for
the text editor. It's Bitstream Vera Sans Mono. This is the
default gnome terminal font, but it doesn't fit entirely well
with the other font I think, can be changed easily of course.
* Clipboard copy/cut/paste now always uses the system clipboard,
the code for the own cut buffer was removed.
* The interface buttons should support copy/cut/paste again now
as well.
* WM_clipboard_text_get/WM_clipboard_text_set were added to the
windowmanager code.
* Find panel is now a kind of second header, instead of a panel.
This needs especially a way to start editing the text field
immediately on open still.
* Operators are independent of the actual space when possible,
was a bit of puzzling but got it solved nice with notifiers,
and some lazy init for syntax highlight in the drawing code.
* RNA was created for the text editor space and used for buttons.
* Operators:
* New, Open, Reload, Save, Save As, Make Internal
* Run Script, Refresh Pyconstraints
* Copy, Cut, Paste
* Convert Whitespace, Uncomment, Comment, Indent, Unindent
* Line Break, Insert
* Next Marker, Previous Marker, Clear All Markers, Mark All
* Select Line, Select All
* Jump, Move, Move Select, Delete, Toggle Overwrite
* Scroll, Scroll Bar, Set Cursor, Line Number
* Find and Replace, Find, Replace, Find Set Selected,
Replace Set Selected
* To 3D Object
* Resolve Conflict
2009-02-28 23:33:35 +00:00
|
|
|
if(note->data==ND_SCREENBROWSE) {
|
2009-02-07 19:37:29 +00:00
|
|
|
ED_screen_set(C, note->reference); // XXX hrms, think this over!
|
2009-12-09 10:55:28 +00:00
|
|
|
if(G.f & G_DEBUG)
|
|
|
|
printf("screen set %p\n", note->reference);
|
2.5: Text Editor back.
There was very little structure in this code, using many globals
and duplicated code. Now it should be better structured. Most
things should work, the main parts that are not back yet are the
python plugins and markers. Notes:
* Blenfont is used for drawing the text, nicely anti-aliased.
* A monospace truetype font was added, since that is needed for
the text editor. It's Bitstream Vera Sans Mono. This is the
default gnome terminal font, but it doesn't fit entirely well
with the other font I think, can be changed easily of course.
* Clipboard copy/cut/paste now always uses the system clipboard,
the code for the own cut buffer was removed.
* The interface buttons should support copy/cut/paste again now
as well.
* WM_clipboard_text_get/WM_clipboard_text_set were added to the
windowmanager code.
* Find panel is now a kind of second header, instead of a panel.
This needs especially a way to start editing the text field
immediately on open still.
* Operators are independent of the actual space when possible,
was a bit of puzzling but got it solved nice with notifiers,
and some lazy init for syntax highlight in the drawing code.
* RNA was created for the text editor space and used for buttons.
* Operators:
* New, Open, Reload, Save, Save As, Make Internal
* Run Script, Refresh Pyconstraints
* Copy, Cut, Paste
* Convert Whitespace, Uncomment, Comment, Indent, Unindent
* Line Break, Insert
* Next Marker, Previous Marker, Clear All Markers, Mark All
* Select Line, Select All
* Jump, Move, Move Select, Delete, Toggle Overwrite
* Scroll, Scroll Bar, Set Cursor, Line Number
* Find and Replace, Find, Replace, Find Set Selected,
Replace Set Selected
* To 3D Object
* Resolve Conflict
2009-02-28 23:33:35 +00:00
|
|
|
}
|
2009-08-15 16:43:03 +00:00
|
|
|
else if(note->data==ND_SCREENDELETE) {
|
|
|
|
ED_screen_delete(C, note->reference); // XXX hrms, think this over!
|
2009-12-09 10:55:28 +00:00
|
|
|
if(G.f & G_DEBUG)
|
|
|
|
printf("screen delete %p\n", note->reference);
|
2009-08-15 16:43:03 +00:00
|
|
|
}
|
2009-02-07 19:37:29 +00:00
|
|
|
}
|
2010-01-14 19:53:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if(note->window==win || (note->window == NULL && (note->reference == NULL || note->reference == CTX_data_scene(C)))) {
|
|
|
|
if(note->category==NC_SCENE) {
|
2009-02-08 12:16:35 +00:00
|
|
|
if(note->data==ND_SCENEBROWSE) {
|
|
|
|
ED_screen_set_scene(C, note->reference); // XXX hrms, think this over!
|
2009-12-09 10:55:28 +00:00
|
|
|
if(G.f & G_DEBUG)
|
|
|
|
printf("scene set %p\n", note->reference);
|
2009-02-08 12:16:35 +00:00
|
|
|
}
|
2010-01-14 01:47:25 +00:00
|
|
|
else if(note->data==ND_FRAME)
|
|
|
|
do_anim= 1;
|
|
|
|
|
|
|
|
if(note->action == NA_REMOVED) {
|
2009-08-15 16:43:03 +00:00
|
|
|
ED_screen_delete_scene(C, note->reference); // XXX hrms, think this over!
|
2009-12-09 10:55:28 +00:00
|
|
|
if(G.f & G_DEBUG)
|
|
|
|
printf("scene delete %p\n", note->reference);
|
2009-08-15 16:43:03 +00:00
|
|
|
}
|
2010-01-14 01:47:25 +00:00
|
|
|
|
2009-02-07 19:37:29 +00:00
|
|
|
}
|
|
|
|
}
|
2010-03-12 12:09:06 +00:00
|
|
|
if(ELEM5(note->category, NC_SCENE, NC_OBJECT, NC_GEOM, NC_SCENE, NC_WM)) {
|
2009-08-19 12:35:40 +00:00
|
|
|
ED_info_stats_clear(CTX_data_scene(C));
|
2.5
Notifiers
---------
Various fixes for wrong use of notifiers, and some new notifiers
to make things a bit more clear and consistent, with two notable
changes:
* Geometry changes are now done with NC_GEOM, rather than
NC_OBJECT|ND_GEOM_, so an object does need to be available.
* Space data now use NC_SPACE|ND_SPACE_*, instead of data
notifiers or even NC_WINDOW in some cases. Note that NC_SPACE
should only be used for notifying about changes in space data,
we don't want to go back to allqueue(REDRAW..).
Depsgraph
---------
The dependency graph now has a different flush call:
DAG_object_flush_update(scene, ob, flag)
is replaced by:
DAG_id_flush_update(id, flag)
It still works basically the same, one difference is that it now
also accepts object data (e.g. Mesh), again to avoid requiring an
Object to be available. Other ID types will simply do nothing at
the moment.
Docs
----
I made some guidelines for how/when to do which kinds of updates
and notifiers. I can't specify totally exact how to make these
decisions, but these are basically the guidelines I use. So, new
and updated docs are here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/NotifiersUpdates
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DataNotifiers
2009-09-04 20:51:09 +00:00
|
|
|
WM_event_add_notifier(C, NC_SPACE|ND_SPACE_INFO, NULL);
|
2009-08-19 12:35:40 +00:00
|
|
|
}
|
2008-12-27 17:43:05 +00:00
|
|
|
}
|
|
|
|
if(do_anim) {
|
2010-06-14 15:02:16 +00:00
|
|
|
|
|
|
|
/* XXX, quick frame changes can cause a crash if framechange and rendering
|
|
|
|
* collide (happens on slow scenes), scene_update_for_newframe can be called
|
|
|
|
* twice which can depgraph update the same object at once */
|
|
|
|
if(!G.rendering) {
|
|
|
|
|
|
|
|
/* depsgraph gets called, might send more notifiers */
|
2010-11-02 09:34:32 +00:00
|
|
|
ED_update_for_newframe(CTX_data_main(C), win->screen->scene, win->screen, 1);
|
2010-06-14 15:02:16 +00:00
|
|
|
}
|
2008-12-27 17:43:05 +00:00
|
|
|
}
|
|
|
|
}
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2009-01-04 17:45:54 +00:00
|
|
|
/* the notifiers are sent without context, to keep it clean */
|
2008-12-18 02:56:48 +00:00
|
|
|
while( (note=wm_notifier_next(wm)) ) {
|
|
|
|
for(win= wm->windows.first; win; win= win->next) {
|
2009-02-09 15:50:09 +00:00
|
|
|
|
|
|
|
/* filter out notifiers */
|
|
|
|
if(note->category==NC_SCREEN && note->reference && note->reference!=win->screen);
|
|
|
|
else if(note->category==NC_SCENE && note->reference && note->reference!=win->screen->scene);
|
|
|
|
else {
|
|
|
|
ScrArea *sa;
|
|
|
|
ARegion *ar;
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
|
2009-02-09 15:50:09 +00:00
|
|
|
/* XXX context in notifiers? */
|
|
|
|
CTX_wm_window_set(C, win);
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
|
2009-02-18 13:29:54 +00:00
|
|
|
/* printf("notifier win %d screen %s cat %x\n", win->winid, win->screen->id.name+2, note->category); */
|
2011-03-09 18:42:35 +00:00
|
|
|
ED_screen_do_listen(C, note);
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
|
2009-02-09 15:50:09 +00:00
|
|
|
for(ar=win->screen->regionbase.first; ar; ar= ar->next) {
|
2008-01-07 18:03:41 +00:00
|
|
|
ED_region_do_listen(ar, note);
|
|
|
|
}
|
2009-02-09 15:50:09 +00:00
|
|
|
|
|
|
|
for(sa= win->screen->areabase.first; sa; sa= sa->next) {
|
|
|
|
ED_area_do_listen(sa, note);
|
|
|
|
for(ar=sa->regionbase.first; ar; ar= ar->next) {
|
|
|
|
ED_region_do_listen(ar, note);
|
|
|
|
}
|
|
|
|
}
|
2008-01-07 18:03:41 +00:00
|
|
|
}
|
|
|
|
}
|
2008-12-15 18:09:55 +00:00
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
MEM_freeN(note);
|
2009-01-04 17:45:54 +00:00
|
|
|
}
|
|
|
|
|
2011-03-11 05:23:56 +00:00
|
|
|
/* combine datamasks so 1 win doesn't disable UV's in another [#26448] */
|
|
|
|
for(win= wm->windows.first; win; win= win->next) {
|
|
|
|
win_combine_v3d_datamask |= ED_viewedit_datamask(win->screen);
|
|
|
|
}
|
|
|
|
|
2009-01-04 17:45:54 +00:00
|
|
|
/* cached: editor refresh callbacks now, they get context */
|
|
|
|
for(win= wm->windows.first; win; win= win->next) {
|
|
|
|
ScrArea *sa;
|
2.5
Smaller jobs, all in one commit!
- Moved object_do_update out of view3d drawing, into
the event system (currently after notifiers).
Depsgraph calls for setting update flags will have to
keep track of each Screen's needs, so a UI showing only
a Sequencer doesn't do objects.
- Added button in "Properties region" in 3D window to set
or disable 4-split, including the 3 options it has.
(lock, box, clip)
- Restored legacy code for UI, to make things work like
bone rename, autocomplete.
- Node editor now shows Curves widgets again
- Bugfix: composite job increased Viewer user id count
- Bugfix: Node editor, not "Enable nodes" still called
a Job, which didn't do anything
- Various code cleaning, unused vars and prototypes.
2009-02-11 16:54:55 +00:00
|
|
|
|
2009-01-06 10:30:34 +00:00
|
|
|
CTX_wm_window_set(C, win);
|
2009-01-04 17:45:54 +00:00
|
|
|
for(sa= win->screen->areabase.first; sa; sa= sa->next) {
|
2009-01-06 10:30:34 +00:00
|
|
|
if(sa->do_refresh) {
|
|
|
|
CTX_wm_area_set(C, sa);
|
2009-01-04 17:45:54 +00:00
|
|
|
ED_area_do_refresh(C, sa);
|
2009-01-06 10:30:34 +00:00
|
|
|
}
|
2009-01-04 17:45:54 +00:00
|
|
|
}
|
2.5
Smaller jobs, all in one commit!
- Moved object_do_update out of view3d drawing, into
the event system (currently after notifiers).
Depsgraph calls for setting update flags will have to
keep track of each Screen's needs, so a UI showing only
a Sequencer doesn't do objects.
- Added button in "Properties region" in 3D window to set
or disable 4-split, including the 3 options it has.
(lock, box, clip)
- Restored legacy code for UI, to make things work like
bone rename, autocomplete.
- Node editor now shows Curves widgets again
- Bugfix: composite job increased Viewer user id count
- Bugfix: Node editor, not "Enable nodes" still called
a Job, which didn't do anything
- Various code cleaning, unused vars and prototypes.
2009-02-11 16:54:55 +00:00
|
|
|
|
2009-12-10 11:08:38 +00:00
|
|
|
/* XXX make lock in future, or separated derivedmesh users in scene */
|
2010-12-23 17:47:06 +00:00
|
|
|
if(!G.rendering) {
|
2009-12-10 11:08:38 +00:00
|
|
|
/* depsgraph & animation: update tagged datablocks */
|
2010-12-23 04:16:31 +00:00
|
|
|
|
|
|
|
/* copied to set's in scene_update_tagged_recursive() */
|
2011-03-11 05:23:56 +00:00
|
|
|
win->screen->scene->customdata_mask= win_combine_v3d_datamask;
|
2010-12-23 04:16:31 +00:00
|
|
|
|
2011-03-13 02:44:25 +00:00
|
|
|
/* XXX, hack so operators can enforce datamasks [#26482], gl render */
|
|
|
|
win->screen->scene->customdata_mask |= win->screen->scene->customdata_mask_modal;
|
|
|
|
|
2010-08-01 12:47:49 +00:00
|
|
|
scene_update_tagged(CTX_data_main(C), win->screen->scene);
|
2010-12-23 17:47:06 +00:00
|
|
|
}
|
2009-01-04 17:45:54 +00:00
|
|
|
}
|
2009-12-08 18:28:09 +00:00
|
|
|
|
2009-01-06 10:30:34 +00:00
|
|
|
CTX_wm_window_set(C, NULL);
|
2008-01-07 18:03:41 +00:00
|
|
|
}
|
|
|
|
|
2010-12-16 18:58:22 +00:00
|
|
|
static int wm_event_always_pass(wmEvent *event)
|
|
|
|
{
|
|
|
|
/* some events we always pass on, to ensure proper communication */
|
|
|
|
return ISTIMER(event->type) || (event->type == WINDEACTIVATE);
|
|
|
|
}
|
|
|
|
|
2010-01-31 23:33:04 +00:00
|
|
|
/* ********************* ui handler ******************* */
|
|
|
|
|
|
|
|
static int wm_handler_ui_call(bContext *C, wmEventHandler *handler, wmEvent *event, int always_pass)
|
|
|
|
{
|
|
|
|
ScrArea *area= CTX_wm_area(C);
|
|
|
|
ARegion *region= CTX_wm_region(C);
|
|
|
|
ARegion *menu= CTX_wm_menu(C);
|
2010-12-16 18:58:22 +00:00
|
|
|
static int do_wheel_ui= 1;
|
|
|
|
int is_wheel= ELEM(event->type, WHEELUPMOUSE, WHEELDOWNMOUSE);
|
2010-01-31 23:33:04 +00:00
|
|
|
int retval;
|
2010-12-16 18:58:22 +00:00
|
|
|
|
2011-06-06 00:48:10 +00:00
|
|
|
/* UI is quite aggressive with swallowing events, like scrollwheel */
|
2010-12-16 18:58:22 +00:00
|
|
|
/* I realize this is not extremely nice code... when UI gets keymaps it can be maybe smarter */
|
|
|
|
if(do_wheel_ui==0) {
|
|
|
|
if(is_wheel)
|
|
|
|
return WM_HANDLER_CONTINUE;
|
|
|
|
else if(wm_event_always_pass(event)==0)
|
|
|
|
do_wheel_ui= 1;
|
|
|
|
}
|
|
|
|
|
2010-01-31 23:33:04 +00:00
|
|
|
/* we set context to where ui handler came from */
|
|
|
|
if(handler->ui_area) CTX_wm_area_set(C, handler->ui_area);
|
|
|
|
if(handler->ui_region) CTX_wm_region_set(C, handler->ui_region);
|
|
|
|
if(handler->ui_menu) CTX_wm_menu_set(C, handler->ui_menu);
|
|
|
|
|
|
|
|
retval= handler->ui_handle(C, event, handler->ui_userdata);
|
|
|
|
|
|
|
|
/* putting back screen context */
|
|
|
|
if((retval != WM_UI_HANDLER_BREAK) || always_pass) {
|
|
|
|
CTX_wm_area_set(C, area);
|
|
|
|
CTX_wm_region_set(C, region);
|
|
|
|
CTX_wm_menu_set(C, menu);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* this special cases is for areas and regions that get removed */
|
|
|
|
CTX_wm_area_set(C, NULL);
|
|
|
|
CTX_wm_region_set(C, NULL);
|
|
|
|
CTX_wm_menu_set(C, NULL);
|
|
|
|
}
|
2010-12-16 18:58:22 +00:00
|
|
|
|
2010-01-31 23:33:04 +00:00
|
|
|
if(retval == WM_UI_HANDLER_BREAK)
|
|
|
|
return WM_HANDLER_BREAK;
|
2010-12-16 18:58:22 +00:00
|
|
|
|
|
|
|
/* event not handled in UI, if wheel then we temporarily disable it */
|
|
|
|
if(is_wheel)
|
|
|
|
do_wheel_ui= 0;
|
|
|
|
|
2010-01-31 23:33:04 +00:00
|
|
|
return WM_HANDLER_CONTINUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void wm_handler_ui_cancel(bContext *C)
|
|
|
|
{
|
|
|
|
wmWindow *win= CTX_wm_window(C);
|
|
|
|
ARegion *ar= CTX_wm_region(C);
|
|
|
|
wmEventHandler *handler, *nexthandler;
|
|
|
|
|
|
|
|
if(!ar)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for(handler= ar->handlers.first; handler; handler= nexthandler) {
|
|
|
|
nexthandler= handler->next;
|
|
|
|
|
|
|
|
if(handler->ui_handle) {
|
|
|
|
wmEvent event= *(win->eventstate);
|
|
|
|
event.type= EVT_BUT_CANCEL;
|
|
|
|
handler->ui_handle(C, &event, handler->ui_userdata);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
/* ********************* operators ******************* */
|
|
|
|
|
2009-09-18 13:02:20 +00:00
|
|
|
int WM_operator_poll(bContext *C, wmOperatorType *ot)
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
{
|
|
|
|
wmOperatorTypeMacro *otmacro;
|
|
|
|
|
|
|
|
for(otmacro= ot->macro.first; otmacro; otmacro= otmacro->next) {
|
2010-10-31 14:43:30 +00:00
|
|
|
wmOperatorType *ot_macro= WM_operatortype_find(otmacro->idname, 0);
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
|
2010-10-31 14:43:30 +00:00
|
|
|
if(0==WM_operator_poll(C, ot_macro))
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-18 13:02:20 +00:00
|
|
|
/* python needs operator type, so we added exception for it */
|
|
|
|
if(ot->pyop_poll)
|
|
|
|
return ot->pyop_poll(C, ot);
|
|
|
|
else if(ot->poll)
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
return ot->poll(C);
|
2009-09-18 13:02:20 +00:00
|
|
|
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2010-11-04 12:59:03 +00:00
|
|
|
/* sets up the new context and calls 'wm_operator_invoke()' with poll_only */
|
|
|
|
int WM_operator_poll_context(bContext *C, wmOperatorType *ot, int context)
|
|
|
|
{
|
|
|
|
return wm_operator_call_internal(C, ot, NULL, NULL, context, TRUE);
|
|
|
|
}
|
|
|
|
|
2010-12-13 06:54:25 +00:00
|
|
|
static void wm_operator_print(bContext *C, wmOperator *op)
|
2010-06-03 07:27:55 +00:00
|
|
|
{
|
2010-12-13 06:54:25 +00:00
|
|
|
/* context is needed for enum function */
|
|
|
|
char *buf = WM_operator_pystring(C, op->type, op->ptr, 1);
|
2010-06-03 07:27:55 +00:00
|
|
|
printf("%s\n", buf);
|
|
|
|
MEM_freeN(buf);
|
|
|
|
}
|
|
|
|
|
2011-10-21 08:16:15 +00:00
|
|
|
/* for debugging only, getting inspecting events manually is tedious */
|
|
|
|
#ifndef NDEBUG
|
|
|
|
|
|
|
|
void WM_event_print(wmEvent *event)
|
|
|
|
{
|
|
|
|
if(event) {
|
|
|
|
const char *unknown= "UNKNOWN";
|
|
|
|
const char *type_id= unknown;
|
|
|
|
const char *val_id= unknown;
|
|
|
|
|
|
|
|
RNA_enum_identifier(event_type_items, event->type, &type_id);
|
|
|
|
RNA_enum_identifier(event_value_items, event->val, &val_id);
|
|
|
|
|
|
|
|
printf("wmEvent - type:%d/%s, val:%d/%s, "
|
|
|
|
"shift:%d, ctrl:%d, alt:%d, oskey:%d, keymodifier:%d, "
|
|
|
|
"mouse:(%d,%d), ascii:'%c', utf8:'%.6s', "
|
|
|
|
"keymap_idname:%s, pointer:%p\n",
|
|
|
|
event->type, type_id, event->val, val_id,
|
|
|
|
event->shift, event->ctrl, event->alt, event->oskey, event->keymodifier,
|
|
|
|
event->x, event->y, event->ascii, event->utf8_buf,
|
|
|
|
event->keymap_idname, (void *)event);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
printf("wmEvent - NULL\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* NDEBUG */
|
|
|
|
|
2010-06-03 07:27:55 +00:00
|
|
|
static void wm_operator_reports(bContext *C, wmOperator *op, int retval, int popup)
|
|
|
|
{
|
2011-09-05 13:19:19 +00:00
|
|
|
if(popup) {
|
|
|
|
if(op->reports->list.first) {
|
|
|
|
/* FIXME, temp setting window, see other call to uiPupMenuReports for why */
|
|
|
|
wmWindow *win_prev= CTX_wm_window(C);
|
2011-09-07 11:53:16 +00:00
|
|
|
ScrArea *area_prev= CTX_wm_area(C);
|
|
|
|
ARegion *ar_prev= CTX_wm_region(C);
|
|
|
|
|
2011-09-05 13:19:19 +00:00
|
|
|
if(win_prev==NULL)
|
|
|
|
CTX_wm_window_set(C, CTX_wm_manager(C)->windows.first);
|
|
|
|
|
2010-06-03 07:27:55 +00:00
|
|
|
uiPupMenuReports(C, op->reports);
|
2011-09-05 13:19:19 +00:00
|
|
|
|
|
|
|
CTX_wm_window_set(C, win_prev);
|
2011-09-07 11:53:16 +00:00
|
|
|
CTX_wm_area_set(C, area_prev);
|
|
|
|
CTX_wm_region_set(C, ar_prev);
|
2011-09-05 13:19:19 +00:00
|
|
|
}
|
|
|
|
}
|
2010-06-03 07:27:55 +00:00
|
|
|
|
|
|
|
if(retval & OPERATOR_FINISHED) {
|
|
|
|
if(G.f & G_DEBUG)
|
2010-12-13 06:54:25 +00:00
|
|
|
wm_operator_print(C, op); /* todo - this print may double up, might want to check more flags then the FINISHED */
|
2010-06-06 08:52:33 +00:00
|
|
|
|
2011-04-09 02:23:39 +00:00
|
|
|
BKE_reports_print(op->reports, RPT_DEBUG); /* print out reports to console. */
|
2010-06-06 08:52:33 +00:00
|
|
|
if (op->type->flag & OPTYPE_REGISTER) {
|
2011-03-22 14:04:47 +00:00
|
|
|
if(G.background == 0) { /* ends up printing these in the terminal, gets annoying */
|
|
|
|
/* Report the python string representation of the operator */
|
|
|
|
char *buf = WM_operator_pystring(C, op->type, op->ptr, 1);
|
|
|
|
BKE_report(CTX_wm_reports(C), RPT_OPERATOR, buf);
|
|
|
|
MEM_freeN(buf);
|
|
|
|
}
|
2010-06-06 08:52:33 +00:00
|
|
|
}
|
2010-06-03 07:27:55 +00:00
|
|
|
}
|
|
|
|
|
2011-03-22 02:38:39 +00:00
|
|
|
/* if the caller owns them them handle this */
|
|
|
|
if (op->reports->list.first && (op->reports->flag & RPT_OP_HOLD) == 0) {
|
2011-01-14 21:45:49 +00:00
|
|
|
|
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
ReportList *wm_reports= CTX_wm_reports(C);
|
2010-06-03 07:27:55 +00:00
|
|
|
ReportTimerInfo *rti;
|
2011-01-14 21:45:49 +00:00
|
|
|
|
2010-06-03 07:27:55 +00:00
|
|
|
/* add reports to the global list, otherwise they are not seen */
|
2011-01-14 21:45:49 +00:00
|
|
|
BLI_movelisttolist(&wm_reports->list, &op->reports->list);
|
2010-06-03 07:27:55 +00:00
|
|
|
|
|
|
|
/* After adding reports to the global list, reset the report timer. */
|
2011-01-14 21:45:49 +00:00
|
|
|
WM_event_remove_timer(wm, NULL, wm_reports->reporttimer);
|
2010-06-03 07:27:55 +00:00
|
|
|
|
|
|
|
/* Records time since last report was added */
|
2011-03-28 18:51:27 +00:00
|
|
|
wm_reports->reporttimer= WM_event_add_timer(wm, CTX_wm_window(C), TIMERREPORT, 0.05);
|
2010-06-03 07:27:55 +00:00
|
|
|
|
|
|
|
rti = MEM_callocN(sizeof(ReportTimerInfo), "ReportTimerInfo");
|
2011-01-14 21:45:49 +00:00
|
|
|
wm_reports->reporttimer->customdata = rti;
|
2010-06-03 07:27:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-08-13 16:34:21 +00:00
|
|
|
/* this function is mainly to check that the rules for freeing
|
|
|
|
* an operator are kept in sync.
|
|
|
|
*/
|
|
|
|
static int wm_operator_register_check(wmWindowManager *wm, wmOperatorType *ot)
|
|
|
|
{
|
2010-11-18 16:33:13 +00:00
|
|
|
return wm && (wm->op_undo_depth == 0) && (ot->flag & OPTYPE_REGISTER);
|
2010-08-13 16:34:21 +00:00
|
|
|
}
|
|
|
|
|
2010-01-29 13:06:50 +00:00
|
|
|
static void wm_operator_finished(bContext *C, wmOperator *op, int repeat)
|
|
|
|
{
|
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
|
|
|
|
|
|
|
op->customdata= NULL;
|
|
|
|
|
|
|
|
/* we don't want to do undo pushes for operators that are being
|
|
|
|
called from operators that already do an undo push. usually
|
|
|
|
this will happen for python operators that call C operators */
|
|
|
|
if(wm->op_undo_depth == 0)
|
|
|
|
if(op->type->flag & OPTYPE_UNDO)
|
|
|
|
ED_undo_push_op(C, op);
|
|
|
|
|
|
|
|
if(repeat==0) {
|
|
|
|
if(G.f & G_DEBUG) {
|
|
|
|
char *buf = WM_operator_pystring(C, op->type, op->ptr, 1);
|
|
|
|
BKE_report(CTX_wm_reports(C), RPT_OPERATOR, buf);
|
|
|
|
MEM_freeN(buf);
|
|
|
|
}
|
|
|
|
|
2010-08-13 16:34:21 +00:00
|
|
|
if(wm_operator_register_check(wm, op->type))
|
2010-01-29 13:06:50 +00:00
|
|
|
wm_operator_register(C, op);
|
|
|
|
else
|
|
|
|
WM_operator_free(op);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-02-01 12:00:00 +00:00
|
|
|
/* if repeat is true, it doesn't register again, nor does it free */
|
|
|
|
static int wm_operator_exec(bContext *C, wmOperator *op, int repeat)
|
2008-12-24 14:52:17 +00:00
|
|
|
{
|
2010-01-29 13:06:50 +00:00
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
2008-12-24 14:52:17 +00:00
|
|
|
int retval= OPERATOR_CANCELLED;
|
|
|
|
|
2010-09-27 12:21:23 +00:00
|
|
|
CTX_wm_operator_poll_msg_set(C, NULL);
|
|
|
|
|
2009-02-01 12:00:00 +00:00
|
|
|
if(op==NULL || op->type==NULL)
|
|
|
|
return retval;
|
|
|
|
|
2009-09-18 13:02:20 +00:00
|
|
|
if(0==WM_operator_poll(C, op->type))
|
2009-02-01 12:00:00 +00:00
|
|
|
return retval;
|
|
|
|
|
2010-01-29 13:06:50 +00:00
|
|
|
if(op->type->exec) {
|
|
|
|
if(op->type->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth++;
|
|
|
|
|
2008-12-24 14:52:17 +00:00
|
|
|
retval= op->type->exec(C, op);
|
2011-08-25 16:42:42 +00:00
|
|
|
OPERATOR_RETVAL_CHECK(retval);
|
2010-01-29 13:06:50 +00:00
|
|
|
|
2010-04-20 14:58:46 +00:00
|
|
|
if(op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
|
2010-01-29 13:06:50 +00:00
|
|
|
wm->op_undo_depth--;
|
|
|
|
}
|
2009-02-01 12:00:00 +00:00
|
|
|
|
2010-06-03 07:27:55 +00:00
|
|
|
if (retval & (OPERATOR_FINISHED|OPERATOR_CANCELLED) && repeat == 0)
|
|
|
|
wm_operator_reports(C, op, retval, 0);
|
2008-12-24 14:52:17 +00:00
|
|
|
|
2010-01-29 13:06:50 +00:00
|
|
|
if(retval & OPERATOR_FINISHED)
|
|
|
|
wm_operator_finished(C, op, repeat);
|
2009-02-01 12:00:00 +00:00
|
|
|
else if(repeat==0)
|
2008-12-26 03:56:52 +00:00
|
|
|
WM_operator_free(op);
|
2009-02-01 12:00:00 +00:00
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
return retval | OPERATOR_HANDLED;
|
2009-02-01 12:00:00 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
/* for running operators with frozen context (modal handlers, menus) */
|
|
|
|
int WM_operator_call(bContext *C, wmOperator *op)
|
|
|
|
{
|
|
|
|
return wm_operator_exec(C, op, 0);
|
2008-12-24 14:52:17 +00:00
|
|
|
}
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
|
2009-02-01 12:00:00 +00:00
|
|
|
/* do this operator again, put here so it can share above code */
|
|
|
|
int WM_operator_repeat(bContext *C, wmOperator *op)
|
|
|
|
{
|
|
|
|
return wm_operator_exec(C, op, 1);
|
|
|
|
}
|
2010-12-15 04:06:19 +00:00
|
|
|
/* TRUE if WM_operator_repeat can run
|
|
|
|
* simple check for now but may become more involved.
|
|
|
|
* To be sure the operator can run call WM_operator_poll(C, op->type) also, since this call
|
|
|
|
* checks if WM_operator_repeat() can run at all, not that it WILL run at any time. */
|
|
|
|
int WM_operator_repeat_check(const bContext *UNUSED(C), wmOperator *op)
|
|
|
|
{
|
|
|
|
return op->type->exec != NULL;
|
|
|
|
}
|
2009-01-18 10:46:26 +00:00
|
|
|
|
|
|
|
static wmOperator *wm_operator_create(wmWindowManager *wm, wmOperatorType *ot, PointerRNA *properties, ReportList *reports)
|
|
|
|
{
|
|
|
|
wmOperator *op= MEM_callocN(sizeof(wmOperator), ot->idname); /* XXX operatortype names are static still. for debug */
|
|
|
|
|
|
|
|
/* XXX adding new operator could be function, only happens here now */
|
|
|
|
op->type= ot;
|
|
|
|
BLI_strncpy(op->idname, ot->idname, OP_MAX_TYPENAME);
|
|
|
|
|
|
|
|
/* initialize properties, either copy or create */
|
|
|
|
op->ptr= MEM_callocN(sizeof(PointerRNA), "wmOperatorPtrRNA");
|
|
|
|
if(properties && properties->data) {
|
|
|
|
op->properties= IDP_CopyProperty(properties->data);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
IDPropertyTemplate val = {0};
|
|
|
|
op->properties= IDP_New(IDP_GROUP, val, "wmOperatorProperties");
|
|
|
|
}
|
|
|
|
RNA_pointer_create(&wm->id, ot->srna, op->properties, op->ptr);
|
|
|
|
|
|
|
|
/* initialize error reports */
|
|
|
|
if (reports) {
|
2009-09-03 22:37:09 +00:00
|
|
|
op->reports= reports; /* must be initialized already */
|
2009-01-18 10:46:26 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
op->reports= MEM_mallocN(sizeof(ReportList), "wmOperatorReportList");
|
2009-09-15 16:25:53 +00:00
|
|
|
BKE_reports_init(op->reports, RPT_STORE|RPT_FREE);
|
2009-01-18 10:46:26 +00:00
|
|
|
}
|
|
|
|
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
/* recursive filling of operator macro list */
|
|
|
|
if(ot->macro.first) {
|
|
|
|
static wmOperator *motherop= NULL;
|
|
|
|
wmOperatorTypeMacro *otmacro;
|
2009-12-05 19:05:21 +00:00
|
|
|
int root = 0;
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
|
|
|
|
/* ensure all ops are in execution order in 1 list */
|
2009-12-05 19:05:21 +00:00
|
|
|
if(motherop==NULL) {
|
|
|
|
motherop = op;
|
|
|
|
root = 1;
|
|
|
|
}
|
2010-01-21 21:58:40 +00:00
|
|
|
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
|
2010-01-21 21:58:40 +00:00
|
|
|
/* if properties exist, it will contain everything needed */
|
|
|
|
if (properties) {
|
|
|
|
otmacro= ot->macro.first;
|
|
|
|
|
|
|
|
RNA_STRUCT_BEGIN(properties, prop) {
|
|
|
|
|
|
|
|
if (otmacro == NULL)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* skip invalid properties */
|
|
|
|
if (strcmp(RNA_property_identifier(prop), otmacro->idname) == 0)
|
|
|
|
{
|
|
|
|
wmOperatorType *otm= WM_operatortype_find(otmacro->idname, 0);
|
|
|
|
PointerRNA someptr = RNA_property_pointer_get(properties, prop);
|
|
|
|
wmOperator *opm= wm_operator_create(wm, otm, &someptr, NULL);
|
2010-01-05 03:31:57 +00:00
|
|
|
|
2010-01-21 21:58:40 +00:00
|
|
|
IDP_ReplaceGroupInGroup(opm->properties, otmacro->properties);
|
|
|
|
|
|
|
|
BLI_addtail(&motherop->macro, opm);
|
|
|
|
opm->opm= motherop; /* pointer to mom, for modal() */
|
|
|
|
|
|
|
|
otmacro= otmacro->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
RNA_STRUCT_END;
|
|
|
|
} else {
|
|
|
|
for (otmacro = ot->macro.first; otmacro; otmacro = otmacro->next) {
|
|
|
|
wmOperatorType *otm= WM_operatortype_find(otmacro->idname, 0);
|
|
|
|
wmOperator *opm= wm_operator_create(wm, otm, otmacro->ptr, NULL);
|
|
|
|
|
|
|
|
BLI_addtail(&motherop->macro, opm);
|
|
|
|
opm->opm= motherop; /* pointer to mom, for modal() */
|
|
|
|
}
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
}
|
|
|
|
|
2009-12-05 19:05:21 +00:00
|
|
|
if (root)
|
|
|
|
motherop= NULL;
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
}
|
|
|
|
|
2010-02-01 18:26:45 +00:00
|
|
|
WM_operator_properties_sanitize(op->ptr, 0);
|
|
|
|
|
2009-01-18 10:46:26 +00:00
|
|
|
return op;
|
|
|
|
}
|
|
|
|
|
2009-02-19 19:03:53 +00:00
|
|
|
static void wm_region_mouse_co(bContext *C, wmEvent *event)
|
|
|
|
{
|
|
|
|
ARegion *ar= CTX_wm_region(C);
|
|
|
|
if(ar) {
|
|
|
|
/* compatibility convention */
|
|
|
|
event->mval[0]= event->x - ar->winrct.xmin;
|
|
|
|
event->mval[1]= event->y - ar->winrct.ymin;
|
|
|
|
}
|
2011-05-22 04:05:09 +00:00
|
|
|
else {
|
|
|
|
/* these values are invalid (avoid odd behavior by relying on old mval values) */
|
|
|
|
event->mval[0]= -1;
|
|
|
|
event->mval[1]= -1;
|
|
|
|
}
|
2009-02-19 19:03:53 +00:00
|
|
|
}
|
|
|
|
|
2011-02-13 14:16:36 +00:00
|
|
|
static int wm_operator_invoke(bContext *C, wmOperatorType *ot, wmEvent *event, PointerRNA *properties, ReportList *reports, short poll_only)
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
{
|
2008-12-18 02:56:48 +00:00
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
int retval= OPERATOR_PASS_THROUGH;
|
|
|
|
|
2010-11-04 12:59:03 +00:00
|
|
|
/* this is done because complicated setup is done to call this function that is better not duplicated */
|
|
|
|
if(poll_only)
|
|
|
|
return WM_operator_poll(C, ot);
|
|
|
|
|
2009-09-18 13:02:20 +00:00
|
|
|
if(WM_operator_poll(C, ot)) {
|
2009-09-03 22:37:09 +00:00
|
|
|
wmOperator *op= wm_operator_create(wm, ot, properties, reports); /* if reports==NULL, theyll be initialized */
|
2009-01-18 10:46:26 +00:00
|
|
|
|
Made modal operators print their operator string after executing
(when in debug "-d" mode only)
copy & paste duplicate and transform operations can now be copied from user input and pasted into ./test.py and run with the Pkey (fixed some minor bugs preventing this)
Would be nice if the "mode" setting used a proper RNA Enum rather then an int.
# example, duplicate and transform
bpyoperator.OBJECT_OT_add_duplicate(mode=1)
bpyoperator.TFM_OT_transform(mode=1, options=0, values=(-1.23989, 0.570745, 0, 0), constraint_orientation=0, constraint_mode=0, constraint_matrix=(0, 0, 0, 0, 0, 0, 0, 0, 0))
2009-01-18 07:35:44 +00:00
|
|
|
if((G.f & G_DEBUG) && event && event->type!=MOUSEMOVE)
|
2009-01-17 18:35:33 +00:00
|
|
|
printf("handle evt %d win %d op %s\n", event?event->type:0, CTX_wm_screen(C)->subwinactive, ot->idname);
|
|
|
|
|
2009-02-19 19:03:53 +00:00
|
|
|
if(op->type->invoke && event) {
|
|
|
|
wm_region_mouse_co(C, event);
|
2010-01-29 13:06:50 +00:00
|
|
|
|
|
|
|
if(op->type->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth++;
|
|
|
|
|
2009-02-19 19:03:53 +00:00
|
|
|
retval= op->type->invoke(C, op, event);
|
2011-08-25 16:42:42 +00:00
|
|
|
OPERATOR_RETVAL_CHECK(retval);
|
2010-01-29 13:06:50 +00:00
|
|
|
|
2010-04-20 14:58:46 +00:00
|
|
|
if(op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
|
2010-01-29 13:06:50 +00:00
|
|
|
wm->op_undo_depth--;
|
2009-02-19 19:03:53 +00:00
|
|
|
}
|
2010-01-29 13:06:50 +00:00
|
|
|
else if(op->type->exec) {
|
|
|
|
if(op->type->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth++;
|
|
|
|
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
retval= op->type->exec(C, op);
|
2011-08-25 16:42:42 +00:00
|
|
|
OPERATOR_RETVAL_CHECK(retval);
|
2010-01-29 13:06:50 +00:00
|
|
|
|
2010-04-20 14:58:46 +00:00
|
|
|
if(op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
|
2010-01-29 13:06:50 +00:00
|
|
|
wm->op_undo_depth--;
|
|
|
|
}
|
2008-12-26 12:21:06 +00:00
|
|
|
else
|
|
|
|
printf("invalid operator call %s\n", ot->idname); /* debug, important to leave a while, should never happen */
|
2010-06-03 07:27:55 +00:00
|
|
|
|
2009-09-22 09:12:39 +00:00
|
|
|
/* Note, if the report is given as an argument then assume the caller will deal with displaying them
|
|
|
|
* currently python only uses this */
|
2010-06-03 07:27:55 +00:00
|
|
|
if (!(retval & OPERATOR_HANDLED) && retval & (OPERATOR_FINISHED|OPERATOR_CANCELLED))
|
|
|
|
/* only show the report if the report list was not given in the function */
|
|
|
|
wm_operator_reports(C, op, retval, (reports==NULL));
|
Made modal operators print their operator string after executing
(when in debug "-d" mode only)
copy & paste duplicate and transform operations can now be copied from user input and pasted into ./test.py and run with the Pkey (fixed some minor bugs preventing this)
Would be nice if the "mode" setting used a proper RNA Enum rather then an int.
# example, duplicate and transform
bpyoperator.OBJECT_OT_add_duplicate(mode=1)
bpyoperator.TFM_OT_transform(mode=1, options=0, values=(-1.23989, 0.570745, 0, 0), constraint_orientation=0, constraint_mode=0, constraint_matrix=(0, 0, 0, 0, 0, 0, 0, 0, 0))
2009-01-18 07:35:44 +00:00
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
if(retval & OPERATOR_HANDLED)
|
|
|
|
; /* do nothing, wm_operator_exec() has been called somewhere */
|
|
|
|
else if(retval & OPERATOR_FINISHED) {
|
2010-01-29 13:06:50 +00:00
|
|
|
wm_operator_finished(C, op, 0);
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
}
|
2009-07-09 16:05:01 +00:00
|
|
|
else if(retval & OPERATOR_RUNNING_MODAL) {
|
2009-11-19 19:27:10 +00:00
|
|
|
/* grab cursor during blocking modal ops (X11)
|
|
|
|
* Also check for macro
|
|
|
|
* */
|
|
|
|
if(ot->flag & OPTYPE_BLOCKING || (op->opm && op->opm->type->flag & OPTYPE_BLOCKING)) {
|
2009-10-17 19:32:28 +00:00
|
|
|
int bounds[4] = {-1,-1,-1,-1};
|
2009-11-19 19:27:10 +00:00
|
|
|
int wrap;
|
|
|
|
|
|
|
|
if (op->opm) {
|
|
|
|
wrap = (U.uiflag & USER_CONTINUOUS_MOUSE) && ((op->opm->flag & OP_GRAB_POINTER) || (op->opm->type->flag & OPTYPE_GRAB_POINTER));
|
|
|
|
} else {
|
|
|
|
wrap = (U.uiflag & USER_CONTINUOUS_MOUSE) && ((op->flag & OP_GRAB_POINTER) || (ot->flag & OPTYPE_GRAB_POINTER));
|
|
|
|
}
|
2009-10-17 19:32:28 +00:00
|
|
|
|
2011-04-04 03:25:05 +00:00
|
|
|
/* exception, cont. grab in header is annoying */
|
|
|
|
if(wrap) {
|
|
|
|
ARegion *ar= CTX_wm_region(C);
|
|
|
|
if(ar && ar->regiontype == RGN_TYPE_HEADER) {
|
|
|
|
wrap= FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-10-17 19:32:28 +00:00
|
|
|
if(wrap) {
|
2010-12-15 16:46:59 +00:00
|
|
|
rcti *winrect= NULL;
|
|
|
|
ARegion *ar= CTX_wm_region(C);
|
2010-12-15 15:28:03 +00:00
|
|
|
ScrArea *sa= CTX_wm_area(C);
|
2010-12-15 16:46:59 +00:00
|
|
|
|
2011-01-13 04:53:55 +00:00
|
|
|
if(ar && ar->regiontype == RGN_TYPE_WINDOW && event && BLI_in_rcti(&ar->winrct, event->x, event->y)) {
|
2010-12-15 16:46:59 +00:00
|
|
|
winrect= &ar->winrct;
|
|
|
|
}
|
|
|
|
else if(sa) {
|
|
|
|
winrect= &sa->totrct;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(winrect) {
|
|
|
|
bounds[0]= winrect->xmin;
|
|
|
|
bounds[1]= winrect->ymax;
|
|
|
|
bounds[2]= winrect->xmax;
|
|
|
|
bounds[3]= winrect->ymin;
|
2009-10-17 19:32:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
WM_cursor_grab(CTX_wm_window(C), wrap, FALSE, bounds);
|
2009-10-10 17:19:49 +00:00
|
|
|
}
|
2010-01-31 23:33:04 +00:00
|
|
|
|
|
|
|
/* cancel UI handlers, typically tooltips that can hang around
|
|
|
|
while dragging the view or worse, that stay there permanently
|
|
|
|
after the modal operator has swallowed all events and passed
|
|
|
|
none to the UI handler */
|
|
|
|
wm_handler_ui_cancel(C);
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
}
|
2009-07-09 16:05:01 +00:00
|
|
|
else
|
|
|
|
WM_operator_free(op);
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2009-09-03 22:37:09 +00:00
|
|
|
/* WM_operator_name_call is the main accessor function
|
|
|
|
* this is for python to access since its done the operator lookup
|
|
|
|
*
|
|
|
|
* invokes operator in context */
|
2010-11-04 12:59:03 +00:00
|
|
|
static int wm_operator_call_internal(bContext *C, wmOperatorType *ot, PointerRNA *properties, ReportList *reports, short context, short poll_only)
|
2008-12-11 15:38:16 +00:00
|
|
|
{
|
2008-12-18 02:56:48 +00:00
|
|
|
wmWindow *window= CTX_wm_window(C);
|
2008-12-26 13:50:32 +00:00
|
|
|
wmEvent *event;
|
2008-12-26 12:21:06 +00:00
|
|
|
|
2008-12-16 07:44:21 +00:00
|
|
|
int retval;
|
|
|
|
|
2010-09-27 12:21:23 +00:00
|
|
|
CTX_wm_operator_poll_msg_set(C, NULL);
|
|
|
|
|
2008-12-11 15:38:16 +00:00
|
|
|
/* dummie test */
|
2009-11-10 20:44:10 +00:00
|
|
|
if(ot && C) {
|
|
|
|
switch(context) {
|
|
|
|
case WM_OP_INVOKE_DEFAULT:
|
|
|
|
case WM_OP_INVOKE_REGION_WIN:
|
|
|
|
case WM_OP_INVOKE_AREA:
|
|
|
|
case WM_OP_INVOKE_SCREEN:
|
|
|
|
/* window is needed for invoke, cancel operator */
|
|
|
|
if (window == NULL)
|
|
|
|
return 0;
|
|
|
|
else
|
|
|
|
event= window->eventstate;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
event = NULL;
|
|
|
|
}
|
|
|
|
|
2008-12-26 12:21:06 +00:00
|
|
|
switch(context) {
|
2008-12-16 07:44:21 +00:00
|
|
|
|
2008-12-26 12:21:06 +00:00
|
|
|
case WM_OP_EXEC_REGION_WIN:
|
|
|
|
case WM_OP_INVOKE_REGION_WIN:
|
2010-02-07 23:39:44 +00:00
|
|
|
case WM_OP_EXEC_REGION_CHANNELS:
|
|
|
|
case WM_OP_INVOKE_REGION_CHANNELS:
|
|
|
|
case WM_OP_EXEC_REGION_PREVIEW:
|
|
|
|
case WM_OP_INVOKE_REGION_PREVIEW:
|
2008-12-26 12:21:06 +00:00
|
|
|
{
|
2010-02-07 23:39:44 +00:00
|
|
|
/* forces operator to go to the region window/channels/preview, for header menus
|
|
|
|
* but we stay in the same region if we are already in one
|
|
|
|
*/
|
2008-12-26 12:21:06 +00:00
|
|
|
ARegion *ar= CTX_wm_region(C);
|
|
|
|
ScrArea *area= CTX_wm_area(C);
|
2010-02-07 23:39:44 +00:00
|
|
|
int type = RGN_TYPE_WINDOW;
|
2008-12-26 12:21:06 +00:00
|
|
|
|
2010-02-07 23:39:44 +00:00
|
|
|
switch (context) {
|
|
|
|
case WM_OP_EXEC_REGION_CHANNELS:
|
|
|
|
case WM_OP_INVOKE_REGION_CHANNELS:
|
|
|
|
type = RGN_TYPE_CHANNELS;
|
2010-11-20 07:51:39 +00:00
|
|
|
break;
|
2010-02-07 23:39:44 +00:00
|
|
|
|
|
|
|
case WM_OP_EXEC_REGION_PREVIEW:
|
|
|
|
case WM_OP_INVOKE_REGION_PREVIEW:
|
|
|
|
type = RGN_TYPE_PREVIEW;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case WM_OP_EXEC_REGION_WIN:
|
|
|
|
case WM_OP_INVOKE_REGION_WIN:
|
|
|
|
default:
|
|
|
|
type = RGN_TYPE_WINDOW;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(!(ar && ar->regiontype == type) && area) {
|
|
|
|
ARegion *ar1= BKE_area_find_region_type(area, type);
|
2008-12-26 12:21:06 +00:00
|
|
|
if(ar1)
|
|
|
|
CTX_wm_region_set(C, ar1);
|
|
|
|
}
|
|
|
|
|
2010-11-04 12:59:03 +00:00
|
|
|
retval= wm_operator_invoke(C, ot, event, properties, reports, poll_only);
|
2008-12-26 12:21:06 +00:00
|
|
|
|
|
|
|
/* set region back */
|
|
|
|
CTX_wm_region_set(C, ar);
|
|
|
|
|
|
|
|
return retval;
|
2008-12-16 07:44:21 +00:00
|
|
|
}
|
2008-12-26 12:21:06 +00:00
|
|
|
case WM_OP_EXEC_AREA:
|
|
|
|
case WM_OP_INVOKE_AREA:
|
|
|
|
{
|
|
|
|
/* remove region from context */
|
|
|
|
ARegion *ar= CTX_wm_region(C);
|
2008-12-11 15:38:16 +00:00
|
|
|
|
2008-12-26 12:21:06 +00:00
|
|
|
CTX_wm_region_set(C, NULL);
|
2010-11-04 12:59:03 +00:00
|
|
|
retval= wm_operator_invoke(C, ot, event, properties, reports, poll_only);
|
2008-12-26 12:21:06 +00:00
|
|
|
CTX_wm_region_set(C, ar);
|
2008-12-11 15:38:16 +00:00
|
|
|
|
2008-12-26 12:21:06 +00:00
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
case WM_OP_EXEC_SCREEN:
|
|
|
|
case WM_OP_INVOKE_SCREEN:
|
|
|
|
{
|
|
|
|
/* remove region + area from context */
|
|
|
|
ARegion *ar= CTX_wm_region(C);
|
|
|
|
ScrArea *area= CTX_wm_area(C);
|
|
|
|
|
|
|
|
CTX_wm_region_set(C, NULL);
|
|
|
|
CTX_wm_area_set(C, NULL);
|
2010-11-04 12:59:03 +00:00
|
|
|
retval= wm_operator_invoke(C, ot, event, properties, reports, poll_only);
|
2008-12-26 12:21:06 +00:00
|
|
|
CTX_wm_area_set(C, area);
|
2011-09-05 17:57:04 +00:00
|
|
|
CTX_wm_region_set(C, ar);
|
2008-12-26 12:21:06 +00:00
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
case WM_OP_EXEC_DEFAULT:
|
|
|
|
case WM_OP_INVOKE_DEFAULT:
|
2010-11-04 12:59:03 +00:00
|
|
|
return wm_operator_invoke(C, ot, event, properties, reports, poll_only);
|
2008-12-16 07:44:21 +00:00
|
|
|
}
|
2008-12-11 15:38:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-09-03 22:37:09 +00:00
|
|
|
|
|
|
|
/* invokes operator in context */
|
|
|
|
int WM_operator_name_call(bContext *C, const char *opstring, int context, PointerRNA *properties)
|
|
|
|
{
|
|
|
|
wmOperatorType *ot= WM_operatortype_find(opstring, 0);
|
|
|
|
if(ot)
|
2010-11-04 12:59:03 +00:00
|
|
|
return wm_operator_call_internal(C, ot, properties, NULL, context, FALSE);
|
2009-09-03 22:37:09 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-01-18 10:46:26 +00:00
|
|
|
/* Similar to WM_operator_name_call called with WM_OP_EXEC_DEFAULT context.
|
2010-07-17 18:08:14 +00:00
|
|
|
- wmOperatorType is used instead of operator name since python already has the operator type
|
2009-01-18 10:46:26 +00:00
|
|
|
- poll() must be called by python before this runs.
|
|
|
|
- reports can be passed to this function (so python can report them as exceptions)
|
|
|
|
*/
|
2009-09-03 22:37:09 +00:00
|
|
|
int WM_operator_call_py(bContext *C, wmOperatorType *ot, int context, PointerRNA *properties, ReportList *reports)
|
2009-01-18 10:46:26 +00:00
|
|
|
{
|
2009-03-16 15:54:43 +00:00
|
|
|
int retval= OPERATOR_CANCELLED;
|
2009-09-03 22:37:09 +00:00
|
|
|
|
|
|
|
#if 0
|
|
|
|
wmOperator *op;
|
|
|
|
op= wm_operator_create(wm, ot, properties, reports);
|
|
|
|
|
2010-01-29 13:06:50 +00:00
|
|
|
if (op->type->exec) {
|
|
|
|
if(op->type->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth++;
|
|
|
|
|
2009-03-16 15:54:43 +00:00
|
|
|
retval= op->type->exec(C, op);
|
2011-08-25 16:42:42 +00:00
|
|
|
OPERATOR_RETVAL_CHECK(retval);
|
2010-01-29 13:06:50 +00:00
|
|
|
|
2010-04-20 14:58:46 +00:00
|
|
|
if(op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
|
2010-01-29 13:06:50 +00:00
|
|
|
wm->op_undo_depth--;
|
|
|
|
}
|
2009-03-16 15:54:43 +00:00
|
|
|
else
|
|
|
|
printf("error \"%s\" operator has no exec function, python cannot call it\n", op->type->name);
|
2009-09-03 22:37:09 +00:00
|
|
|
#endif
|
|
|
|
|
2010-11-04 12:59:03 +00:00
|
|
|
retval= wm_operator_call_internal(C, ot, properties, reports, context, FALSE);
|
2009-01-18 10:46:26 +00:00
|
|
|
|
2009-09-15 16:25:53 +00:00
|
|
|
/* keep the reports around if needed later */
|
2010-09-20 04:59:20 +00:00
|
|
|
if ( (retval & OPERATOR_RUNNING_MODAL) ||
|
2010-11-18 16:33:13 +00:00
|
|
|
((retval & OPERATOR_FINISHED) && wm_operator_register_check(CTX_wm_manager(C), ot))
|
2010-09-20 04:59:20 +00:00
|
|
|
) {
|
2010-08-13 16:34:21 +00:00
|
|
|
reports->flag |= RPT_FREE; /* let blender manage freeing */
|
2009-09-14 16:00:42 +00:00
|
|
|
}
|
|
|
|
|
2009-01-18 10:46:26 +00:00
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
/* ********************* handlers *************** */
|
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
/* future extra customadata free? */
|
2009-11-17 22:19:48 +00:00
|
|
|
void wm_event_free_handler(wmEventHandler *handler)
|
2008-01-10 17:38:17 +00:00
|
|
|
{
|
2009-02-16 12:14:04 +00:00
|
|
|
MEM_freeN(handler);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* only set context when area/region is part of screen */
|
|
|
|
static void wm_handler_op_context(bContext *C, wmEventHandler *handler)
|
|
|
|
{
|
|
|
|
bScreen *screen= CTX_wm_screen(C);
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
if(screen && handler->op) {
|
2009-02-16 15:08:06 +00:00
|
|
|
if(handler->op_area==NULL)
|
|
|
|
CTX_wm_area_set(C, NULL);
|
2009-02-16 12:14:04 +00:00
|
|
|
else {
|
2009-02-16 15:08:06 +00:00
|
|
|
ScrArea *sa;
|
|
|
|
|
|
|
|
for(sa= screen->areabase.first; sa; sa= sa->next)
|
|
|
|
if(sa==handler->op_area)
|
2009-02-16 12:14:04 +00:00
|
|
|
break;
|
2009-07-24 12:43:59 +00:00
|
|
|
if(sa==NULL) {
|
|
|
|
/* when changing screen layouts with running modal handlers (like render display), this
|
|
|
|
is not an error to print */
|
|
|
|
if(handler->op==NULL)
|
|
|
|
printf("internal error: handler (%s) has invalid area\n", handler->op->type->idname);
|
|
|
|
}
|
2009-02-16 15:08:06 +00:00
|
|
|
else {
|
|
|
|
ARegion *ar;
|
|
|
|
CTX_wm_area_set(C, sa);
|
|
|
|
for(ar= sa->regionbase.first; ar; ar= ar->next)
|
|
|
|
if(ar==handler->op_region)
|
|
|
|
break;
|
|
|
|
/* XXX no warning print here, after full-area and back regions are remade */
|
|
|
|
if(ar)
|
|
|
|
CTX_wm_region_set(C, ar);
|
|
|
|
}
|
2009-02-16 12:14:04 +00:00
|
|
|
}
|
|
|
|
}
|
2008-01-10 17:38:17 +00:00
|
|
|
}
|
|
|
|
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
/* called on exit or remove area, only here call cancel callback */
|
|
|
|
void WM_event_remove_handlers(bContext *C, ListBase *handlers)
|
2007-12-24 18:27:28 +00:00
|
|
|
{
|
|
|
|
wmEventHandler *handler;
|
2010-01-29 13:06:50 +00:00
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
2007-12-24 18:27:28 +00:00
|
|
|
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
/* C is zero on freeing database, modal handlers then already were freed */
|
|
|
|
while((handler=handlers->first)) {
|
|
|
|
BLI_remlink(handlers, handler);
|
|
|
|
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
if(handler->op) {
|
|
|
|
if(handler->op->type->cancel) {
|
2008-12-18 02:56:48 +00:00
|
|
|
ScrArea *area= CTX_wm_area(C);
|
|
|
|
ARegion *region= CTX_wm_region(C);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
wm_handler_op_context(C, handler);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2010-01-29 13:06:50 +00:00
|
|
|
if(handler->op->type->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth++;
|
|
|
|
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
handler->op->type->cancel(C, handler->op);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2010-01-29 13:06:50 +00:00
|
|
|
if(handler->op->type->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth--;
|
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
CTX_wm_area_set(C, area);
|
|
|
|
CTX_wm_region_set(C, region);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
}
|
|
|
|
|
2009-10-17 14:08:01 +00:00
|
|
|
WM_cursor_ungrab(CTX_wm_window(C));
|
2008-12-24 14:52:17 +00:00
|
|
|
WM_operator_free(handler->op);
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
}
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
else if(handler->ui_remove) {
|
2008-12-18 02:56:48 +00:00
|
|
|
ScrArea *area= CTX_wm_area(C);
|
|
|
|
ARegion *region= CTX_wm_region(C);
|
2009-03-25 20:49:15 +00:00
|
|
|
ARegion *menu= CTX_wm_menu(C);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
if(handler->ui_area) CTX_wm_area_set(C, handler->ui_area);
|
|
|
|
if(handler->ui_region) CTX_wm_region_set(C, handler->ui_region);
|
2009-03-25 20:49:15 +00:00
|
|
|
if(handler->ui_menu) CTX_wm_menu_set(C, handler->ui_menu);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2008-12-15 19:19:39 +00:00
|
|
|
handler->ui_remove(C, handler->ui_userdata);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
CTX_wm_area_set(C, area);
|
|
|
|
CTX_wm_region_set(C, region);
|
2009-03-25 20:49:15 +00:00
|
|
|
CTX_wm_menu_set(C, menu);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
}
|
|
|
|
|
2008-01-10 17:38:17 +00:00
|
|
|
wm_event_free_handler(handler);
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
}
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
}
|
|
|
|
|
2009-01-01 18:05:12 +00:00
|
|
|
/* do userdef mappings */
|
Keymap conflict detection operator.
Takes into account the hierarchical structures of keymaps as well as wildcards (KM_ANY) in event definitions, user remaps (emulate numpad, action/select mouse buttons, ...) and event values that overlap (click, press and release)
For now, doesn't do anything other than print conflicts in the console.
As a result, I cleaned up a lot of keymaps that had double definitions, moved some keymap items in more appropriate places, fixed wrong definitions and removed kmi that were added for testing a long long time ago.
Out of all the remaining conflicts, after removing obvious non-issues, here's what remains: http://www.pasteall.org/9898
2009-12-17 22:14:43 +00:00
|
|
|
int WM_userdef_event_map(int kmitype)
|
2007-12-24 18:27:28 +00:00
|
|
|
{
|
2009-01-01 18:05:12 +00:00
|
|
|
switch(kmitype) {
|
|
|
|
case SELECTMOUSE:
|
|
|
|
if(U.flag & USER_LMOUSESELECT)
|
|
|
|
return LEFTMOUSE;
|
|
|
|
else
|
|
|
|
return RIGHTMOUSE;
|
|
|
|
|
|
|
|
case ACTIONMOUSE:
|
|
|
|
if(U.flag & USER_LMOUSESELECT)
|
|
|
|
return RIGHTMOUSE;
|
|
|
|
else
|
|
|
|
return LEFTMOUSE;
|
|
|
|
|
|
|
|
case WHEELOUTMOUSE:
|
|
|
|
if(U.uiflag & USER_WHEELZOOMDIR)
|
|
|
|
return WHEELUPMOUSE;
|
|
|
|
else
|
|
|
|
return WHEELDOWNMOUSE;
|
|
|
|
|
|
|
|
case WHEELINMOUSE:
|
|
|
|
if(U.uiflag & USER_WHEELZOOMDIR)
|
|
|
|
return WHEELDOWNMOUSE;
|
|
|
|
else
|
|
|
|
return WHEELUPMOUSE;
|
|
|
|
|
|
|
|
case EVT_TWEAK_A:
|
|
|
|
if(U.flag & USER_LMOUSESELECT)
|
|
|
|
return EVT_TWEAK_R;
|
|
|
|
else
|
|
|
|
return EVT_TWEAK_L;
|
|
|
|
|
|
|
|
case EVT_TWEAK_S:
|
|
|
|
if(U.flag & USER_LMOUSESELECT)
|
|
|
|
return EVT_TWEAK_L;
|
|
|
|
else
|
|
|
|
return EVT_TWEAK_R;
|
2009-01-01 14:57:04 +00:00
|
|
|
}
|
2008-12-20 15:42:48 +00:00
|
|
|
|
2009-01-01 18:05:12 +00:00
|
|
|
return kmitype;
|
|
|
|
}
|
|
|
|
|
2010-01-14 18:15:12 +00:00
|
|
|
static void wm_eventemulation(wmEvent *event)
|
2009-01-01 18:05:12 +00:00
|
|
|
{
|
2010-01-27 17:01:41 +00:00
|
|
|
static int mmb_emulated = 0; /* this should be in a data structure somwhere */
|
|
|
|
|
2010-01-14 18:15:12 +00:00
|
|
|
/* middlemouse emulation */
|
|
|
|
if(U.flag & USER_TWOBUTTONMOUSE) {
|
2010-01-27 17:01:41 +00:00
|
|
|
if(event->type == LEFTMOUSE && (event->alt || mmb_emulated == KM_PRESS)) {
|
2010-01-14 18:15:12 +00:00
|
|
|
event->type = MIDDLEMOUSE;
|
|
|
|
event->alt = 0;
|
2010-01-27 17:01:41 +00:00
|
|
|
mmb_emulated = event->val;
|
2009-08-18 16:11:53 +00:00
|
|
|
}
|
|
|
|
}
|
2009-11-22 16:33:47 +00:00
|
|
|
|
2010-01-15 06:17:28 +00:00
|
|
|
#ifdef __APPLE__
|
|
|
|
/* rightmouse emulation */
|
|
|
|
if(U.flag & USER_TWOBUTTONMOUSE) {
|
2010-01-27 19:46:12 +00:00
|
|
|
if(event->type == LEFTMOUSE && (event->oskey || mmb_emulated == KM_PRESS)) {
|
2010-01-15 06:17:28 +00:00
|
|
|
event->type = RIGHTMOUSE;
|
|
|
|
event->oskey = 0;
|
2010-01-27 17:01:41 +00:00
|
|
|
mmb_emulated = event->val;
|
2010-01-15 06:17:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-01-14 18:15:12 +00:00
|
|
|
/* numpad emulation */
|
|
|
|
if(U.flag & USER_NONUMPAD) {
|
|
|
|
switch(event->type) {
|
|
|
|
case ZEROKEY: event->type = PAD0; break;
|
|
|
|
case ONEKEY: event->type = PAD1; break;
|
|
|
|
case TWOKEY: event->type = PAD2; break;
|
|
|
|
case THREEKEY: event->type = PAD3; break;
|
|
|
|
case FOURKEY: event->type = PAD4; break;
|
|
|
|
case FIVEKEY: event->type = PAD5; break;
|
|
|
|
case SIXKEY: event->type = PAD6; break;
|
|
|
|
case SEVENKEY: event->type = PAD7; break;
|
|
|
|
case EIGHTKEY: event->type = PAD8; break;
|
|
|
|
case NINEKEY: event->type = PAD9; break;
|
|
|
|
case MINUSKEY: event->type = PADMINUS; break;
|
|
|
|
case EQUALKEY: event->type = PADPLUSKEY; break;
|
|
|
|
case BACKSLASHKEY: event->type = PADSLASHKEY; break;
|
|
|
|
}
|
2009-11-22 16:33:47 +00:00
|
|
|
}
|
2010-01-14 18:15:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int wm_eventmatch(wmEvent *winevent, wmKeyMapItem *kmi)
|
|
|
|
{
|
|
|
|
int kmitype= WM_userdef_event_map(kmi->type);
|
|
|
|
|
|
|
|
if(kmi->flag & KMI_INACTIVE) return 0;
|
2009-08-18 16:11:53 +00:00
|
|
|
|
2008-12-20 15:42:48 +00:00
|
|
|
/* the matching rules */
|
2009-01-23 14:43:25 +00:00
|
|
|
if(kmitype==KM_TEXTINPUT)
|
2011-10-20 11:18:57 +00:00
|
|
|
if(ISTEXTINPUT(winevent->type) && (winevent->ascii || winevent->utf8_buf[0])) return 1;
|
2009-01-23 14:43:25 +00:00
|
|
|
if(kmitype!=KM_ANY)
|
|
|
|
if(winevent->type!=kmitype) return 0;
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2008-12-08 15:02:57 +00:00
|
|
|
if(kmi->val!=KM_ANY)
|
|
|
|
if(winevent->val!=kmi->val) return 0;
|
2009-01-31 16:54:37 +00:00
|
|
|
|
|
|
|
/* modifiers also check bits, so it allows modifier order */
|
2008-12-22 12:57:53 +00:00
|
|
|
if(kmi->shift!=KM_ANY)
|
2009-01-31 16:54:37 +00:00
|
|
|
if(winevent->shift != kmi->shift && !(winevent->shift & kmi->shift)) return 0;
|
2008-12-22 12:57:53 +00:00
|
|
|
if(kmi->ctrl!=KM_ANY)
|
2009-01-31 16:54:37 +00:00
|
|
|
if(winevent->ctrl != kmi->ctrl && !(winevent->ctrl & kmi->ctrl)) return 0;
|
2008-12-22 12:57:53 +00:00
|
|
|
if(kmi->alt!=KM_ANY)
|
2009-01-31 16:54:37 +00:00
|
|
|
if(winevent->alt != kmi->alt && !(winevent->alt & kmi->alt)) return 0;
|
2008-12-22 12:57:53 +00:00
|
|
|
if(kmi->oskey!=KM_ANY)
|
2009-01-31 16:54:37 +00:00
|
|
|
if(winevent->oskey != kmi->oskey && !(winevent->oskey & kmi->oskey)) return 0;
|
2009-08-16 17:42:09 +00:00
|
|
|
|
2008-12-08 15:02:57 +00:00
|
|
|
if(kmi->keymodifier)
|
|
|
|
if(winevent->keymodifier!=kmi->keymodifier) return 0;
|
2009-08-16 17:42:09 +00:00
|
|
|
|
|
|
|
/* key modifiers always check when event has it */
|
|
|
|
/* otherwise regular keypresses with keymodifier still work */
|
|
|
|
if(winevent->keymodifier)
|
2009-09-21 16:39:07 +00:00
|
|
|
if(ISTEXTINPUT(winevent->type))
|
2009-08-16 17:42:09 +00:00
|
|
|
if(winevent->keymodifier!=kmi->keymodifier) return 0;
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2008-12-18 19:41:36 +00:00
|
|
|
|
2.5
Modal keymaps.
I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support.
The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way.
This system also allows to still handle hardcoded own events.
Tech doc:
1) define keymap
- Create map with unique name, WM_modalkeymap_add()
- Give map property definitions (EnumPropertyItem *)
This only for UI, so user can get information on available options
2) items
- WM_modalkeymap_add_item(): give it an enum value for events
3) activate
- In keymap definition code, assign the modal keymap to operatortype
WM_modalkeymap_assign()
4) event manager
- The event handler will check for modal keymap, if so:
- If the modal map has a match:
- Sets event->type to EVT_MODAL_MAP
- Sets event->val to the enum value
5) modal handler
- If event type is EVT_MODAL_MAP:
- Check event->val, handle it
- Other events can just be handled still
Two examples added in the code:
editors/transform/transform.c: transform_modal_keymap()
editors/screen/screen_ops.c: keymap_modal_set()
Also: to support 'key release' the define KM_RELEASE now is officially
used in event manager, this is not '0', so don't check key events with
the old convention if(event->val) but use if(event->val==KM_PRESS)
2009-07-21 11:03:07 +00:00
|
|
|
/* operator exists */
|
2009-11-15 19:25:34 +00:00
|
|
|
static void wm_event_modalkeymap(const bContext *C, wmOperator *op, wmEvent *event)
|
2.5
Modal keymaps.
I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support.
The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way.
This system also allows to still handle hardcoded own events.
Tech doc:
1) define keymap
- Create map with unique name, WM_modalkeymap_add()
- Give map property definitions (EnumPropertyItem *)
This only for UI, so user can get information on available options
2) items
- WM_modalkeymap_add_item(): give it an enum value for events
3) activate
- In keymap definition code, assign the modal keymap to operatortype
WM_modalkeymap_assign()
4) event manager
- The event handler will check for modal keymap, if so:
- If the modal map has a match:
- Sets event->type to EVT_MODAL_MAP
- Sets event->val to the enum value
5) modal handler
- If event type is EVT_MODAL_MAP:
- Check event->val, handle it
- Other events can just be handled still
Two examples added in the code:
editors/transform/transform.c: transform_modal_keymap()
editors/screen/screen_ops.c: keymap_modal_set()
Also: to support 'key release' the define KM_RELEASE now is officially
used in event manager, this is not '0', so don't check key events with
the old convention if(event->val) but use if(event->val==KM_PRESS)
2009-07-21 11:03:07 +00:00
|
|
|
{
|
2009-11-18 17:08:29 +00:00
|
|
|
/* support for modal keymap in macros */
|
|
|
|
if (op->opm)
|
|
|
|
op = op->opm;
|
|
|
|
|
2.5
Modal keymaps.
I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support.
The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way.
This system also allows to still handle hardcoded own events.
Tech doc:
1) define keymap
- Create map with unique name, WM_modalkeymap_add()
- Give map property definitions (EnumPropertyItem *)
This only for UI, so user can get information on available options
2) items
- WM_modalkeymap_add_item(): give it an enum value for events
3) activate
- In keymap definition code, assign the modal keymap to operatortype
WM_modalkeymap_assign()
4) event manager
- The event handler will check for modal keymap, if so:
- If the modal map has a match:
- Sets event->type to EVT_MODAL_MAP
- Sets event->val to the enum value
5) modal handler
- If event type is EVT_MODAL_MAP:
- Check event->val, handle it
- Other events can just be handled still
Two examples added in the code:
editors/transform/transform.c: transform_modal_keymap()
editors/screen/screen_ops.c: keymap_modal_set()
Also: to support 'key release' the define KM_RELEASE now is officially
used in event manager, this is not '0', so don't check key events with
the old convention if(event->val) but use if(event->val==KM_PRESS)
2009-07-21 11:03:07 +00:00
|
|
|
if(op->type->modalkeymap) {
|
2009-11-15 19:25:34 +00:00
|
|
|
wmKeyMap *keymap= WM_keymap_active(CTX_wm_manager(C), op->type->modalkeymap);
|
Key Configuration
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
|
|
|
wmKeyMapItem *kmi;
|
2009-11-15 19:25:34 +00:00
|
|
|
|
|
|
|
for(kmi= keymap->items.first; kmi; kmi= kmi->next) {
|
2.5
Modal keymaps.
I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support.
The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way.
This system also allows to still handle hardcoded own events.
Tech doc:
1) define keymap
- Create map with unique name, WM_modalkeymap_add()
- Give map property definitions (EnumPropertyItem *)
This only for UI, so user can get information on available options
2) items
- WM_modalkeymap_add_item(): give it an enum value for events
3) activate
- In keymap definition code, assign the modal keymap to operatortype
WM_modalkeymap_assign()
4) event manager
- The event handler will check for modal keymap, if so:
- If the modal map has a match:
- Sets event->type to EVT_MODAL_MAP
- Sets event->val to the enum value
5) modal handler
- If event type is EVT_MODAL_MAP:
- Check event->val, handle it
- Other events can just be handled still
Two examples added in the code:
editors/transform/transform.c: transform_modal_keymap()
editors/screen/screen_ops.c: keymap_modal_set()
Also: to support 'key release' the define KM_RELEASE now is officially
used in event manager, this is not '0', so don't check key events with
the old convention if(event->val) but use if(event->val==KM_PRESS)
2009-07-21 11:03:07 +00:00
|
|
|
if(wm_eventmatch(event, kmi)) {
|
|
|
|
|
|
|
|
event->type= EVT_MODAL_MAP;
|
|
|
|
event->val= kmi->propvalue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
/* Warning: this function removes a modal handler, when finished */
|
2009-01-01 20:44:40 +00:00
|
|
|
static int wm_handler_operator_call(bContext *C, ListBase *handlers, wmEventHandler *handler, wmEvent *event, PointerRNA *properties)
|
2007-12-24 18:27:28 +00:00
|
|
|
{
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
int retval= OPERATOR_PASS_THROUGH;
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
/* derived, modal or blocking operator */
|
|
|
|
if(handler->op) {
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
wmOperator *op= handler->op;
|
|
|
|
wmOperatorType *ot= op->type;
|
|
|
|
|
|
|
|
if(ot->modal) {
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
/* we set context to where modal handler came from */
|
2010-01-29 13:06:50 +00:00
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
2008-12-18 02:56:48 +00:00
|
|
|
ScrArea *area= CTX_wm_area(C);
|
|
|
|
ARegion *region= CTX_wm_region(C);
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
wm_handler_op_context(C, handler);
|
2009-02-19 19:03:53 +00:00
|
|
|
wm_region_mouse_co(C, event);
|
2009-11-15 19:25:34 +00:00
|
|
|
wm_event_modalkeymap(C, op, event);
|
2.5
Modal keymaps.
I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support.
The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way.
This system also allows to still handle hardcoded own events.
Tech doc:
1) define keymap
- Create map with unique name, WM_modalkeymap_add()
- Give map property definitions (EnumPropertyItem *)
This only for UI, so user can get information on available options
2) items
- WM_modalkeymap_add_item(): give it an enum value for events
3) activate
- In keymap definition code, assign the modal keymap to operatortype
WM_modalkeymap_assign()
4) event manager
- The event handler will check for modal keymap, if so:
- If the modal map has a match:
- Sets event->type to EVT_MODAL_MAP
- Sets event->val to the enum value
5) modal handler
- If event type is EVT_MODAL_MAP:
- Check event->val, handle it
- Other events can just be handled still
Two examples added in the code:
editors/transform/transform.c: transform_modal_keymap()
editors/screen/screen_ops.c: keymap_modal_set()
Also: to support 'key release' the define KM_RELEASE now is officially
used in event manager, this is not '0', so don't check key events with
the old convention if(event->val) but use if(event->val==KM_PRESS)
2009-07-21 11:03:07 +00:00
|
|
|
|
2010-01-29 13:06:50 +00:00
|
|
|
if(ot->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth++;
|
|
|
|
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
retval= ot->modal(C, op, event);
|
2011-08-25 16:42:42 +00:00
|
|
|
OPERATOR_RETVAL_CHECK(retval);
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
|
2011-09-28 15:42:55 +00:00
|
|
|
/* when this is _not_ the case the modal modifier may have loaded
|
|
|
|
* a new blend file (demo mode does this), so we have to assume
|
|
|
|
* the event, operator etc have all been freed. - campbell */
|
|
|
|
if(CTX_wm_manager(C) == wm) {
|
2010-01-29 13:06:50 +00:00
|
|
|
|
2011-09-28 15:42:55 +00:00
|
|
|
if(ot->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth--;
|
Made modal operators print their operator string after executing
(when in debug "-d" mode only)
copy & paste duplicate and transform operations can now be copied from user input and pasted into ./test.py and run with the Pkey (fixed some minor bugs preventing this)
Would be nice if the "mode" setting used a proper RNA Enum rather then an int.
# example, duplicate and transform
bpyoperator.OBJECT_OT_add_duplicate(mode=1)
bpyoperator.TFM_OT_transform(mode=1, options=0, values=(-1.23989, 0.570745, 0, 0), constraint_orientation=0, constraint_mode=0, constraint_matrix=(0, 0, 0, 0, 0, 0, 0, 0, 0))
2009-01-18 07:35:44 +00:00
|
|
|
|
2011-09-28 15:42:55 +00:00
|
|
|
/* putting back screen context, reval can pass trough after modal failures! */
|
|
|
|
if((retval & OPERATOR_PASS_THROUGH) || wm_event_always_pass(event)) {
|
|
|
|
CTX_wm_area_set(C, area);
|
|
|
|
CTX_wm_region_set(C, region);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* this special cases is for areas and regions that get removed */
|
|
|
|
CTX_wm_area_set(C, NULL);
|
|
|
|
CTX_wm_region_set(C, NULL);
|
|
|
|
}
|
2009-07-09 16:05:01 +00:00
|
|
|
|
2011-09-28 15:42:55 +00:00
|
|
|
if(retval & (OPERATOR_CANCELLED|OPERATOR_FINISHED))
|
|
|
|
wm_operator_reports(C, op, retval, 0);
|
|
|
|
|
|
|
|
if(retval & OPERATOR_FINISHED) {
|
|
|
|
wm_operator_finished(C, op, 0);
|
|
|
|
handler->op= NULL;
|
|
|
|
}
|
|
|
|
else if(retval & (OPERATOR_CANCELLED|OPERATOR_FINISHED)) {
|
|
|
|
WM_operator_free(op);
|
|
|
|
handler->op= NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* remove modal handler, operator itself should have been cancelled and freed */
|
|
|
|
if(retval & (OPERATOR_CANCELLED|OPERATOR_FINISHED)) {
|
|
|
|
WM_cursor_ungrab(CTX_wm_window(C));
|
|
|
|
|
|
|
|
BLI_remlink(handlers, handler);
|
|
|
|
wm_event_free_handler(handler);
|
|
|
|
|
|
|
|
/* prevent silly errors from operator users */
|
|
|
|
//retval &= ~OPERATOR_PASS_THROUGH;
|
|
|
|
}
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
}
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
}
|
2008-01-10 17:38:17 +00:00
|
|
|
else
|
|
|
|
printf("wm_handler_operator_call error\n");
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
|
|
|
else {
|
2009-07-13 08:33:51 +00:00
|
|
|
wmOperatorType *ot= WM_operatortype_find(event->keymap_idname, 0);
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
if(ot)
|
2010-11-04 12:59:03 +00:00
|
|
|
retval= wm_operator_invoke(C, ot, event, properties, NULL, FALSE);
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
2009-11-24 05:03:44 +00:00
|
|
|
/* Finished and pass through flag as handled */
|
|
|
|
|
2011-10-01 13:46:20 +00:00
|
|
|
/* Finished and pass through flag as handled */
|
|
|
|
if(retval == (OPERATOR_FINISHED|OPERATOR_PASS_THROUGH))
|
|
|
|
return WM_HANDLER_HANDLED;
|
|
|
|
|
2009-11-29 16:49:26 +00:00
|
|
|
/* Modal unhandled, break */
|
|
|
|
if(retval == (OPERATOR_PASS_THROUGH|OPERATOR_RUNNING_MODAL))
|
|
|
|
return (WM_HANDLER_BREAK|WM_HANDLER_MODAL);
|
|
|
|
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
if(retval & OPERATOR_PASS_THROUGH)
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
return WM_HANDLER_CONTINUE;
|
|
|
|
|
|
|
|
return WM_HANDLER_BREAK;
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
/* fileselect handlers are only in the window queue, so it's save to switch screens or area types */
|
|
|
|
static int wm_handler_fileselect_call(bContext *C, ListBase *handlers, wmEventHandler *handler, wmEvent *event)
|
|
|
|
{
|
2010-01-29 13:06:50 +00:00
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
2009-02-16 12:14:04 +00:00
|
|
|
SpaceFile *sfile;
|
|
|
|
int action= WM_HANDLER_CONTINUE;
|
|
|
|
|
|
|
|
if(event->type != EVT_FILESELECT)
|
|
|
|
return action;
|
|
|
|
if(handler->op != (wmOperator *)event->customdata)
|
|
|
|
return action;
|
|
|
|
|
|
|
|
switch(event->val) {
|
|
|
|
case EVT_FILESELECT_OPEN:
|
|
|
|
case EVT_FILESELECT_FULL_OPEN:
|
2009-09-12 19:54:39 +00:00
|
|
|
{
|
2009-12-17 10:01:08 +00:00
|
|
|
ScrArea *sa;
|
|
|
|
|
|
|
|
/* sa can be null when window A is active, but mouse is over window B */
|
|
|
|
/* in this case, open file select in original window A */
|
|
|
|
if (handler->op_area == NULL) {
|
|
|
|
bScreen *screen = CTX_wm_screen(C);
|
|
|
|
sa = (ScrArea *)screen->areabase.first;
|
2011-06-06 00:42:36 +00:00
|
|
|
}
|
|
|
|
else {
|
2009-12-17 10:01:08 +00:00
|
|
|
sa = handler->op_area;
|
2011-06-06 00:42:36 +00:00
|
|
|
}
|
2009-12-17 10:01:08 +00:00
|
|
|
|
2011-06-06 00:42:36 +00:00
|
|
|
if(event->val==EVT_FILESELECT_OPEN) {
|
|
|
|
ED_area_newspace(C, sa, SPACE_FILE); /* 'sa' is modified in-place */
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
sa= ED_screen_full_newspace(C, sa, SPACE_FILE); /* sets context */
|
|
|
|
}
|
|
|
|
|
|
|
|
/* note, getting the 'sa' back from the context causes a nasty bug where the newly created
|
|
|
|
* 'sa' != CTX_wm_area(C). removed the line below and set 'sa' in the 'if' above */
|
|
|
|
/* sa = CTX_wm_area(C); */
|
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
/* settings for filebrowser, sfile is not operator owner but sends events */
|
2009-12-17 10:01:08 +00:00
|
|
|
sfile= (SpaceFile*)sa->spacedata.first;
|
2009-02-16 12:14:04 +00:00
|
|
|
sfile->op= handler->op;
|
2009-06-04 20:07:06 +00:00
|
|
|
|
2009-07-27 19:06:33 +00:00
|
|
|
ED_fileselect_set_params(sfile);
|
2009-02-16 12:14:04 +00:00
|
|
|
|
|
|
|
action= WM_HANDLER_BREAK;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case EVT_FILESELECT_EXEC:
|
|
|
|
case EVT_FILESELECT_CANCEL:
|
2010-09-17 22:12:23 +00:00
|
|
|
case EVT_FILESELECT_EXTERNAL_CANCEL:
|
2009-02-16 12:14:04 +00:00
|
|
|
{
|
|
|
|
/* XXX validate area and region? */
|
|
|
|
bScreen *screen= CTX_wm_screen(C);
|
2010-09-17 22:12:23 +00:00
|
|
|
|
|
|
|
/* remlink now, for load file case before removing*/
|
2009-02-16 12:14:04 +00:00
|
|
|
BLI_remlink(handlers, handler);
|
|
|
|
|
2010-09-18 03:55:56 +00:00
|
|
|
if(event->val!=EVT_FILESELECT_EXTERNAL_CANCEL) {
|
|
|
|
if(screen != handler->filescreen) {
|
2010-09-17 22:12:23 +00:00
|
|
|
ED_screen_full_prevspace(C, CTX_wm_area(C));
|
2010-09-18 03:55:56 +00:00
|
|
|
}
|
|
|
|
else {
|
2010-09-17 22:12:23 +00:00
|
|
|
ED_area_prevspace(C, CTX_wm_area(C));
|
2010-09-18 03:55:56 +00:00
|
|
|
}
|
|
|
|
}
|
2010-09-17 22:12:23 +00:00
|
|
|
|
2009-10-01 23:32:57 +00:00
|
|
|
wm_handler_op_context(C, handler);
|
|
|
|
|
2010-01-11 11:59:14 +00:00
|
|
|
/* needed for uiPupMenuReports */
|
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
if(event->val==EVT_FILESELECT_EXEC) {
|
2010-09-17 09:27:31 +00:00
|
|
|
#if 0 // use REDALERT now
|
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
/* a bit weak, might become arg for WM_event_fileselect? */
|
2009-02-18 13:29:54 +00:00
|
|
|
/* XXX also extension code in image-save doesnt work for this yet */
|
2010-01-27 02:20:24 +00:00
|
|
|
if (RNA_struct_find_property(handler->op->ptr, "check_existing") &&
|
|
|
|
RNA_boolean_get(handler->op->ptr, "check_existing")) {
|
2010-07-02 20:09:42 +00:00
|
|
|
char *path= RNA_string_get_alloc(handler->op->ptr, "filepath", NULL, 0);
|
2009-02-16 12:14:04 +00:00
|
|
|
/* this gives ownership to pupmenu */
|
2009-09-28 16:11:06 +00:00
|
|
|
uiPupMenuSaveOver(C, handler->op, (path)? path: "");
|
2010-07-02 20:09:42 +00:00
|
|
|
if(path)
|
|
|
|
MEM_freeN(path);
|
2009-02-16 12:14:04 +00:00
|
|
|
}
|
2010-09-17 09:27:31 +00:00
|
|
|
else
|
|
|
|
#endif
|
|
|
|
{
|
2010-01-29 13:06:50 +00:00
|
|
|
int retval;
|
|
|
|
|
|
|
|
if(handler->op->type->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth++;
|
|
|
|
|
|
|
|
retval= handler->op->type->exec(C, handler->op);
|
|
|
|
|
2010-11-15 16:26:30 +00:00
|
|
|
/* XXX check this carefully, CTX_wm_manager(C) == wm is a bit hackish */
|
2010-04-20 14:58:46 +00:00
|
|
|
if(handler->op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
|
2010-01-29 13:06:50 +00:00
|
|
|
wm->op_undo_depth--;
|
2009-06-05 16:11:35 +00:00
|
|
|
|
|
|
|
if (retval & OPERATOR_FINISHED)
|
|
|
|
if(G.f & G_DEBUG)
|
2010-12-13 06:54:25 +00:00
|
|
|
wm_operator_print(C, handler->op);
|
2009-06-05 16:11:35 +00:00
|
|
|
|
2010-11-15 16:26:30 +00:00
|
|
|
/* XXX check this carefully, CTX_wm_manager(C) == wm is a bit hackish */
|
|
|
|
if(CTX_wm_manager(C) == wm && wm->op_undo_depth == 0)
|
2010-02-17 12:21:38 +00:00
|
|
|
if(handler->op->type->flag & OPTYPE_UNDO)
|
|
|
|
ED_undo_push_op(C, handler->op);
|
|
|
|
|
2010-01-11 11:59:14 +00:00
|
|
|
if(handler->op->reports->list.first) {
|
|
|
|
|
|
|
|
/* FIXME, temp setting window, this is really bad!
|
|
|
|
* only have because lib linking errors need to be seen by users :(
|
|
|
|
* it can be removed without breaking anything but then no linking errors - campbell */
|
|
|
|
wmWindow *win_prev= CTX_wm_window(C);
|
2011-09-07 11:53:16 +00:00
|
|
|
ScrArea *area_prev= CTX_wm_area(C);
|
|
|
|
ARegion *ar_prev= CTX_wm_region(C);
|
|
|
|
|
2010-01-11 11:59:14 +00:00
|
|
|
if(win_prev==NULL)
|
|
|
|
CTX_wm_window_set(C, CTX_wm_manager(C)->windows.first);
|
|
|
|
|
|
|
|
handler->op->reports->printlevel = RPT_WARNING;
|
|
|
|
uiPupMenuReports(C, handler->op->reports);
|
|
|
|
|
2010-04-08 11:46:52 +00:00
|
|
|
/* XXX - copied from 'wm_operator_finished()' */
|
|
|
|
/* add reports to the global list, otherwise they are not seen */
|
2010-12-21 14:49:34 +00:00
|
|
|
BLI_movelisttolist(&CTX_wm_reports(C)->list, &handler->op->reports->list);
|
2010-04-08 11:46:52 +00:00
|
|
|
|
2010-01-11 11:59:14 +00:00
|
|
|
CTX_wm_window_set(C, win_prev);
|
2011-09-07 11:53:16 +00:00
|
|
|
CTX_wm_area_set(C, area_prev);
|
|
|
|
CTX_wm_region_set(C, ar_prev);
|
2010-01-11 11:59:14 +00:00
|
|
|
}
|
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
WM_operator_free(handler->op);
|
|
|
|
}
|
|
|
|
}
|
2009-10-01 23:32:57 +00:00
|
|
|
else {
|
2010-01-29 13:06:50 +00:00
|
|
|
if(handler->op->type->cancel) {
|
|
|
|
if(handler->op->type->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth++;
|
|
|
|
|
2009-10-01 23:32:57 +00:00
|
|
|
handler->op->type->cancel(C, handler->op);
|
|
|
|
|
2010-01-29 13:06:50 +00:00
|
|
|
if(handler->op->type->flag & OPTYPE_UNDO)
|
|
|
|
wm->op_undo_depth--;
|
|
|
|
}
|
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
WM_operator_free(handler->op);
|
2009-10-01 23:32:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
CTX_wm_area_set(C, NULL);
|
2009-02-16 12:14:04 +00:00
|
|
|
|
|
|
|
wm_event_free_handler(handler);
|
|
|
|
|
|
|
|
action= WM_HANDLER_BREAK;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return action;
|
|
|
|
}
|
|
|
|
|
2008-12-10 13:56:54 +00:00
|
|
|
static int handler_boundbox_test(wmEventHandler *handler, wmEvent *event)
|
|
|
|
{
|
|
|
|
if(handler->bbwin) {
|
|
|
|
if(handler->bblocal) {
|
|
|
|
rcti rect= *handler->bblocal;
|
|
|
|
BLI_translate_rcti(&rect, handler->bbwin->xmin, handler->bbwin->ymin);
|
2009-07-28 16:46:14 +00:00
|
|
|
|
|
|
|
if(BLI_in_rcti(&rect, event->x, event->y))
|
|
|
|
return 1;
|
|
|
|
else if(event->type==MOUSEMOVE && BLI_in_rcti(&rect, event->prevx, event->prevy))
|
|
|
|
return 1;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
if(BLI_in_rcti(handler->bbwin, event->x, event->y))
|
|
|
|
return 1;
|
|
|
|
else if(event->type==MOUSEMOVE && BLI_in_rcti(handler->bbwin, event->prevx, event->prevy))
|
|
|
|
return 1;
|
|
|
|
else
|
|
|
|
return 0;
|
2008-12-10 13:56:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-12-10 23:24:29 +00:00
|
|
|
static int wm_action_not_handled(int action)
|
|
|
|
{
|
|
|
|
return action == WM_HANDLER_CONTINUE || action == (WM_HANDLER_BREAK|WM_HANDLER_MODAL);
|
|
|
|
}
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
static int wm_handlers_do(bContext *C, wmEvent *event, ListBase *handlers)
|
|
|
|
{
|
Key Configuration
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
wmEventHandler *handler, *nexthandler;
|
2007-12-24 18:27:28 +00:00
|
|
|
int action= WM_HANDLER_CONTINUE;
|
2009-07-01 22:16:16 +00:00
|
|
|
int always_pass;
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
if(handlers==NULL) return action;
|
2009-09-24 10:35:04 +00:00
|
|
|
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
/* modal handlers can get removed in this loop, we keep the loop this way */
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
for(handler= handlers->first; handler; handler= nexthandler) {
|
2011-04-20 11:15:58 +00:00
|
|
|
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
nexthandler= handler->next;
|
2011-04-20 11:15:58 +00:00
|
|
|
|
|
|
|
/* during this loop, ui handlers for nested menus can tag multiple handlers free */
|
|
|
|
if(handler->flag & WM_HANDLER_DO_FREE);
|
|
|
|
/* optional boundbox */
|
|
|
|
else if(handler_boundbox_test(handler, event)) {
|
2009-07-01 22:16:16 +00:00
|
|
|
/* in advance to avoid access to freed event on window close */
|
|
|
|
always_pass= wm_event_always_pass(event);
|
2008-12-10 13:56:54 +00:00
|
|
|
|
|
|
|
/* modal+blocking handler */
|
|
|
|
if(handler->flag & WM_HANDLER_BLOCKING)
|
2009-11-24 05:03:44 +00:00
|
|
|
action |= WM_HANDLER_BREAK;
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
|
2008-12-10 13:56:54 +00:00
|
|
|
if(handler->keymap) {
|
Key Configuration
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
|
|
|
wmKeyMap *keymap= WM_keymap_active(wm, handler->keymap);
|
|
|
|
wmKeyMapItem *kmi;
|
2008-12-10 13:56:54 +00:00
|
|
|
|
2009-09-17 21:36:02 +00:00
|
|
|
if(!keymap->poll || keymap->poll(C)) {
|
Key Configuration
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
|
|
|
for(kmi= keymap->items.first; kmi; kmi= kmi->next) {
|
2009-09-17 21:36:02 +00:00
|
|
|
if(wm_eventmatch(event, kmi)) {
|
|
|
|
|
|
|
|
event->keymap_idname= kmi->idname; /* weak, but allows interactive callback to not use rawkey */
|
|
|
|
|
2009-11-24 05:03:44 +00:00
|
|
|
action |= wm_handler_operator_call(C, handlers, handler, event, kmi->ptr);
|
|
|
|
if(action & WM_HANDLER_BREAK) /* not always_pass here, it denotes removed handler */
|
2009-09-17 21:36:02 +00:00
|
|
|
break;
|
|
|
|
}
|
2008-12-10 13:56:54 +00:00
|
|
|
}
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
|
|
|
}
|
2008-12-10 13:56:54 +00:00
|
|
|
else if(handler->ui_handle) {
|
2010-01-31 23:33:04 +00:00
|
|
|
action |= wm_handler_ui_call(C, handler, event, always_pass);
|
2008-12-10 13:56:54 +00:00
|
|
|
}
|
2009-02-16 12:14:04 +00:00
|
|
|
else if(handler->type==WM_HANDLER_FILESELECT) {
|
|
|
|
/* screen context changes here */
|
2009-11-24 05:03:44 +00:00
|
|
|
action |= wm_handler_fileselect_call(C, handlers, handler, event);
|
2009-02-16 12:14:04 +00:00
|
|
|
}
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
else if(handler->dropboxes) {
|
|
|
|
if(event->type==EVT_DROP) {
|
|
|
|
wmDropBox *drop= handler->dropboxes->first;
|
|
|
|
for(; drop; drop= drop->next) {
|
|
|
|
/* other drop custom types allowed */
|
|
|
|
if(event->custom==EVT_DATA_LISTBASE) {
|
|
|
|
ListBase *lb= (ListBase *)event->customdata;
|
|
|
|
wmDrag *drag;
|
2011-01-19 18:07:13 +00:00
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
for(drag= lb->first; drag; drag= drag->next) {
|
|
|
|
if(drop->poll(C, drag, event)) {
|
2011-01-19 18:07:13 +00:00
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
drop->copy(drag, drop);
|
|
|
|
|
2011-01-19 18:07:13 +00:00
|
|
|
/* free the drags before calling operator */
|
|
|
|
BLI_freelistN(event->customdata);
|
|
|
|
event->customdata= NULL;
|
|
|
|
event->custom= 0;
|
|
|
|
|
2010-12-17 19:05:34 +00:00
|
|
|
WM_operator_name_call(C, drop->ot->idname, drop->opcontext, drop->ptr);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
action |= WM_HANDLER_BREAK;
|
2010-12-17 19:05:34 +00:00
|
|
|
|
2011-01-03 17:00:49 +00:00
|
|
|
/* XXX fileread case */
|
|
|
|
if(CTX_wm_window(C)==NULL)
|
|
|
|
return action;
|
|
|
|
|
2011-01-19 18:07:13 +00:00
|
|
|
/* escape from drag loop, got freed */
|
|
|
|
break;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2008-12-10 13:56:54 +00:00
|
|
|
else {
|
|
|
|
/* modal, swallows all */
|
2009-11-24 05:03:44 +00:00
|
|
|
action |= wm_handler_operator_call(C, handlers, handler, event, NULL);
|
2008-12-10 13:56:54 +00:00
|
|
|
}
|
2008-01-19 17:54:05 +00:00
|
|
|
|
2009-11-24 05:03:44 +00:00
|
|
|
if(action & WM_HANDLER_BREAK) {
|
2009-09-18 12:43:36 +00:00
|
|
|
if(always_pass)
|
2009-11-24 05:03:44 +00:00
|
|
|
action &= ~WM_HANDLER_BREAK;
|
2009-09-18 12:43:36 +00:00
|
|
|
else
|
|
|
|
break;
|
|
|
|
}
|
2008-12-10 13:56:54 +00:00
|
|
|
}
|
2008-01-19 17:54:05 +00:00
|
|
|
|
2011-04-23 03:31:27 +00:00
|
|
|
/* XXX fileread case, if the wm is freed then the handler's
|
|
|
|
* will have been too so the code below need not run. */
|
|
|
|
if(CTX_wm_window(C)==NULL) {
|
|
|
|
return action;
|
|
|
|
}
|
|
|
|
|
2011-04-21 09:43:38 +00:00
|
|
|
/* XXX code this for all modal ops, and ensure free only happens here */
|
2011-04-20 20:46:02 +00:00
|
|
|
|
2011-04-21 09:43:38 +00:00
|
|
|
/* modal ui handler can be tagged to be freed */
|
|
|
|
if(BLI_findindex(handlers, handler) != -1) { /* could be free'd already by regular modal ops */
|
|
|
|
if(handler->flag & WM_HANDLER_DO_FREE) {
|
2011-04-20 20:46:02 +00:00
|
|
|
BLI_remlink(handlers, handler);
|
|
|
|
wm_event_free_handler(handler);
|
|
|
|
}
|
2011-04-20 11:15:58 +00:00
|
|
|
}
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
2009-11-23 16:24:28 +00:00
|
|
|
|
|
|
|
/* test for CLICK event */
|
2009-12-10 23:24:29 +00:00
|
|
|
if (wm_action_not_handled(action) && event->val == KM_RELEASE) {
|
2009-11-23 16:24:28 +00:00
|
|
|
wmWindow *win = CTX_wm_window(C);
|
|
|
|
|
2009-12-19 14:58:24 +00:00
|
|
|
if (win && win->eventstate->prevtype == event->type && win->eventstate->prevval == KM_PRESS) {
|
2010-10-18 00:25:32 +00:00
|
|
|
/* test for double click first,
|
|
|
|
* note1: this can be problematic because single click operators can get the
|
|
|
|
* double click event but then with old mouse coords which is highly confusing,
|
|
|
|
* so check for mouse moves too.
|
|
|
|
* note2: the first click event will be handled but still used to create a
|
|
|
|
* double click event if clicking again quickly.
|
2011-06-06 00:48:10 +00:00
|
|
|
* If no double click events are found it will fallback to a single click.
|
2010-10-18 00:25:32 +00:00
|
|
|
* So a double click event can result in 2 successive single click calls
|
|
|
|
* if its not handled by the keymap - campbell */
|
|
|
|
if ( (ABS(event->x - win->eventstate->prevclickx)) <= 2 &&
|
|
|
|
(ABS(event->y - win->eventstate->prevclicky)) <= 2 &&
|
|
|
|
((PIL_check_seconds_timer() - win->eventstate->prevclicktime) * 1000 < U.dbl_click_time)
|
|
|
|
) {
|
2009-12-10 17:41:03 +00:00
|
|
|
event->val = KM_DBL_CLICK;
|
2010-10-18 00:25:32 +00:00
|
|
|
/* removed this because in cases where we're this is used as a single click
|
|
|
|
* event, this will give old coords, since the distance is checked above, using new coords should be ok. */
|
|
|
|
// event->x = win->eventstate->prevclickx;
|
|
|
|
// event->y = win->eventstate->prevclicky;
|
2009-12-10 17:41:03 +00:00
|
|
|
action |= wm_handlers_do(C, event, handlers);
|
|
|
|
}
|
|
|
|
|
2009-12-10 23:24:29 +00:00
|
|
|
if (wm_action_not_handled(action)) {
|
|
|
|
event->val = KM_CLICK;
|
|
|
|
action |= wm_handlers_do(C, event, handlers);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-11-23 16:24:28 +00:00
|
|
|
/* revert value if not handled */
|
2009-12-10 23:24:29 +00:00
|
|
|
if (wm_action_not_handled(action)) {
|
2009-11-23 16:24:28 +00:00
|
|
|
event->val = KM_RELEASE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-03-07 14:56:19 +00:00
|
|
|
|
|
|
|
if(action == (WM_HANDLER_BREAK|WM_HANDLER_MODAL))
|
|
|
|
wm_cursor_arrow_move(CTX_wm_window(C), event);
|
2009-11-23 16:24:28 +00:00
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
return action;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int wm_event_inside_i(wmEvent *event, rcti *rect)
|
2008-12-02 18:49:58 +00:00
|
|
|
{
|
2009-09-18 12:43:36 +00:00
|
|
|
if(wm_event_always_pass(event))
|
|
|
|
return 1;
|
2008-12-02 18:49:58 +00:00
|
|
|
if(BLI_in_rcti(rect, event->x, event->y))
|
2011-04-21 15:53:30 +00:00
|
|
|
return 1;
|
2008-12-02 18:49:58 +00:00
|
|
|
if(event->type==MOUSEMOVE) {
|
|
|
|
if( BLI_in_rcti(rect, event->prevx, event->prevy)) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
static ScrArea *area_event_inside(bContext *C, int x, int y)
|
2.5 getting-back-into-coding commit :)
- cleaned up join and split operations. Most noticable is operator callback
design, which should make a design based on user-less exec() first, then
wrap invoke() and modal() around it. The exec() should be callable with
only Context and properties.
- split now works again; and inversed as previously, if you drag from a
triangle (action zone) inside area it subdivides area as expected.
- dragging from triangle outside area, over an edge, joins areas
- split has been simplified, it had too many options... it could just work
simpler (now)
- 'action zone' now is an operator itself, a widget sending an ACTIONZONE event,
which can be handled by others (so other gestures can be added in action zone
too)
Still evaluating:
- context gets set where?
- code structure confuses... what are proper functions for operators?
- what is WM... should low level screen stuff more there?
- when do you send event, notifier?
- files grow to large, will clean
Oh yeah and docs, docs, docs. Coming! :)
2008-11-17 18:54:03 +00:00
|
|
|
{
|
2008-12-18 02:56:48 +00:00
|
|
|
bScreen *screen= CTX_wm_screen(C);
|
2.5 getting-back-into-coding commit :)
- cleaned up join and split operations. Most noticable is operator callback
design, which should make a design based on user-less exec() first, then
wrap invoke() and modal() around it. The exec() should be callable with
only Context and properties.
- split now works again; and inversed as previously, if you drag from a
triangle (action zone) inside area it subdivides area as expected.
- dragging from triangle outside area, over an edge, joins areas
- split has been simplified, it had too many options... it could just work
simpler (now)
- 'action zone' now is an operator itself, a widget sending an ACTIONZONE event,
which can be handled by others (so other gestures can be added in action zone
too)
Still evaluating:
- context gets set where?
- code structure confuses... what are proper functions for operators?
- what is WM... should low level screen stuff more there?
- when do you send event, notifier?
- files grow to large, will clean
Oh yeah and docs, docs, docs. Coming! :)
2008-11-17 18:54:03 +00:00
|
|
|
ScrArea *sa;
|
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
if(screen)
|
|
|
|
for(sa= screen->areabase.first; sa; sa= sa->next)
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
if(BLI_in_rcti(&sa->totrct, x, y))
|
2.5 getting-back-into-coding commit :)
- cleaned up join and split operations. Most noticable is operator callback
design, which should make a design based on user-less exec() first, then
wrap invoke() and modal() around it. The exec() should be callable with
only Context and properties.
- split now works again; and inversed as previously, if you drag from a
triangle (action zone) inside area it subdivides area as expected.
- dragging from triangle outside area, over an edge, joins areas
- split has been simplified, it had too many options... it could just work
simpler (now)
- 'action zone' now is an operator itself, a widget sending an ACTIONZONE event,
which can be handled by others (so other gestures can be added in action zone
too)
Still evaluating:
- context gets set where?
- code structure confuses... what are proper functions for operators?
- what is WM... should low level screen stuff more there?
- when do you send event, notifier?
- files grow to large, will clean
Oh yeah and docs, docs, docs. Coming! :)
2008-11-17 18:54:03 +00:00
|
|
|
return sa;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
static ARegion *region_event_inside(bContext *C, int x, int y)
|
2008-12-04 09:37:42 +00:00
|
|
|
{
|
2008-12-18 02:56:48 +00:00
|
|
|
bScreen *screen= CTX_wm_screen(C);
|
|
|
|
ScrArea *area= CTX_wm_area(C);
|
2008-12-04 09:37:42 +00:00
|
|
|
ARegion *ar;
|
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
if(screen && area)
|
|
|
|
for(ar= area->regionbase.first; ar; ar= ar->next)
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
if(BLI_in_rcti(&ar->winrct, x, y))
|
2008-12-04 09:37:42 +00:00
|
|
|
return ar;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
static void wm_paintcursor_tag(bContext *C, wmPaintCursor *pc, ARegion *ar)
|
|
|
|
{
|
2.5: WM Compositing
* Triple Buffer is now more complete:
- Proper handling of window resize, duplicate, etc.
- It now uses 3x3 textures (or less) if the power of two sizes
do not match well. That still has a worst case wast of 23.4%,
but better than 300%.
- It can also use the ARB/NV/EXT_texture_rectangle extension
now, which may be supported on hardware that does not support
ARB_texture_non_power_of_two.
- Gesture, menu and brushe redraws now require no redraws at all
from the area regions. So even on a high poly scene just moving
the paint cursor or opening a menu should be fast.
* Testing can be done by setting the "Window Draw Method" in the
User Preferences in the outliner. "Overlap" is still default,
since "Triple Buffer" has not been tested on computers other than
mine, would like to avoid crashing Blender on startup in case
there is a common bug, but it's ready for testing now.
- For reference "Full" draws the full window each time.
- "Triple Buffer" should work for both swap copy and swap exchange
systems, the latter still need the -E command line option for
"Overlap".
- Resizing and going fullscreen still gives flicker here but no
more than "Full" drawing.
* Partial Redraw was added. ED_region_tag_redraw_partial takes a
rect in window coordinates to define a subarea of the region.
On region draw it will then set glScissor to a smaller area, and
ar->drawrct will always be set to either the partial or full
window rect. The latter can then be used for clipping in the 3D
view or clipping interface drawing. Neither is implemented yet.
2009-01-23 03:52:52 +00:00
|
|
|
if(ar) {
|
|
|
|
for(; pc; pc= pc->next) {
|
2010-01-27 09:36:28 +00:00
|
|
|
if(pc->poll == NULL || pc->poll(C)) {
|
2.5: WM Compositing
* Triple Buffer is now more complete:
- Proper handling of window resize, duplicate, etc.
- It now uses 3x3 textures (or less) if the power of two sizes
do not match well. That still has a worst case wast of 23.4%,
but better than 300%.
- It can also use the ARB/NV/EXT_texture_rectangle extension
now, which may be supported on hardware that does not support
ARB_texture_non_power_of_two.
- Gesture, menu and brushe redraws now require no redraws at all
from the area regions. So even on a high poly scene just moving
the paint cursor or opening a menu should be fast.
* Testing can be done by setting the "Window Draw Method" in the
User Preferences in the outliner. "Overlap" is still default,
since "Triple Buffer" has not been tested on computers other than
mine, would like to avoid crashing Blender on startup in case
there is a common bug, but it's ready for testing now.
- For reference "Full" draws the full window each time.
- "Triple Buffer" should work for both swap copy and swap exchange
systems, the latter still need the -E command line option for
"Overlap".
- Resizing and going fullscreen still gives flicker here but no
more than "Full" drawing.
* Partial Redraw was added. ED_region_tag_redraw_partial takes a
rect in window coordinates to define a subarea of the region.
On region draw it will then set glScissor to a smaller area, and
ar->drawrct will always be set to either the partial or full
window rect. The latter can then be used for clipping in the 3D
view or clipping interface drawing. Neither is implemented yet.
2009-01-23 03:52:52 +00:00
|
|
|
wmWindow *win= CTX_wm_window(C);
|
|
|
|
win->screen->do_draw_paintcursor= 1;
|
2010-03-22 11:59:36 +00:00
|
|
|
wm_tag_redraw_overlay(win, ar);
|
2.5: WM Compositing
* Triple Buffer is now more complete:
- Proper handling of window resize, duplicate, etc.
- It now uses 3x3 textures (or less) if the power of two sizes
do not match well. That still has a worst case wast of 23.4%,
but better than 300%.
- It can also use the ARB/NV/EXT_texture_rectangle extension
now, which may be supported on hardware that does not support
ARB_texture_non_power_of_two.
- Gesture, menu and brushe redraws now require no redraws at all
from the area regions. So even on a high poly scene just moving
the paint cursor or opening a menu should be fast.
* Testing can be done by setting the "Window Draw Method" in the
User Preferences in the outliner. "Overlap" is still default,
since "Triple Buffer" has not been tested on computers other than
mine, would like to avoid crashing Blender on startup in case
there is a common bug, but it's ready for testing now.
- For reference "Full" draws the full window each time.
- "Triple Buffer" should work for both swap copy and swap exchange
systems, the latter still need the -E command line option for
"Overlap".
- Resizing and going fullscreen still gives flicker here but no
more than "Full" drawing.
* Partial Redraw was added. ED_region_tag_redraw_partial takes a
rect in window coordinates to define a subarea of the region.
On region draw it will then set glScissor to a smaller area, and
ar->drawrct will always be set to either the partial or full
window rect. The latter can then be used for clipping in the 3D
view or clipping interface drawing. Neither is implemented yet.
2009-01-23 03:52:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* called on mousemove, check updates for paintcursors */
|
|
|
|
/* context was set on active area and region */
|
|
|
|
static void wm_paintcursor_test(bContext *C, wmEvent *event)
|
|
|
|
{
|
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
|
|
|
|
|
|
|
if(wm->paintcursors.first) {
|
|
|
|
ARegion *ar= CTX_wm_region(C);
|
2011-03-04 18:39:58 +00:00
|
|
|
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
if(ar)
|
|
|
|
wm_paintcursor_tag(C, wm->paintcursors.first, ar);
|
|
|
|
|
|
|
|
/* if previous position was not in current region, we have to set a temp new context */
|
|
|
|
if(ar==NULL || !BLI_in_rcti(&ar->winrct, event->prevx, event->prevy)) {
|
|
|
|
ScrArea *sa= CTX_wm_area(C);
|
|
|
|
|
|
|
|
CTX_wm_area_set(C, area_event_inside(C, event->prevx, event->prevy));
|
|
|
|
CTX_wm_region_set(C, region_event_inside(C, event->prevx, event->prevy));
|
|
|
|
|
|
|
|
wm_paintcursor_tag(C, wm->paintcursors.first, CTX_wm_region(C));
|
|
|
|
|
|
|
|
CTX_wm_area_set(C, sa);
|
|
|
|
CTX_wm_region_set(C, ar);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2008-12-04 09:37:42 +00:00
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
static void wm_event_drag_test(wmWindowManager *wm, wmWindow *win, wmEvent *event)
|
|
|
|
{
|
|
|
|
if(wm->drags.first==NULL) return;
|
|
|
|
|
|
|
|
if(event->type==MOUSEMOVE)
|
|
|
|
win->screen->do_draw_drag= 1;
|
|
|
|
else if(event->type==ESCKEY) {
|
|
|
|
BLI_freelistN(&wm->drags);
|
|
|
|
win->screen->do_draw_drag= 1;
|
|
|
|
}
|
|
|
|
else if(event->type==LEFTMOUSE && event->val==KM_RELEASE) {
|
|
|
|
event->type= EVT_DROP;
|
|
|
|
|
|
|
|
/* create customdata, first free existing */
|
|
|
|
if(event->customdata) {
|
|
|
|
if(event->customdatafree)
|
|
|
|
MEM_freeN(event->customdata);
|
|
|
|
}
|
|
|
|
|
|
|
|
event->custom= EVT_DATA_LISTBASE;
|
|
|
|
event->customdata= &wm->drags;
|
|
|
|
event->customdatafree= 1;
|
|
|
|
|
|
|
|
/* clear drop icon */
|
|
|
|
win->screen->do_draw_drag= 1;
|
|
|
|
|
|
|
|
/* restore cursor (disabled, see wm_dragdrop.c) */
|
|
|
|
// WM_cursor_restore(win);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* overlap fails otherwise */
|
|
|
|
if(win->screen->do_draw_drag)
|
|
|
|
if(win->drawmethod == USER_DRAW_OVERLAP)
|
|
|
|
win->screen->do_draw= 1;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
/* called in main loop */
|
|
|
|
/* goes over entire hierarchy: events -> window -> screen -> area -> region */
|
|
|
|
void wm_event_do_handlers(bContext *C)
|
|
|
|
{
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
wmWindowManager *wm= CTX_wm_manager(C);
|
2007-12-24 18:27:28 +00:00
|
|
|
wmWindow *win;
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
/* update key configuration before handling events */
|
|
|
|
WM_keyconfig_update(wm);
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
for(win= wm->windows.first; win; win= win->next) {
|
2007-12-24 18:27:28 +00:00
|
|
|
wmEvent *event;
|
|
|
|
|
2008-01-07 18:03:41 +00:00
|
|
|
if( win->screen==NULL )
|
|
|
|
wm_event_free_all(win);
|
2010-04-08 13:12:53 +00:00
|
|
|
else {
|
2010-02-22 09:01:49 +00:00
|
|
|
Scene* scene = win->screen->scene;
|
2010-04-08 13:12:53 +00:00
|
|
|
|
|
|
|
if(scene) {
|
2010-02-21 18:01:41 +00:00
|
|
|
int playing = sound_scene_playing(win->screen->scene);
|
2010-04-08 13:12:53 +00:00
|
|
|
|
|
|
|
if(playing != -1) {
|
2010-02-22 09:01:49 +00:00
|
|
|
CTX_wm_window_set(C, win);
|
|
|
|
CTX_wm_screen_set(C, win->screen);
|
|
|
|
CTX_data_scene_set(C, scene);
|
2010-04-08 13:12:53 +00:00
|
|
|
|
|
|
|
if(((playing == 1) && (!win->screen->animtimer)) || ((playing == 0) && (win->screen->animtimer))){
|
2010-07-19 11:47:46 +00:00
|
|
|
ED_screen_animation_play(C, -1, 1);
|
2010-02-21 18:01:41 +00:00
|
|
|
}
|
2010-04-08 13:12:53 +00:00
|
|
|
|
|
|
|
if(playing == 0) {
|
2011-10-13 22:19:29 +00:00
|
|
|
float time = sound_sync_scene(scene);
|
2011-10-14 07:41:45 +00:00
|
|
|
if(finite(time)) {
|
2011-10-13 22:19:29 +00:00
|
|
|
int ncfra = sound_sync_scene(scene) * (float)FPS + 0.5f;
|
|
|
|
if(ncfra != scene->r.cfra) {
|
|
|
|
scene->r.cfra = ncfra;
|
|
|
|
ED_update_for_newframe(CTX_data_main(C), scene, win->screen, 1);
|
|
|
|
WM_event_add_notifier(C, NC_WINDOW, NULL);
|
|
|
|
}
|
2010-02-22 09:01:49 +00:00
|
|
|
}
|
|
|
|
}
|
2010-04-08 13:12:53 +00:00
|
|
|
|
2010-02-22 09:01:49 +00:00
|
|
|
CTX_data_scene_set(C, NULL);
|
|
|
|
CTX_wm_screen_set(C, NULL);
|
|
|
|
CTX_wm_window_set(C, NULL);
|
2010-02-21 18:01:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2009-01-31 13:30:56 +00:00
|
|
|
while( (event= win->queue.first) ) {
|
2009-11-27 12:43:48 +00:00
|
|
|
int action = WM_HANDLER_CONTINUE;
|
2009-09-24 10:35:04 +00:00
|
|
|
|
2010-06-23 18:47:56 +00:00
|
|
|
if((G.f & G_DEBUG) && event && !ELEM(event->type, MOUSEMOVE, INBETWEEN_MOUSEMOVE))
|
2010-04-08 16:36:50 +00:00
|
|
|
printf("pass on evt %d val %d\n", event->type, event->val);
|
|
|
|
|
2010-01-14 18:15:12 +00:00
|
|
|
wm_eventemulation(event);
|
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
CTX_wm_window_set(C, win);
|
2009-01-26 15:22:10 +00:00
|
|
|
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
/* we let modal handlers get active area/region, also wm_paintcursor_test needs it */
|
|
|
|
CTX_wm_area_set(C, area_event_inside(C, event->x, event->y));
|
|
|
|
CTX_wm_region_set(C, region_event_inside(C, event->x, event->y));
|
2008-12-02 18:49:58 +00:00
|
|
|
|
2008-12-21 19:58:25 +00:00
|
|
|
/* MVC demands to not draw in event handlers... but we need to leave it for ogl selecting etc */
|
2008-01-07 18:03:41 +00:00
|
|
|
wm_window_make_drawable(C, win);
|
2008-12-14 19:04:20 +00:00
|
|
|
|
2011-05-22 04:05:09 +00:00
|
|
|
wm_region_mouse_co(C, event);
|
|
|
|
|
2009-09-18 15:48:49 +00:00
|
|
|
/* first we do priority handlers, modal + some limited keymaps */
|
2009-11-24 05:03:44 +00:00
|
|
|
action |= wm_handlers_do(C, event, &win->modalhandlers);
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2009-01-23 17:42:36 +00:00
|
|
|
/* fileread case */
|
2009-09-18 12:43:36 +00:00
|
|
|
if(CTX_wm_window(C)==NULL)
|
2009-01-26 15:22:10 +00:00
|
|
|
return;
|
2009-01-23 17:42:36 +00:00
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
/* check dragging, creates new event or frees, adds draw tag */
|
|
|
|
wm_event_drag_test(wm, win, event);
|
|
|
|
|
2.5
Sanitized the 'tweak' event.
Original idea was to have WM event system generating it
automatically. However, I first tested it via a handler
and operator, to check what kind of configurations would
be useful. It appeared to not work nice, also because
that inserting a tweak operator in a keymap is confusing.
Now 'tweaks' are generated automatically, and can be
catched by keymaps as any event. The current definition
of tweak is:
- if Left/Middle/Rightmouse pressed
if event wasn't handled by window queue (modal handlers)
start checking mousepositions
- while mousepositions are checked
- escape on any event other than mouse
- on mouse events:
- add tweak event if mousemove > 10 pixels
- stop checking for tweak if mousebutton released
- Tweak events have a define indicating mousebutton used
EVT_TWEAK_L, EVT_TWEAK_M, EVT_TWEAK_R
- In keymap definitions you can use _S or _A to map to
action or select mouse userdef.
- Event value in keymap should be KM_ANY for all tweaks,
or use one of the eight directions:
EVT_GESTURE_E, _SE, _S, _SW, _W, _NW, _N, _NE
- And of course you can add modifier checks in keymaps for it.
- Because tweaks are a result of mouse events, the handlers get
both to evaluate. That means that RMB-select + tweak will work
correctly.
In case you don't want both to be handled, for example the
CTRL+LMB 'extrude' and CTRL+LMB-tweak 'lasso select', you will
need to set the first acting on a EVT_RELEASE, this event only
gets passed on when tweak fails.
The current system allows all options, configurable, we had in 2.48,
and many more! A diagram of what's possible is on the todo. :)
Also in this commit: lasso select editmesh failed with 'zbuffer
occluded select'. Also circle-select failed.
2009-02-02 14:13:14 +00:00
|
|
|
/* builtin tweak, if action is break it removes tweak */
|
2009-09-18 12:43:36 +00:00
|
|
|
wm_tweakevent_test(C, event, action);
|
2009-09-24 10:35:04 +00:00
|
|
|
|
2009-11-24 05:03:44 +00:00
|
|
|
if((action & WM_HANDLER_BREAK) == 0) {
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
ScrArea *sa;
|
|
|
|
ARegion *ar;
|
2008-12-02 18:49:58 +00:00
|
|
|
int doit= 0;
|
2011-03-04 18:39:58 +00:00
|
|
|
|
2011-03-10 11:11:26 +00:00
|
|
|
/* Note: setting subwin active should be done here, after modal handlers have been done */
|
|
|
|
if(event->type==MOUSEMOVE) {
|
|
|
|
/* state variables in screen, cursors. Also used in wm_draw.c, fails for modal handlers though */
|
|
|
|
ED_screen_set_subwinactive(C, event);
|
|
|
|
/* for regions having custom cursors */
|
|
|
|
wm_paintcursor_test(C, event);
|
|
|
|
}
|
2011-07-25 00:03:07 +00:00
|
|
|
else if (event->type==NDOF_MOTION) {
|
|
|
|
win->addmousemove = TRUE;
|
|
|
|
}
|
|
|
|
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
for(sa= win->screen->areabase.first; sa; sa= sa->next) {
|
2009-09-18 12:43:36 +00:00
|
|
|
if(wm_event_inside_i(event, &sa->totrct)) {
|
2008-12-18 02:56:48 +00:00
|
|
|
CTX_wm_area_set(C, sa);
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
|
2009-11-24 05:03:44 +00:00
|
|
|
if((action & WM_HANDLER_BREAK) == 0) {
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
for(ar=sa->regionbase.first; ar; ar= ar->next) {
|
2009-09-18 12:43:36 +00:00
|
|
|
if(wm_event_inside_i(event, &ar->winrct)) {
|
2008-12-18 02:56:48 +00:00
|
|
|
CTX_wm_region_set(C, ar);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
2011-05-22 04:05:09 +00:00
|
|
|
/* call even on non mouse events, since the */
|
|
|
|
wm_region_mouse_co(C, event);
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
/* does polls for drop regions and checks uibuts */
|
|
|
|
/* need to be here to make sure region context is true */
|
2010-06-07 07:47:27 +00:00
|
|
|
if(ELEM(event->type, MOUSEMOVE, EVT_DROP)) {
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
wm_drags_check_ops(C, event);
|
|
|
|
}
|
|
|
|
|
2009-11-24 05:03:44 +00:00
|
|
|
action |= wm_handlers_do(C, event, &ar->handlers);
|
2010-11-18 16:33:13 +00:00
|
|
|
|
|
|
|
/* fileread case (python), [#29489] */
|
|
|
|
if(CTX_wm_window(C)==NULL)
|
|
|
|
return;
|
|
|
|
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
doit |= (BLI_in_rcti(&ar->winrct, event->x, event->y));
|
|
|
|
|
2009-11-24 05:03:44 +00:00
|
|
|
if(action & WM_HANDLER_BREAK)
|
2009-09-18 12:43:36 +00:00
|
|
|
break;
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-09-18 12:43:36 +00:00
|
|
|
|
|
|
|
CTX_wm_region_set(C, NULL);
|
|
|
|
|
2011-05-22 04:05:09 +00:00
|
|
|
if((action & WM_HANDLER_BREAK) == 0) {
|
|
|
|
wm_region_mouse_co(C, event); /* only invalidates event->mval in this case */
|
2009-11-24 05:03:44 +00:00
|
|
|
action |= wm_handlers_do(C, event, &sa->handlers);
|
2011-05-22 04:05:09 +00:00
|
|
|
}
|
2009-09-18 12:43:36 +00:00
|
|
|
CTX_wm_area_set(C, NULL);
|
|
|
|
|
2008-12-02 18:49:58 +00:00
|
|
|
/* NOTE: do not escape on WM_HANDLER_BREAK, mousemove needs handled for previous area */
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
|
|
|
}
|
2009-01-31 13:33:23 +00:00
|
|
|
|
2009-11-24 05:03:44 +00:00
|
|
|
if((action & WM_HANDLER_BREAK) == 0) {
|
2009-09-18 12:43:36 +00:00
|
|
|
/* also some non-modal handlers need active area/region */
|
|
|
|
CTX_wm_area_set(C, area_event_inside(C, event->x, event->y));
|
|
|
|
CTX_wm_region_set(C, region_event_inside(C, event->x, event->y));
|
|
|
|
|
2011-05-22 04:05:09 +00:00
|
|
|
wm_region_mouse_co(C, event);
|
|
|
|
|
2009-11-24 05:03:44 +00:00
|
|
|
action |= wm_handlers_do(C, event, &win->handlers);
|
2009-09-18 12:43:36 +00:00
|
|
|
|
|
|
|
/* fileread case */
|
|
|
|
if(CTX_wm_window(C)==NULL)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-12-02 18:49:58 +00:00
|
|
|
/* XXX hrmf, this gives reliable previous mouse coord for area change, feels bad?
|
|
|
|
doing it on ghost queue gives errors when mousemoves go over area borders */
|
2009-09-21 09:17:14 +00:00
|
|
|
if(doit && win->screen && win->screen->subwinactive != win->screen->mainwin) {
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
win->eventstate->prevx= event->x;
|
|
|
|
win->eventstate->prevy= event->y;
|
2011-07-25 00:03:07 +00:00
|
|
|
//printf("win->eventstate->prev = %d %d\n", event->x, event->y);
|
2008-12-02 18:49:58 +00:00
|
|
|
}
|
2011-07-25 00:03:07 +00:00
|
|
|
else
|
|
|
|
;//printf("not setting prev to %d %d\n", event->x, event->y);
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
2009-01-31 13:30:56 +00:00
|
|
|
|
2009-11-23 16:24:28 +00:00
|
|
|
/* store last event for this window */
|
2009-12-14 19:39:54 +00:00
|
|
|
/* mousemove and timer events don't overwrite last type */
|
2011-09-22 15:39:31 +00:00
|
|
|
if (!ELEM(event->type, MOUSEMOVE, INBETWEEN_MOUSEMOVE) && !ISTIMER(event->type)) {
|
2009-12-10 23:24:29 +00:00
|
|
|
if (wm_action_not_handled(action)) {
|
2009-12-19 14:58:24 +00:00
|
|
|
if (win->eventstate->prevtype == event->type) {
|
2009-12-10 17:41:03 +00:00
|
|
|
/* set click time on first click (press -> release) */
|
2009-12-19 14:58:24 +00:00
|
|
|
if (win->eventstate->prevval == KM_PRESS && event->val == KM_RELEASE) {
|
|
|
|
win->eventstate->prevclicktime = PIL_check_seconds_timer();
|
2010-07-05 16:42:42 +00:00
|
|
|
win->eventstate->prevclickx = event->x;
|
|
|
|
win->eventstate->prevclicky = event->y;
|
2009-12-10 17:41:03 +00:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* reset click time if event type not the same */
|
2009-12-19 14:58:24 +00:00
|
|
|
win->eventstate->prevclicktime = 0;
|
2009-12-10 17:41:03 +00:00
|
|
|
}
|
|
|
|
|
2009-12-19 14:58:24 +00:00
|
|
|
win->eventstate->prevval = event->val;
|
|
|
|
win->eventstate->prevtype = event->type;
|
2009-12-10 23:24:29 +00:00
|
|
|
} else if (event->val == KM_CLICK) { /* keep click for double click later */
|
2009-12-19 14:58:24 +00:00
|
|
|
win->eventstate->prevtype = event->type;
|
|
|
|
win->eventstate->prevval = event->val;
|
|
|
|
win->eventstate->prevclicktime = PIL_check_seconds_timer();
|
2010-07-05 16:42:42 +00:00
|
|
|
win->eventstate->prevclickx = event->x;
|
|
|
|
win->eventstate->prevclicky = event->y;
|
2009-12-10 23:24:29 +00:00
|
|
|
} else { /* reset if not */
|
2009-12-19 14:58:24 +00:00
|
|
|
win->eventstate->prevtype = -1;
|
|
|
|
win->eventstate->prevval = 0;
|
|
|
|
win->eventstate->prevclicktime = 0;
|
2009-11-26 18:36:24 +00:00
|
|
|
}
|
2009-11-24 05:03:44 +00:00
|
|
|
}
|
2009-11-23 16:24:28 +00:00
|
|
|
|
2009-01-31 13:30:56 +00:00
|
|
|
/* unlink and free here, blender-quit then frees all */
|
|
|
|
BLI_remlink(&win->queue, event);
|
2007-12-24 18:27:28 +00:00
|
|
|
wm_event_free(event);
|
2008-12-02 18:49:58 +00:00
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
2009-06-06 13:35:04 +00:00
|
|
|
|
|
|
|
/* only add mousemove when queue was read entirely */
|
2009-09-21 09:17:14 +00:00
|
|
|
if(win->addmousemove && win->eventstate) {
|
2010-12-03 12:30:59 +00:00
|
|
|
wmEvent tevent= *(win->eventstate);
|
2011-07-25 00:03:07 +00:00
|
|
|
//printf("adding MOUSEMOVE %d %d\n", tevent.x, tevent.y);
|
2010-12-03 12:30:59 +00:00
|
|
|
tevent.type= MOUSEMOVE;
|
|
|
|
tevent.prevx= tevent.x;
|
|
|
|
tevent.prevy= tevent.y;
|
|
|
|
wm_event_add(win, &tevent);
|
2009-06-06 13:35:04 +00:00
|
|
|
win->addmousemove= 0;
|
|
|
|
}
|
|
|
|
|
2009-01-26 15:22:10 +00:00
|
|
|
CTX_wm_window_set(C, NULL);
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
|
|
|
|
/* update key configuration after handling events */
|
|
|
|
WM_keyconfig_update(wm);
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
/* ********** filesector handling ************ */
|
|
|
|
|
|
|
|
void WM_event_fileselect_event(bContext *C, void *ophandle, int eventval)
|
|
|
|
{
|
|
|
|
/* add to all windows! */
|
|
|
|
wmWindow *win;
|
|
|
|
|
|
|
|
for(win= CTX_wm_manager(C)->windows.first; win; win= win->next) {
|
|
|
|
wmEvent event= *win->eventstate;
|
|
|
|
|
|
|
|
event.type= EVT_FILESELECT;
|
|
|
|
event.val= eventval;
|
|
|
|
event.customdata= ophandle; // only as void pointer type check
|
|
|
|
|
|
|
|
wm_event_add(win, &event);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-09-12 19:54:39 +00:00
|
|
|
/* operator is supposed to have a filled "path" property */
|
2009-02-16 12:14:04 +00:00
|
|
|
/* optional property: filetype (XXX enum?) */
|
|
|
|
|
|
|
|
/* Idea is to keep a handler alive on window queue, owning the operator.
|
|
|
|
The filewindow can send event to make it execute, thus ensuring
|
|
|
|
executing happens outside of lower level queues, with UI refreshed.
|
|
|
|
Should also allow multiwin solutions */
|
|
|
|
|
|
|
|
void WM_event_add_fileselect(bContext *C, wmOperator *op)
|
|
|
|
{
|
2011-01-04 14:37:21 +00:00
|
|
|
wmEventHandler *handler, *handlernext;
|
2009-02-16 12:14:04 +00:00
|
|
|
wmWindow *win= CTX_wm_window(C);
|
|
|
|
int full= 1; // XXX preset?
|
2010-08-31 14:22:00 +00:00
|
|
|
|
2011-01-04 14:37:21 +00:00
|
|
|
/* only allow 1 file selector open per window */
|
|
|
|
for(handler= win->modalhandlers.first; handler; handler=handlernext) {
|
|
|
|
handlernext= handler->next;
|
|
|
|
|
|
|
|
if(handler->type == WM_HANDLER_FILESELECT) {
|
|
|
|
if(handler->op)
|
|
|
|
WM_operator_free(handler->op);
|
|
|
|
BLI_remlink(&win->modalhandlers, handler);
|
|
|
|
wm_event_free_handler(handler);
|
|
|
|
}
|
2010-08-31 14:22:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
handler = MEM_callocN(sizeof(wmEventHandler), "fileselect handler");
|
2009-02-16 12:14:04 +00:00
|
|
|
|
|
|
|
handler->type= WM_HANDLER_FILESELECT;
|
|
|
|
handler->op= op;
|
|
|
|
handler->op_area= CTX_wm_area(C);
|
|
|
|
handler->op_region= CTX_wm_region(C);
|
|
|
|
handler->filescreen= CTX_wm_screen(C);
|
|
|
|
|
2009-09-18 12:43:36 +00:00
|
|
|
BLI_addhead(&win->modalhandlers, handler);
|
2009-02-16 12:14:04 +00:00
|
|
|
|
2010-09-17 09:27:31 +00:00
|
|
|
/* check props once before invoking if check is available
|
|
|
|
* ensures initial properties are valid */
|
|
|
|
if(op->type->check) {
|
|
|
|
op->type->check(C, op); /* ignore return value */
|
|
|
|
}
|
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
WM_event_fileselect_event(C, op, full?EVT_FILESELECT_FULL_OPEN:EVT_FILESELECT_OPEN);
|
|
|
|
}
|
|
|
|
|
2011-03-07 14:56:19 +00:00
|
|
|
#if 0
|
2007-12-24 18:27:28 +00:00
|
|
|
/* lets not expose struct outside wm? */
|
2011-02-13 14:16:36 +00:00
|
|
|
static void WM_event_set_handler_flag(wmEventHandler *handler, int flag)
|
2007-12-24 18:27:28 +00:00
|
|
|
{
|
|
|
|
handler->flag= flag;
|
|
|
|
}
|
2011-03-07 14:56:19 +00:00
|
|
|
#endif
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2009-09-18 12:43:36 +00:00
|
|
|
wmEventHandler *WM_event_add_modal_handler(bContext *C, wmOperator *op)
|
2007-12-24 18:27:28 +00:00
|
|
|
{
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
wmEventHandler *handler= MEM_callocN(sizeof(wmEventHandler), "event modal handler");
|
2009-09-18 12:43:36 +00:00
|
|
|
wmWindow *win= CTX_wm_window(C);
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 17:56:38 +00:00
|
|
|
|
|
|
|
/* operator was part of macro */
|
|
|
|
if(op->opm) {
|
|
|
|
/* give the mother macro to the handler */
|
|
|
|
handler->op= op->opm;
|
|
|
|
/* mother macro opm becomes the macro element */
|
|
|
|
handler->op->opm= op;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
handler->op= op;
|
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
handler->op_area= CTX_wm_area(C); /* means frozen screen context for modal handlers! */
|
|
|
|
handler->op_region= CTX_wm_region(C);
|
2008-12-03 19:33:42 +00:00
|
|
|
|
2009-09-18 12:43:36 +00:00
|
|
|
BLI_addhead(&win->modalhandlers, handler);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2008-12-03 19:33:42 +00:00
|
|
|
return handler;
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
|
|
|
|
2009-09-17 21:36:02 +00:00
|
|
|
wmEventHandler *WM_event_add_keymap_handler(ListBase *handlers, wmKeyMap *keymap)
|
2007-12-24 18:27:28 +00:00
|
|
|
{
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
wmEventHandler *handler;
|
2009-01-23 17:42:36 +00:00
|
|
|
|
2009-09-17 21:36:02 +00:00
|
|
|
if(!keymap) {
|
|
|
|
printf("WM_event_add_keymap_handler called with NULL keymap\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
/* only allow same keymap once */
|
|
|
|
for(handler= handlers->first; handler; handler= handler->next)
|
|
|
|
if(handler->keymap==keymap)
|
2008-06-19 19:09:21 +00:00
|
|
|
return handler;
|
2009-01-23 17:42:36 +00:00
|
|
|
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
handler= MEM_callocN(sizeof(wmEventHandler), "event keymap handler");
|
2007-12-24 18:27:28 +00:00
|
|
|
BLI_addtail(handlers, handler);
|
|
|
|
handler->keymap= keymap;
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
return handler;
|
|
|
|
}
|
|
|
|
|
2009-01-23 14:43:25 +00:00
|
|
|
/* priorities not implemented yet, for time being just insert in begin of list */
|
2010-10-16 02:40:31 +00:00
|
|
|
wmEventHandler *WM_event_add_keymap_handler_priority(ListBase *handlers, wmKeyMap *keymap, int UNUSED(priority))
|
2009-01-23 14:43:25 +00:00
|
|
|
{
|
|
|
|
wmEventHandler *handler;
|
|
|
|
|
|
|
|
WM_event_remove_keymap_handler(handlers, keymap);
|
|
|
|
|
|
|
|
handler= MEM_callocN(sizeof(wmEventHandler), "event keymap handler");
|
|
|
|
BLI_addhead(handlers, handler);
|
|
|
|
handler->keymap= keymap;
|
|
|
|
|
|
|
|
return handler;
|
|
|
|
}
|
|
|
|
|
2009-09-17 21:36:02 +00:00
|
|
|
wmEventHandler *WM_event_add_keymap_handler_bb(ListBase *handlers, wmKeyMap *keymap, rcti *bblocal, rcti *bbwin)
|
2008-12-10 13:56:54 +00:00
|
|
|
{
|
|
|
|
wmEventHandler *handler= WM_event_add_keymap_handler(handlers, keymap);
|
|
|
|
|
2009-01-23 17:42:36 +00:00
|
|
|
if(handler) {
|
|
|
|
handler->bblocal= bblocal;
|
|
|
|
handler->bbwin= bbwin;
|
|
|
|
}
|
2008-12-10 13:56:54 +00:00
|
|
|
return handler;
|
|
|
|
}
|
|
|
|
|
2009-09-17 21:36:02 +00:00
|
|
|
void WM_event_remove_keymap_handler(ListBase *handlers, wmKeyMap *keymap)
|
2.5 Branch
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
2008-06-11 10:10:31 +00:00
|
|
|
{
|
|
|
|
wmEventHandler *handler;
|
|
|
|
|
|
|
|
for(handler= handlers->first; handler; handler= handler->next) {
|
|
|
|
if(handler->keymap==keymap) {
|
|
|
|
BLI_remlink(handlers, handler);
|
|
|
|
wm_event_free_handler(handler);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2008-01-10 17:38:17 +00:00
|
|
|
|
2009-04-16 21:39:45 +00:00
|
|
|
wmEventHandler *WM_event_add_ui_handler(const bContext *C, ListBase *handlers, wmUIHandlerFunc func, wmUIHandlerRemoveFunc remove, void *userdata)
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
{
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
wmEventHandler *handler= MEM_callocN(sizeof(wmEventHandler), "event ui handler");
|
|
|
|
handler->ui_handle= func;
|
|
|
|
handler->ui_remove= remove;
|
2008-12-15 19:19:39 +00:00
|
|
|
handler->ui_userdata= userdata;
|
2008-12-18 02:56:48 +00:00
|
|
|
handler->ui_area= (C)? CTX_wm_area(C): NULL;
|
|
|
|
handler->ui_region= (C)? CTX_wm_region(C): NULL;
|
2009-03-25 20:49:15 +00:00
|
|
|
handler->ui_menu= (C)? CTX_wm_menu(C): NULL;
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
|
|
|
BLI_addhead(handlers, handler);
|
|
|
|
|
|
|
|
return handler;
|
|
|
|
}
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
|
2011-04-20 11:15:58 +00:00
|
|
|
/* set "postpone" for win->modalhandlers, this is in a running for() loop in wm_handlers_do() */
|
|
|
|
void WM_event_remove_ui_handler(ListBase *handlers, wmUIHandlerFunc func, wmUIHandlerRemoveFunc remove, void *userdata, int postpone)
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
{
|
|
|
|
wmEventHandler *handler;
|
|
|
|
|
|
|
|
for(handler= handlers->first; handler; handler= handler->next) {
|
2008-12-15 19:19:39 +00:00
|
|
|
if(handler->ui_handle == func && handler->ui_remove == remove && handler->ui_userdata == userdata) {
|
2011-04-20 11:15:58 +00:00
|
|
|
/* handlers will be freed in wm_handlers_do() */
|
|
|
|
if(postpone) {
|
|
|
|
handler->flag |= WM_HANDLER_DO_FREE;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
BLI_remlink(handlers, handler);
|
|
|
|
wm_event_free_handler(handler);
|
|
|
|
}
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
break;
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
wmEventHandler *WM_event_add_dropbox_handler(ListBase *handlers, ListBase *dropboxes)
|
|
|
|
{
|
|
|
|
wmEventHandler *handler;
|
|
|
|
|
|
|
|
/* only allow same dropbox once */
|
|
|
|
for(handler= handlers->first; handler; handler= handler->next)
|
|
|
|
if(handler->dropboxes==dropboxes)
|
|
|
|
return handler;
|
|
|
|
|
|
|
|
handler= MEM_callocN(sizeof(wmEventHandler), "dropbox handler");
|
|
|
|
|
|
|
|
/* dropbox stored static, no free or copy */
|
|
|
|
handler->dropboxes= dropboxes;
|
|
|
|
BLI_addhead(handlers, handler);
|
|
|
|
|
|
|
|
return handler;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* XXX solution works, still better check the real cause (ton) */
|
2010-01-12 23:30:19 +00:00
|
|
|
void WM_event_remove_area_handler(ListBase *handlers, void *area)
|
|
|
|
{
|
|
|
|
wmEventHandler *handler, *nexthandler;
|
|
|
|
|
|
|
|
for(handler = handlers->first; handler; handler= nexthandler) {
|
2010-01-13 04:27:10 +00:00
|
|
|
nexthandler = handler->next;
|
2010-01-13 02:59:42 +00:00
|
|
|
if (handler->type != WM_HANDLER_FILESELECT) {
|
2010-01-14 05:21:20 +00:00
|
|
|
if (handler->ui_area == area) {
|
2010-01-13 02:59:42 +00:00
|
|
|
BLI_remlink(handlers, handler);
|
|
|
|
wm_event_free_handler(handler);
|
|
|
|
}
|
2010-01-12 23:30:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-03-07 14:56:19 +00:00
|
|
|
#if 0
|
2011-02-13 14:16:36 +00:00
|
|
|
static void WM_event_remove_handler(ListBase *handlers, wmEventHandler *handler)
|
2010-01-12 23:30:19 +00:00
|
|
|
{
|
|
|
|
BLI_remlink(handlers, handler);
|
|
|
|
wm_event_free_handler(handler);
|
|
|
|
}
|
2011-03-07 14:56:19 +00:00
|
|
|
#endif
|
2010-01-12 23:30:19 +00:00
|
|
|
|
2008-12-02 18:49:58 +00:00
|
|
|
void WM_event_add_mousemove(bContext *C)
|
|
|
|
{
|
2008-12-18 02:56:48 +00:00
|
|
|
wmWindow *window= CTX_wm_window(C);
|
2009-06-06 13:35:04 +00:00
|
|
|
|
|
|
|
window->addmousemove= 1;
|
2008-12-02 18:49:58 +00:00
|
|
|
}
|
|
|
|
|
2009-01-01 18:05:12 +00:00
|
|
|
/* for modal callbacks, check configuration for how to interpret exit with tweaks */
|
|
|
|
int WM_modal_tweak_exit(wmEvent *evt, int tweak_event)
|
|
|
|
{
|
2011-02-17 01:24:52 +00:00
|
|
|
/* if the release-confirm userpref setting is enabled,
|
|
|
|
* tweak events can be cancelled when mouse is released
|
|
|
|
*/
|
|
|
|
if (U.flag & USER_RELEASECONFIRM) {
|
|
|
|
/* option on, so can exit with km-release */
|
|
|
|
if (evt->val == KM_RELEASE) {
|
|
|
|
switch (tweak_event) {
|
|
|
|
case EVT_TWEAK_L:
|
|
|
|
case EVT_TWEAK_M:
|
|
|
|
case EVT_TWEAK_R:
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
2011-04-04 07:42:08 +00:00
|
|
|
else {
|
|
|
|
/* if the initial event wasn't a tweak event then
|
|
|
|
* ignore USER_RELEASECONFIRM setting: see [#26756] */
|
|
|
|
if(ELEM3(tweak_event, EVT_TWEAK_L, EVT_TWEAK_M, EVT_TWEAK_R) == 0) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
2009-01-01 18:05:12 +00:00
|
|
|
}
|
2011-02-17 01:24:52 +00:00
|
|
|
else {
|
|
|
|
/* this is fine as long as not doing km-release, otherwise
|
|
|
|
* some items (i.e. markers) being tweaked may end up getting
|
|
|
|
* dropped all over
|
|
|
|
*/
|
|
|
|
if (evt->val != KM_RELEASE)
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-01-01 18:05:12 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
/* ********************* ghost stuff *************** */
|
|
|
|
|
|
|
|
static int convert_key(GHOST_TKey key)
|
|
|
|
{
|
|
|
|
if (key>=GHOST_kKeyA && key<=GHOST_kKeyZ) {
|
|
|
|
return (AKEY + ((int) key - GHOST_kKeyA));
|
|
|
|
} else if (key>=GHOST_kKey0 && key<=GHOST_kKey9) {
|
|
|
|
return (ZEROKEY + ((int) key - GHOST_kKey0));
|
|
|
|
} else if (key>=GHOST_kKeyNumpad0 && key<=GHOST_kKeyNumpad9) {
|
|
|
|
return (PAD0 + ((int) key - GHOST_kKeyNumpad0));
|
2010-04-20 00:08:27 +00:00
|
|
|
} else if (key>=GHOST_kKeyF1 && key<=GHOST_kKeyF19) {
|
2007-12-24 18:27:28 +00:00
|
|
|
return (F1KEY + ((int) key - GHOST_kKeyF1));
|
|
|
|
} else {
|
|
|
|
switch (key) {
|
|
|
|
case GHOST_kKeyBackSpace: return BACKSPACEKEY;
|
|
|
|
case GHOST_kKeyTab: return TABKEY;
|
|
|
|
case GHOST_kKeyLinefeed: return LINEFEEDKEY;
|
|
|
|
case GHOST_kKeyClear: return 0;
|
|
|
|
case GHOST_kKeyEnter: return RETKEY;
|
|
|
|
|
|
|
|
case GHOST_kKeyEsc: return ESCKEY;
|
|
|
|
case GHOST_kKeySpace: return SPACEKEY;
|
|
|
|
case GHOST_kKeyQuote: return QUOTEKEY;
|
|
|
|
case GHOST_kKeyComma: return COMMAKEY;
|
|
|
|
case GHOST_kKeyMinus: return MINUSKEY;
|
|
|
|
case GHOST_kKeyPeriod: return PERIODKEY;
|
|
|
|
case GHOST_kKeySlash: return SLASHKEY;
|
|
|
|
|
|
|
|
case GHOST_kKeySemicolon: return SEMICOLONKEY;
|
|
|
|
case GHOST_kKeyEqual: return EQUALKEY;
|
|
|
|
|
|
|
|
case GHOST_kKeyLeftBracket: return LEFTBRACKETKEY;
|
|
|
|
case GHOST_kKeyRightBracket: return RIGHTBRACKETKEY;
|
|
|
|
case GHOST_kKeyBackslash: return BACKSLASHKEY;
|
|
|
|
case GHOST_kKeyAccentGrave: return ACCENTGRAVEKEY;
|
|
|
|
|
|
|
|
case GHOST_kKeyLeftShift: return LEFTSHIFTKEY;
|
|
|
|
case GHOST_kKeyRightShift: return RIGHTSHIFTKEY;
|
|
|
|
case GHOST_kKeyLeftControl: return LEFTCTRLKEY;
|
|
|
|
case GHOST_kKeyRightControl: return RIGHTCTRLKEY;
|
2010-10-05 19:10:15 +00:00
|
|
|
case GHOST_kKeyOS: return OSKEY;
|
2007-12-24 18:27:28 +00:00
|
|
|
case GHOST_kKeyLeftAlt: return LEFTALTKEY;
|
|
|
|
case GHOST_kKeyRightAlt: return RIGHTALTKEY;
|
|
|
|
|
|
|
|
case GHOST_kKeyCapsLock: return CAPSLOCKKEY;
|
|
|
|
case GHOST_kKeyNumLock: return 0;
|
|
|
|
case GHOST_kKeyScrollLock: return 0;
|
|
|
|
|
|
|
|
case GHOST_kKeyLeftArrow: return LEFTARROWKEY;
|
|
|
|
case GHOST_kKeyRightArrow: return RIGHTARROWKEY;
|
|
|
|
case GHOST_kKeyUpArrow: return UPARROWKEY;
|
|
|
|
case GHOST_kKeyDownArrow: return DOWNARROWKEY;
|
|
|
|
|
|
|
|
case GHOST_kKeyPrintScreen: return 0;
|
|
|
|
case GHOST_kKeyPause: return PAUSEKEY;
|
|
|
|
|
|
|
|
case GHOST_kKeyInsert: return INSERTKEY;
|
|
|
|
case GHOST_kKeyDelete: return DELKEY;
|
|
|
|
case GHOST_kKeyHome: return HOMEKEY;
|
|
|
|
case GHOST_kKeyEnd: return ENDKEY;
|
|
|
|
case GHOST_kKeyUpPage: return PAGEUPKEY;
|
|
|
|
case GHOST_kKeyDownPage: return PAGEDOWNKEY;
|
|
|
|
|
|
|
|
case GHOST_kKeyNumpadPeriod: return PADPERIOD;
|
|
|
|
case GHOST_kKeyNumpadEnter: return PADENTER;
|
|
|
|
case GHOST_kKeyNumpadPlus: return PADPLUSKEY;
|
|
|
|
case GHOST_kKeyNumpadMinus: return PADMINUS;
|
|
|
|
case GHOST_kKeyNumpadAsterisk: return PADASTERKEY;
|
|
|
|
case GHOST_kKeyNumpadSlash: return PADSLASHKEY;
|
|
|
|
|
|
|
|
case GHOST_kKeyGrLess: return GRLESSKEY;
|
2011-02-18 22:42:03 +00:00
|
|
|
|
|
|
|
case GHOST_kKeyMediaPlay: return MEDIAPLAY;
|
|
|
|
case GHOST_kKeyMediaStop: return MEDIASTOP;
|
|
|
|
case GHOST_kKeyMediaFirst: return MEDIAFIRST;
|
|
|
|
case GHOST_kKeyMediaLast: return MEDIALAST;
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
default:
|
|
|
|
return UNKNOWNKEY; /* GHOST_kKeyUnknown */
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* adds customdata to event */
|
|
|
|
static void update_tablet_data(wmWindow *win, wmEvent *event)
|
|
|
|
{
|
|
|
|
const GHOST_TabletData *td= GHOST_GetTabletData(win->ghostwin);
|
|
|
|
|
|
|
|
/* if there's tablet data from an active tablet device then add it */
|
2009-09-16 15:55:00 +00:00
|
|
|
if ((td != NULL) && td->Active != GHOST_kTabletModeNone) {
|
2007-12-24 18:27:28 +00:00
|
|
|
struct wmTabletData *wmtab= MEM_mallocN(sizeof(wmTabletData), "customdata tablet");
|
|
|
|
|
2009-09-16 15:55:00 +00:00
|
|
|
wmtab->Active = (int)td->Active;
|
2007-12-24 18:27:28 +00:00
|
|
|
wmtab->Pressure = td->Pressure;
|
|
|
|
wmtab->Xtilt = td->Xtilt;
|
|
|
|
wmtab->Ytilt = td->Ytilt;
|
|
|
|
|
2008-11-24 10:45:36 +00:00
|
|
|
event->custom= EVT_DATA_TABLET;
|
2007-12-24 18:27:28 +00:00
|
|
|
event->customdata= wmtab;
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
event->customdatafree= 1;
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-08-07 10:57:15 +00:00
|
|
|
/* adds customdata to event */
|
|
|
|
static void attach_ndof_data(wmEvent* event, const GHOST_TEventNDOFMotionData* ghost)
|
|
|
|
{
|
|
|
|
wmNDOFMotionData* data = MEM_mallocN(sizeof(wmNDOFMotionData), "customdata NDOF");
|
|
|
|
|
2011-07-24 00:40:39 +00:00
|
|
|
const float s = U.ndof_sensitivity;
|
2010-08-07 10:57:15 +00:00
|
|
|
|
2011-08-07 17:22:47 +00:00
|
|
|
data->tx = s * ghost->tx;
|
2011-08-06 23:13:36 +00:00
|
|
|
|
2011-08-07 17:22:47 +00:00
|
|
|
data->rx = s * ghost->rx;
|
2011-08-07 17:38:36 +00:00
|
|
|
data->ry = s * ghost->ry;
|
|
|
|
data->rz = s * ghost->rz;
|
2011-08-02 22:50:06 +00:00
|
|
|
|
2011-08-02 23:52:07 +00:00
|
|
|
if (U.ndof_flag & NDOF_ZOOM_UPDOWN)
|
2011-08-02 22:50:06 +00:00
|
|
|
{
|
2011-08-07 17:22:47 +00:00
|
|
|
/* rotate so Y is where Z was */
|
|
|
|
data->ty = s * ghost->tz;
|
|
|
|
data->tz = s * ghost->ty;
|
|
|
|
/* maintain handed-ness? or just do what feels right? */
|
|
|
|
|
|
|
|
/* should this affect rotation also?
|
|
|
|
* initial guess is 'yes', but get user feedback immediately!
|
|
|
|
*/
|
|
|
|
#if 0
|
|
|
|
/* after turning this on, my guess becomes 'no' */
|
|
|
|
data->ry = s * ghost->rz;
|
|
|
|
data->rz = s * ghost->ry;
|
2011-08-06 23:13:36 +00:00
|
|
|
#endif
|
2011-08-02 22:50:06 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2011-08-07 17:22:47 +00:00
|
|
|
data->ty = s * ghost->ty;
|
|
|
|
data->tz = s * ghost->tz;
|
2011-08-02 22:50:06 +00:00
|
|
|
}
|
2010-08-07 10:57:15 +00:00
|
|
|
|
|
|
|
data->dt = ghost->dt;
|
|
|
|
|
2011-07-14 21:20:45 +00:00
|
|
|
data->progress = (wmProgress) ghost->progress;
|
|
|
|
|
2010-08-07 10:57:15 +00:00
|
|
|
event->custom = EVT_DATA_NDOF_MOTION;
|
|
|
|
event->customdata = data;
|
|
|
|
event->customdatafree = 1;
|
|
|
|
}
|
2007-12-24 18:27:28 +00:00
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
/* imperfect but probably usable... draw/enable drags to other windows */
|
|
|
|
static wmWindow *wm_event_cursor_other_windows(wmWindowManager *wm, wmWindow *win, wmEvent *evt)
|
|
|
|
{
|
2011-05-12 16:47:36 +00:00
|
|
|
int mx= evt->x, my= evt->y;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
|
|
|
if(wm->windows.first== wm->windows.last)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* top window bar... */
|
|
|
|
if(mx<0 || my<0 || mx>win->sizex || my>win->sizey+30) {
|
|
|
|
wmWindow *owin;
|
2010-01-28 16:57:37 +00:00
|
|
|
wmEventHandler *handler;
|
|
|
|
|
|
|
|
/* let's skip windows having modal handlers now */
|
|
|
|
/* potential XXX ugly... I wouldn't have added a modalhandlers list (introduced in rev 23331, ton) */
|
|
|
|
for(handler= win->modalhandlers.first; handler; handler= handler->next)
|
2010-01-29 16:25:31 +00:00
|
|
|
if(handler->ui_handle || handler->op)
|
2010-01-28 16:57:37 +00:00
|
|
|
return NULL;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
|
|
|
/* to desktop space */
|
2011-05-12 16:47:36 +00:00
|
|
|
mx += (int)win->posx;
|
|
|
|
my += (int)win->posy;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
|
|
|
/* check other windows to see if it has mouse inside */
|
|
|
|
for(owin= wm->windows.first; owin; owin= owin->next) {
|
2010-01-28 16:57:37 +00:00
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
if(owin!=win) {
|
|
|
|
if(mx-owin->posx >= 0 && my-owin->posy >= 0 &&
|
|
|
|
mx-owin->posx <= owin->sizex && my-owin->posy <= owin->sizey) {
|
2011-05-12 16:47:36 +00:00
|
|
|
evt->x= mx - (int)owin->posx;
|
|
|
|
evt->y= my - (int)owin->posy;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
|
|
|
return owin;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
/* windows store own event queues, no bContext here */
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
/* time is in 1000s of seconds, from ghost */
|
2010-10-16 02:40:31 +00:00
|
|
|
void wm_event_add_ghostevent(wmWindowManager *wm, wmWindow *win, int type, int UNUSED(time), void *customdata)
|
2007-12-24 18:27:28 +00:00
|
|
|
{
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
wmWindow *owin;
|
2007-12-24 18:27:28 +00:00
|
|
|
wmEvent event, *evt= win->eventstate;
|
2011-06-11 00:25:48 +00:00
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
/* initialize and copy state (only mouse x y and modifiers) */
|
|
|
|
event= *evt;
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
/* mouse move */
|
|
|
|
case GHOST_kEventCursorMove: {
|
|
|
|
if(win->active) {
|
|
|
|
GHOST_TEventCursorData *cd= customdata;
|
2010-06-23 18:47:56 +00:00
|
|
|
wmEvent *lastevent= win->queue.last;
|
2007-12-24 18:27:28 +00:00
|
|
|
int cx, cy;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
GHOST_ScreenToClient(win->ghostwin, cd->x, cd->y, &cx, &cy);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
evt->x= cx;
|
|
|
|
evt->y= (win->sizey-1) - cy;
|
|
|
|
|
|
|
|
event.x= evt->x;
|
|
|
|
event.y= evt->y;
|
|
|
|
|
|
|
|
event.type= MOUSEMOVE;
|
|
|
|
|
2010-06-23 18:47:56 +00:00
|
|
|
/* some painting operators want accurate mouse events, they can
|
2011-01-02 11:06:50 +00:00
|
|
|
handle in between mouse move moves, others can happily ignore
|
2010-06-23 18:47:56 +00:00
|
|
|
them for better performance */
|
|
|
|
if(lastevent && lastevent->type == MOUSEMOVE)
|
|
|
|
lastevent->type = INBETWEEN_MOUSEMOVE;
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
update_tablet_data(win, &event);
|
|
|
|
wm_event_add(win, &event);
|
2011-07-25 00:03:07 +00:00
|
|
|
|
|
|
|
//printf("sending MOUSEMOVE %d %d\n", event.x, event.y);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
|
|
|
/* also add to other window if event is there, this makes overdraws disappear nicely */
|
|
|
|
/* it remaps mousecoord to other window in event */
|
|
|
|
owin= wm_event_cursor_other_windows(wm, win, &event);
|
|
|
|
if(owin) {
|
|
|
|
wmEvent oevent= *(owin->eventstate);
|
|
|
|
|
2010-04-07 05:39:24 +00:00
|
|
|
oevent.x=owin->eventstate->x= event.x;
|
|
|
|
oevent.y=owin->eventstate->y= event.y;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
oevent.type= MOUSEMOVE;
|
|
|
|
|
|
|
|
update_tablet_data(owin, &oevent);
|
|
|
|
wm_event_add(owin, &oevent);
|
|
|
|
}
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2010-01-11 11:14:36 +00:00
|
|
|
case GHOST_kEventTrackpad: {
|
2010-02-10 14:16:02 +00:00
|
|
|
GHOST_TEventTrackpadData * pd = customdata;
|
|
|
|
switch (pd->subtype) {
|
|
|
|
case GHOST_kTrackpadEventMagnify:
|
|
|
|
event.type = MOUSEZOOM;
|
|
|
|
break;
|
|
|
|
case GHOST_kTrackpadEventRotate:
|
|
|
|
event.type = MOUSEROTATE;
|
|
|
|
break;
|
|
|
|
case GHOST_kTrackpadEventScroll:
|
|
|
|
default:
|
|
|
|
event.type= MOUSEPAN;
|
|
|
|
break;
|
|
|
|
}
|
2011-06-23 19:55:47 +00:00
|
|
|
|
2010-02-10 14:16:02 +00:00
|
|
|
{
|
2011-06-23 19:55:47 +00:00
|
|
|
int cx, cy;
|
|
|
|
GHOST_ScreenToClient(win->ghostwin, pd->x, pd->y, &cx, &cy);
|
|
|
|
event.x= evt->x= cx;
|
|
|
|
event.y= evt->y= (win->sizey-1) - cy;
|
2010-02-10 14:16:02 +00:00
|
|
|
}
|
2011-06-23 19:55:47 +00:00
|
|
|
|
2010-02-10 14:16:02 +00:00
|
|
|
// Use prevx/prevy so we can calculate the delta later
|
|
|
|
event.prevx= event.x - pd->deltaX;
|
2011-06-23 19:55:47 +00:00
|
|
|
event.prevy= event.y - (-pd->deltaY);
|
2010-02-10 14:16:02 +00:00
|
|
|
|
|
|
|
update_tablet_data(win, &event);
|
|
|
|
wm_event_add(win, &event);
|
2010-01-11 11:14:36 +00:00
|
|
|
break;
|
|
|
|
}
|
2007-12-24 18:27:28 +00:00
|
|
|
/* mouse button */
|
|
|
|
case GHOST_kEventButtonDown:
|
|
|
|
case GHOST_kEventButtonUp: {
|
|
|
|
GHOST_TEventButtonData *bd= customdata;
|
2009-09-24 10:35:04 +00:00
|
|
|
event.val= (type==GHOST_kEventButtonDown) ? KM_PRESS:KM_RELEASE; /* Note!, this starts as 0/1 but later is converted to KM_PRESS/KM_RELEASE by tweak */
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
if (bd->button == GHOST_kButtonMaskLeft)
|
|
|
|
event.type= LEFTMOUSE;
|
|
|
|
else if (bd->button == GHOST_kButtonMaskRight)
|
|
|
|
event.type= RIGHTMOUSE;
|
2009-09-21 05:56:43 +00:00
|
|
|
else if (bd->button == GHOST_kButtonMaskButton4)
|
|
|
|
event.type= BUTTON4MOUSE;
|
|
|
|
else if (bd->button == GHOST_kButtonMaskButton5)
|
|
|
|
event.type= BUTTON5MOUSE;
|
2007-12-24 18:27:28 +00:00
|
|
|
else
|
|
|
|
event.type= MIDDLEMOUSE;
|
|
|
|
|
2011-06-27 11:21:25 +00:00
|
|
|
if(win->active==0) {
|
|
|
|
int cx, cy;
|
|
|
|
|
|
|
|
/* entering window, update mouse pos. (ghost sends win-activate *after* the mouseclick in window!) */
|
|
|
|
wm_get_cursor_position(win, &cx, &cy);
|
|
|
|
|
|
|
|
event.x= evt->x= cx;
|
|
|
|
event.y= evt->y= cy;
|
|
|
|
}
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
/* add to other window if event is there (not to both!) */
|
|
|
|
owin= wm_event_cursor_other_windows(wm, win, &event);
|
|
|
|
if(owin) {
|
|
|
|
wmEvent oevent= *(owin->eventstate);
|
|
|
|
|
|
|
|
oevent.x= event.x;
|
|
|
|
oevent.y= event.y;
|
|
|
|
oevent.type= event.type;
|
|
|
|
oevent.val= event.val;
|
|
|
|
|
|
|
|
update_tablet_data(owin, &oevent);
|
|
|
|
wm_event_add(owin, &oevent);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
update_tablet_data(win, &event);
|
|
|
|
wm_event_add(win, &event);
|
|
|
|
}
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* keyboard */
|
|
|
|
case GHOST_kEventKeyDown:
|
|
|
|
case GHOST_kEventKeyUp: {
|
|
|
|
GHOST_TEventKeyData *kd= customdata;
|
|
|
|
event.type= convert_key(kd->key);
|
|
|
|
event.ascii= kd->ascii;
|
2011-10-22 04:36:58 +00:00
|
|
|
memcpy(event.utf8_buf, kd->utf8_buf,sizeof(event.utf8_buf));/* might be not null terminated*/
|
2.5
Modal keymaps.
I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support.
The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way.
This system also allows to still handle hardcoded own events.
Tech doc:
1) define keymap
- Create map with unique name, WM_modalkeymap_add()
- Give map property definitions (EnumPropertyItem *)
This only for UI, so user can get information on available options
2) items
- WM_modalkeymap_add_item(): give it an enum value for events
3) activate
- In keymap definition code, assign the modal keymap to operatortype
WM_modalkeymap_assign()
4) event manager
- The event handler will check for modal keymap, if so:
- If the modal map has a match:
- Sets event->type to EVT_MODAL_MAP
- Sets event->val to the enum value
5) modal handler
- If event type is EVT_MODAL_MAP:
- Check event->val, handle it
- Other events can just be handled still
Two examples added in the code:
editors/transform/transform.c: transform_modal_keymap()
editors/screen/screen_ops.c: keymap_modal_set()
Also: to support 'key release' the define KM_RELEASE now is officially
used in event manager, this is not '0', so don't check key events with
the old convention if(event->val) but use if(event->val==KM_PRESS)
2009-07-21 11:03:07 +00:00
|
|
|
event.val= (type==GHOST_kEventKeyDown)?KM_PRESS:KM_RELEASE;
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2009-01-23 14:43:25 +00:00
|
|
|
/* exclude arrow keys, esc, etc from text input */
|
2009-09-21 15:51:29 +00:00
|
|
|
if(type==GHOST_kEventKeyUp || (event.ascii<32 && event.ascii>0))
|
2009-01-23 14:43:25 +00:00
|
|
|
event.ascii= '\0';
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
/* modifiers */
|
|
|
|
if (event.type==LEFTSHIFTKEY || event.type==RIGHTSHIFTKEY) {
|
2009-07-21 12:19:46 +00:00
|
|
|
event.shift= evt->shift= (event.val==KM_PRESS);
|
|
|
|
if(event.val==KM_PRESS && (evt->ctrl || evt->alt || evt->oskey))
|
2009-01-31 16:54:37 +00:00
|
|
|
event.shift= evt->shift = 3; // define?
|
|
|
|
}
|
|
|
|
else if (event.type==LEFTCTRLKEY || event.type==RIGHTCTRLKEY) {
|
2009-07-21 12:19:46 +00:00
|
|
|
event.ctrl= evt->ctrl= (event.val==KM_PRESS);
|
|
|
|
if(event.val==KM_PRESS && (evt->shift || evt->alt || evt->oskey))
|
2009-01-31 16:54:37 +00:00
|
|
|
event.ctrl= evt->ctrl = 3; // define?
|
|
|
|
}
|
|
|
|
else if (event.type==LEFTALTKEY || event.type==RIGHTALTKEY) {
|
2009-07-21 12:19:46 +00:00
|
|
|
event.alt= evt->alt= (event.val==KM_PRESS);
|
|
|
|
if(event.val==KM_PRESS && (evt->ctrl || evt->shift || evt->oskey))
|
2009-01-31 16:54:37 +00:00
|
|
|
event.alt= evt->alt = 3; // define?
|
|
|
|
}
|
2010-10-05 19:10:15 +00:00
|
|
|
else if (event.type==OSKEY) {
|
2009-07-21 12:19:46 +00:00
|
|
|
event.oskey= evt->oskey= (event.val==KM_PRESS);
|
|
|
|
if(event.val==KM_PRESS && (evt->ctrl || evt->alt || evt->shift))
|
2009-01-31 16:54:37 +00:00
|
|
|
event.oskey= evt->oskey = 3; // define?
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
2009-08-16 17:42:09 +00:00
|
|
|
else {
|
|
|
|
if(event.val==KM_PRESS && event.keymodifier==0)
|
|
|
|
evt->keymodifier= event.type; /* only set in eventstate, for next event */
|
|
|
|
else if(event.val==KM_RELEASE && event.keymodifier==event.type)
|
|
|
|
event.keymodifier= evt->keymodifier= 0;
|
|
|
|
}
|
2009-09-21 15:51:29 +00:00
|
|
|
|
|
|
|
/* this case happens on some systems that on holding a key pressed,
|
|
|
|
generate press events without release, we still want to keep the
|
|
|
|
modifier in win->eventstate, but for the press event of the same
|
|
|
|
key we don't want the key modifier */
|
|
|
|
if(event.keymodifier == event.type)
|
|
|
|
event.keymodifier= 0;
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2.5
Modal keymaps.
I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support.
The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way.
This system also allows to still handle hardcoded own events.
Tech doc:
1) define keymap
- Create map with unique name, WM_modalkeymap_add()
- Give map property definitions (EnumPropertyItem *)
This only for UI, so user can get information on available options
2) items
- WM_modalkeymap_add_item(): give it an enum value for events
3) activate
- In keymap definition code, assign the modal keymap to operatortype
WM_modalkeymap_assign()
4) event manager
- The event handler will check for modal keymap, if so:
- If the modal map has a match:
- Sets event->type to EVT_MODAL_MAP
- Sets event->val to the enum value
5) modal handler
- If event type is EVT_MODAL_MAP:
- Check event->val, handle it
- Other events can just be handled still
Two examples added in the code:
editors/transform/transform.c: transform_modal_keymap()
editors/screen/screen_ops.c: keymap_modal_set()
Also: to support 'key release' the define KM_RELEASE now is officially
used in event manager, this is not '0', so don't check key events with
the old convention if(event->val) but use if(event->val==KM_PRESS)
2009-07-21 11:03:07 +00:00
|
|
|
/* if test_break set, it catches this. XXX Keep global for now? */
|
2008-12-30 13:16:14 +00:00
|
|
|
if(event.type==ESCKEY)
|
|
|
|
G.afbreek= 1;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
wm_event_add(win, &event);
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case GHOST_kEventWheel: {
|
|
|
|
GHOST_TEventWheelData* wheelData = customdata;
|
|
|
|
|
|
|
|
if (wheelData->z > 0)
|
|
|
|
event.type= WHEELUPMOUSE;
|
|
|
|
else
|
|
|
|
event.type= WHEELDOWNMOUSE;
|
|
|
|
|
2009-01-01 14:57:04 +00:00
|
|
|
event.val= KM_PRESS;
|
2007-12-24 18:27:28 +00:00
|
|
|
wm_event_add(win, &event);
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
case GHOST_kEventTimer: {
|
|
|
|
event.type= TIMER;
|
2008-11-24 10:45:36 +00:00
|
|
|
event.custom= EVT_DATA_TIMER;
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
event.customdata= customdata;
|
|
|
|
wm_event_add(win, &event);
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2010-08-07 10:57:15 +00:00
|
|
|
case GHOST_kEventNDOFMotion: {
|
|
|
|
event.type = NDOF_MOTION;
|
|
|
|
attach_ndof_data(&event, customdata);
|
|
|
|
wm_event_add(win, &event);
|
|
|
|
|
2011-07-25 00:03:07 +00:00
|
|
|
//printf("sending NDOF_MOTION, prev = %d %d\n", event.x, event.y);
|
|
|
|
|
2010-08-07 10:57:15 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case GHOST_kEventNDOFButton: {
|
|
|
|
GHOST_TEventNDOFButtonData* e = customdata;
|
|
|
|
|
|
|
|
event.type = NDOF_BUTTON_NONE + e->button;
|
|
|
|
|
|
|
|
switch (e->action) {
|
|
|
|
case GHOST_kPress:
|
|
|
|
event.val = KM_PRESS;
|
|
|
|
break;
|
|
|
|
case GHOST_kRelease:
|
|
|
|
event.val = KM_RELEASE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
event.custom = 0;
|
|
|
|
event.customdata = NULL;
|
|
|
|
|
|
|
|
wm_event_add(win, &event);
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
case GHOST_kEventUnknown:
|
|
|
|
case GHOST_kNumEventTypes:
|
|
|
|
break;
|
2009-12-08 13:02:03 +00:00
|
|
|
|
|
|
|
case GHOST_kEventWindowDeactivate: {
|
|
|
|
event.type= WINDEACTIVATE;
|
|
|
|
wm_event_add(win, &event);
|
|
|
|
|
|
|
|
break;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
2009-12-08 13:02:03 +00:00
|
|
|
}
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|
2011-10-22 01:53:35 +00:00
|
|
|
|
|
|
|
/* Handy when debugging checking events */
|
|
|
|
/* WM_event_print(&event); */
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
}
|