2011-02-23 10:52:22 +00:00
|
|
|
/*
|
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/wm_event_system.h
|
|
|
|
|
* \ingroup wm
|
|
|
|
|
*/
|
|
|
|
|
|
2012-02-17 18:59:41 +00:00
|
|
|
#ifndef __WM_EVENT_SYSTEM_H__
|
|
|
|
|
#define __WM_EVENT_SYSTEM_H__
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
|
/* return value of handler-operator call */
|
2012-10-21 05:46:41 +00:00
|
|
|
#define WM_HANDLER_CONTINUE 0
|
|
|
|
|
#define WM_HANDLER_BREAK 1
|
|
|
|
|
#define WM_HANDLER_HANDLED 2
|
|
|
|
|
#define WM_HANDLER_MODAL 4 /* MODAL|BREAK means unhandled */
|
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
|
|
|
struct ScrArea;
|
|
|
|
|
struct ARegion;
|
2007-12-24 18:27:28 +00:00
|
|
|
|
|
|
|
|
/* wmKeyMap is in DNA_windowmanager.h, it's savable */
|
|
|
|
|
|
|
|
|
|
typedef struct wmEventHandler {
|
|
|
|
|
struct wmEventHandler *next, *prev;
|
2012-10-21 05:46:41 +00:00
|
|
|
|
2015-06-01 16:40:43 +10:00
|
|
|
char type; /* WM_HANDLER_DEFAULT, ... */
|
|
|
|
|
char flag; /* WM_HANDLER_BLOCKING, ... */
|
2012-10-21 05:46:41 +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
|
|
|
/* keymap handler */
|
2012-10-21 05:46:41 +00:00
|
|
|
wmKeyMap *keymap; /* pointer to builtin/custom keymaps */
|
2014-01-19 23:14:24 +11:00
|
|
|
const rcti *bblocal, *bbwin; /* optional local and windowspace bb */
|
2018-05-20 22:34:18 +02:00
|
|
|
/* Run after the keymap item runs. */
|
|
|
|
|
void (*keymap_callback)(wmKeyMap *keymap, wmKeyMapItem *kmi, void *user_data);
|
|
|
|
|
void *keymap_callback_user_data;
|
2012-10-21 05:46:41 +00:00
|
|
|
|
2017-07-19 21:42:41 +02:00
|
|
|
/* modal operator handler */
|
2012-10-21 05:46:41 +00:00
|
|
|
wmOperator *op; /* for derived/modal handlers */
|
|
|
|
|
struct ScrArea *op_area; /* for derived/modal handlers */
|
|
|
|
|
struct ARegion *op_region; /* for derived/modal handlers */
|
2015-04-27 18:53:45 +10:00
|
|
|
short op_region_type; /* for derived/modal handlers */
|
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
|
|
|
|
|
|
|
|
/* ui handler */
|
2012-10-21 05:46:41 +00:00
|
|
|
wmUIHandlerFunc ui_handle; /* callback receiving events */
|
|
|
|
|
wmUIHandlerRemoveFunc ui_remove; /* callback when handler is removed */
|
|
|
|
|
void *ui_userdata; /* user data pointer */
|
|
|
|
|
struct ScrArea *ui_area; /* for derived/modal handlers */
|
|
|
|
|
struct ARegion *ui_region; /* for derived/modal handlers */
|
|
|
|
|
struct ARegion *ui_menu; /* for derived/modal handlers */
|
|
|
|
|
|
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 box handler */
|
|
|
|
|
ListBase *dropboxes;
|
2016-10-07 16:34:55 +02:00
|
|
|
/* manipulator handler */
|
|
|
|
|
struct wmManipulatorMap *manipulator_map;
|
2007-12-24 18:27:28 +00:00
|
|
|
} wmEventHandler;
|
|
|
|
|
|
2017-11-05 14:33:18 +11:00
|
|
|
/* custom types for handlers, for signaling, freeing */
|
2007-12-24 18:27:28 +00:00
|
|
|
enum {
|
|
|
|
|
WM_HANDLER_DEFAULT,
|
2009-02-16 12:14:04 +00:00
|
|
|
WM_HANDLER_FILESELECT
|
2007-12-24 18:27:28 +00:00
|
|
|
};
|
|
|
|
|
|
2008-12-08 15:02:57 +00:00
|
|
|
/* wm_event_system.c */
|
2012-10-21 05:46:41 +00:00
|
|
|
void wm_event_free_all (wmWindow *win);
|
|
|
|
|
void wm_event_free (wmEvent *event);
|
|
|
|
|
void wm_event_free_handler (wmEventHandler *handler);
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2012-10-21 05:46:41 +00:00
|
|
|
/* goes over entire hierarchy: events -> window -> screen -> area -> region */
|
|
|
|
|
void wm_event_do_handlers (bContext *C);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2012-10-21 05:46:41 +00:00
|
|
|
void wm_event_add_ghostevent (wmWindowManager *wm, wmWindow *win, int type, int time, void *customdata);
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2017-08-25 20:26:52 +10:00
|
|
|
void wm_event_do_refresh_wm_and_depsgraph(bContext *C);
|
|
|
|
|
void wm_event_do_notifiers(bContext *C);
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2008-12-08 15:02:57 +00:00
|
|
|
/* wm_keymap.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
|
|
|
/* wm_dropbox.c */
|
2012-10-21 05:46:41 +00:00
|
|
|
void wm_dropbox_free(void);
|
2017-10-14 17:29:54 +11:00
|
|
|
void wm_drags_check_ops(bContext *C, const wmEvent *event);
|
2012-10-21 05:46:41 +00:00
|
|
|
void wm_drags_draw(bContext *C, wmWindow *win, rcti *rect);
|
2008-12-08 15:02:57 +00:00
|
|
|
|
2012-02-17 18:59:41 +00:00
|
|
|
#endif /* __WM_EVENT_SYSTEM_H__ */
|
