This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
blender-archive/source/blender/windowmanager/intern/wm_event_system.c

3091 lines
86 KiB
C
Raw Normal View History

/*
* ***** 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.
*
* 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
*/
#include <stdlib.h>
#include <string.h>
#include "DNA_listBase.h"
#include "DNA_screen_types.h"
#include "DNA_scene_types.h"
#include "DNA_windowmanager_types.h"
#include "DNA_userdef_types.h"
#include "MEM_guardedalloc.h"
#include "GHOST_C-api.h"
#include "BLI_blenlib.h"
#include "BLI_utildefines.h"
#include "BLI_math.h"
#include "BKE_blender.h"
#include "BKE_context.h"
#include "BKE_idprop.h"
#include "BKE_global.h"
#include "BKE_main.h"
#include "BKE_report.h"
#include "BKE_scene.h"
#include "BKE_screen.h"
#include "BKE_sound.h"
#include "ED_fileselect.h"
#include "ED_info.h"
#include "ED_render.h"
#include "ED_screen.h"
#include "ED_view3d.h"
#include "ED_util.h"
#include "RNA_access.h"
#include "BIF_gl.h"
#include "UI_interface.h"
#include "PIL_time.h"
#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"
#include "wm_draw.h"
#ifndef NDEBUG
# include "RNA_enum_types.h"
#endif
static int wm_operator_call_internal(bContext *C, wmOperatorType *ot, PointerRNA *properties, ReportList *reports,
short context, short poll_only);
/* ************ event management ************** */
void wm_event_add(wmWindow *win, wmEvent *event_to_add)
{
wmEvent *event = MEM_callocN(sizeof(wmEvent), "wmEvent");
*event = *event_to_add;
BLI_addtail(&win->queue, event);
}
void wm_event_free(wmEvent *event)
{
if (event->customdata) {
if (event->customdatafree) {
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
/* note: pointer to listbase struct elsewhere */
if (event->custom == EVT_DATA_LISTBASE)
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
BLI_freelistN(event->customdata);
else
MEM_freeN(event->customdata);
}
}
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);
}
}
/* ********************* notifiers, listeners *************** */
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;
}
/* XXX: in future, which notifiers to send to other windows? */
void WM_event_add_notifier(const bContext *C, unsigned int type, void *reference)
{
ARegion *ar;
wmNotifier *note = MEM_callocN(sizeof(wmNotifier), "notifier");
note->wm = CTX_wm_manager(C);
BLI_addtail(&note->wm->queue, note);
note->window = CTX_wm_window(C);
ar = CTX_wm_region(C);
if (ar)
note->swinid = ar->swinid;
note->category = type & NOTE_CATEGORY;
note->data = type & NOTE_DATA;
note->subtype = type & NOTE_SUBTYPE;
note->action = type & NOTE_ACTION;
note->reference = reference;
}
void WM_main_add_notifier(unsigned int type, void *reference)
{
Main *bmain = G.main;
wmWindowManager *wm = bmain->wm.first;
if (wm && !wm_test_duplicate_notifier(wm, type, reference)) {
wmNotifier *note = MEM_callocN(sizeof(wmNotifier), "notifier");
note->wm = wm;
BLI_addtail(&note->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;
}
}
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)
{
wmWindowManager *wm = CTX_wm_manager(C);
wmNotifier *note, *next;
wmWindow *win;
uint64_t win_combine_v3d_datamask = 0;
if (wm == NULL)
return;
/* cache & catch WM level notifiers, such as frame change, scene/screen set */
for (win = wm->windows.first; win; win = win->next) {
int do_anim = FALSE;
CTX_wm_window_set(C, win);
for (note = wm->queue.first; note; note = next) {
next = note->next;
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);
}
if (note->window == win) {
if (note->category == NC_SCREEN) {
if (note->data == ND_SCREENBROWSE) {
ED_screen_set(C, note->reference); // XXX hrms, think this over!
if (G.debug & G_DEBUG_EVENTS)
printf("%s: screen set %p\n", __func__, 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
}
else if (note->data == ND_SCREENDELETE) {
ED_screen_delete(C, note->reference); // XXX hrms, think this over!
if (G.debug & G_DEBUG_EVENTS)
printf("%s: screen delete %p\n", __func__, note->reference);
}
}
}
if (note->window == win ||
(note->window == NULL && (note->reference == NULL || note->reference == CTX_data_scene(C))))
{
if (note->category == NC_SCENE) {
if (note->data == ND_FRAME)
do_anim = TRUE;
}
}
if (ELEM5(note->category, NC_SCENE, NC_OBJECT, NC_GEOM, NC_SCENE, NC_WM)) {
ED_info_stats_clear(CTX_data_scene(C));
WM_event_add_notifier(C, NC_SPACE | ND_SPACE_INFO, NULL);
}
}
if (do_anim) {
/* XXX, quick frame changes can cause a crash if framechange and rendering
* collide (happens on slow scenes), BKE_scene_update_for_newframe can be called
* twice which can depgraph update the same object at once */
if (G.is_rendering == FALSE) {
/* depsgraph gets called, might send more notifiers */
ED_update_for_newframe(CTX_data_main(C), win->screen->scene, 1);
}
}
}
/* the notifiers are sent without context, to keep it clean */
while ( (note = wm_notifier_next(wm)) ) {
for (win = wm->windows.first; win; win = win->next) {
/* filter out notifiers */
2012-10-07 09:48:59 +00:00
if (note->category == NC_SCREEN && note->reference && note->reference != win->screen) {
/* pass */
}
else if (note->category == NC_SCENE && note->reference && note->reference != win->screen->scene) {
/* pass */
}
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
/* 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
/* printf("notifier win %d screen %s cat %x\n", win->winid, win->screen->id.name+2, note->category); */
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
for (ar = win->screen->regionbase.first; ar; ar = ar->next) {
ED_region_do_listen(ar, note);
}
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);
}
}
}
}
MEM_freeN(note);
}
/* 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_view3d_screen_datamask(win->screen);
}
/* cached: editor refresh callbacks now, they get context */
for (win = wm->windows.first; win; win = win->next) {
ScrArea *sa;
CTX_wm_window_set(C, win);
for (sa = win->screen->areabase.first; sa; sa = sa->next) {
if (sa->do_refresh) {
CTX_wm_area_set(C, sa);
ED_area_do_refresh(C, sa);
}
}
/* XXX make lock in future, or separated derivedmesh users in scene */
if (G.is_rendering == FALSE) {
/* depsgraph & animation: update tagged datablocks */
Main *bmain = CTX_data_main(C);
/* copied to set's in scene_update_tagged_recursive() */
win->screen->scene->customdata_mask = win_combine_v3d_datamask;
/* XXX, hack so operators can enforce datamasks [#26482], gl render */
win->screen->scene->customdata_mask |= win->screen->scene->customdata_mask_modal;
BKE_scene_update_tagged(bmain, win->screen->scene);
}
}
CTX_wm_window_set(C, NULL);
}
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);
}
/* ********************* 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);
static int do_wheel_ui = TRUE;
int is_wheel = ELEM3(event->type, WHEELUPMOUSE, WHEELDOWNMOUSE, MOUSEPAN);
int retval;
/* UI code doesn't handle return values - it just always returns break.
2012-11-18 01:22:31 +00:00
* to make the DBL_CLICK conversion work, we just don't send this to UI */
if (event->val == KM_DBL_CLICK)
return WM_HANDLER_CONTINUE;
2011-06-06 00:48:10 +00:00
/* UI is quite aggressive with swallowing events, like scrollwheel */
/* I realize this is not extremely nice code... when UI gets keymaps it can be maybe smarter */
if (do_wheel_ui == FALSE) {
if (is_wheel)
return WM_HANDLER_CONTINUE;
else if (wm_event_always_pass(event) == 0)
do_wheel_ui = TRUE;
}
/* 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);
}
if (retval == WM_UI_HANDLER_BREAK)
return WM_HANDLER_BREAK;
/* event not handled in UI, if wheel then we temporarily disable it */
if (is_wheel)
do_wheel_ui = FALSE;
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 ******************* */
int WM_operator_poll(bContext *C, wmOperatorType *ot)
{
wmOperatorTypeMacro *otmacro;
for (otmacro = ot->macro.first; otmacro; otmacro = otmacro->next) {
wmOperatorType *ot_macro = WM_operatortype_find(otmacro->idname, 0);
if (0 == WM_operator_poll(C, ot_macro))
return 0;
}
/* python needs operator type, so we added exception for it */
if (ot->pyop_poll)
return ot->pyop_poll(C, ot);
else if (ot->poll)
return ot->poll(C);
return 1;
}
/* sets up the new context and calls 'wm_operator_invoke()' with poll_only */
int WM_operator_poll_context(bContext *C, wmOperatorType *ot, short context)
{
return wm_operator_call_internal(C, ot, NULL, NULL, context, TRUE);
}
static void wm_operator_print(bContext *C, wmOperator *op)
{
/* context is needed for enum function */
char *buf = WM_operator_pystring(C, op->type, op->ptr, 1);
printf("%s\n", buf);
MEM_freeN(buf);
}
/* 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, \n"
" shift:%d, ctrl:%d, alt:%d, oskey:%d, keymodifier:%d, \n"
" mouse:(%d,%d), ascii:'%c', utf8:'%.*s', "
" 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,
BLI_str_utf8_size(event->utf8_buf), event->utf8_buf,
event->keymap_idname, (void *)event);
}
else {
printf("wmEvent - NULL\n");
}
}
#endif /* NDEBUG */
2012-02-04 00:36:55 +00:00
/* (caller_owns_reports == TRUE) when called from python */
static void wm_operator_reports(bContext *C, wmOperator *op, int retval, int caller_owns_reports)
{
2012-02-04 00:36:55 +00:00
if (caller_owns_reports == FALSE) { /* popup */
if (op->reports->list.first) {
/* FIXME, temp setting window, see other call to uiPupMenuReports for why */
wmWindow *win_prev = CTX_wm_window(C);
ScrArea *area_prev = CTX_wm_area(C);
ARegion *ar_prev = CTX_wm_region(C);
if (win_prev == NULL)
CTX_wm_window_set(C, CTX_wm_manager(C)->windows.first);
uiPupMenuReports(C, op->reports);
CTX_wm_window_set(C, win_prev);
CTX_wm_area_set(C, area_prev);
CTX_wm_region_set(C, ar_prev);
}
}
if (retval & OPERATOR_FINISHED) {
if (G.debug & G_DEBUG_WM) {
2012-02-04 00:36:55 +00:00
/* todo - this print may double up, might want to check more flags then the FINISHED */
wm_operator_print(C, op);
}
if (caller_owns_reports == FALSE) {
BKE_reports_print(op->reports, RPT_DEBUG); /* print out reports to console. */
}
if (op->type->flag & OPTYPE_REGISTER) {
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);
}
}
}
2012-02-04 00:36:55 +00:00
/* if the caller owns them, handle this */
if (op->reports->list.first && (op->reports->flag & RPT_OP_HOLD) == 0) {
wmWindowManager *wm = CTX_wm_manager(C);
ReportList *wm_reports = CTX_wm_reports(C);
ReportTimerInfo *rti;
/* add reports to the global list, otherwise they are not seen */
BLI_movelisttolist(&wm_reports->list, &op->reports->list);
/* After adding reports to the global list, reset the report timer. */
WM_event_remove_timer(wm, NULL, wm_reports->reporttimer);
/* Records time since last report was added */
wm_reports->reporttimer = WM_event_add_timer(wm, CTX_wm_window(C), TIMERREPORT, 0.05);
rti = MEM_callocN(sizeof(ReportTimerInfo), "ReportTimerInfo");
wm_reports->reporttimer->customdata = rti;
}
}
/* 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)
{
return wm && (wm->op_undo_depth == 0) && (ot->flag & OPTYPE_REGISTER);
}
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
2012-03-09 18:28:30 +00:00
* 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.debug & G_DEBUG_WM) {
char *buf = WM_operator_pystring(C, op->type, op->ptr, 1);
BKE_report(CTX_wm_reports(C), RPT_OPERATOR, buf);
MEM_freeN(buf);
}
if (wm_operator_register_check(wm, op->type))
wm_operator_register(C, op);
else
WM_operator_free(op);
}
}
/* if repeat is true, it doesn't register again, nor does it free */
static int wm_operator_exec(bContext *C, wmOperator *op, int repeat)
{
wmWindowManager *wm = CTX_wm_manager(C);
int retval = OPERATOR_CANCELLED;
CTX_wm_operator_poll_msg_set(C, NULL);
if (op == NULL || op->type == NULL)
return retval;
if (0 == WM_operator_poll(C, op->type))
return retval;
if (op->type->exec) {
if (op->type->flag & OPTYPE_UNDO)
wm->op_undo_depth++;
retval = op->type->exec(C, op);
OPERATOR_RETVAL_CHECK(retval);
if (op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
wm->op_undo_depth--;
}
/* XXX Disabled the repeat check to address part 2 of #31840.
* Carefully checked all calls to wm_operator_exec and WM_operator_repeat, don't see any reason
* why this was needed, but worth to note it in case something turns bad. (mont29) */
if (retval & (OPERATOR_FINISHED | OPERATOR_CANCELLED)/* && repeat == 0 */)
2012-02-04 00:36:55 +00:00
wm_operator_reports(C, op, retval, FALSE);
if (retval & OPERATOR_FINISHED) {
if (repeat) {
if (wm->op_undo_depth == 0) { /* not called by py script */
WM_operator_last_properties_store(op);
}
}
wm_operator_finished(C, op, repeat);
}
else if (repeat == 0) {
WM_operator_free(op);
}
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;
}
/* simply calls exec with basic checks */
static int wm_operator_exec_notest(bContext *C, wmOperator *op)
{
int retval = OPERATOR_CANCELLED;
if (op == NULL || op->type == NULL || op->type->exec == NULL)
return retval;
retval = op->type->exec(C, op);
OPERATOR_RETVAL_CHECK(retval);
return retval;
}
/* for running operators with frozen context (modal handlers, menus)
*
* warning: do not use this within an operator to call its self! [#29537] */
int WM_operator_call(bContext *C, wmOperator *op)
{
return wm_operator_exec(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
/* this is intended to be used when an invoke operator wants to call exec on its self
* and is basically like running op->type->exec() directly, no poll checks no freeing,
2012-07-16 23:23:33 +00:00
* since we assume whoever called invoke will take care of that */
int WM_operator_call_notest(bContext *C, wmOperator *op)
{
return wm_operator_exec_notest(C, op);
}
/* 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);
}
/* 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;
}
2012-08-01 10:44:55 +00:00
static wmOperator *wm_operator_create(wmWindowManager *wm, wmOperatorType *ot,
PointerRNA *properties, ReportList *reports)
{
/* XXX operatortype names are static still. for debug */
wmOperator *op = MEM_callocN(sizeof(wmOperator), ot->idname);
/* 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) {
op->reports = reports; /* must be initialized already */
}
else {
op->reports = MEM_mallocN(sizeof(ReportList), "wmOperatorReportList");
BKE_reports_init(op->reports, RPT_STORE | RPT_FREE);
}
/* 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;
/* ensure all ops are in execution order in 1 list */
if (motherop == NULL) {
2009-12-05 19:05:21 +00:00
motherop = op;
root = 1;
}
/* 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);
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() */
}
}
2009-12-05 19:05:21 +00:00
if (root)
motherop = NULL;
}
WM_operator_properties_sanitize(op->ptr, 0);
return op;
}
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;
}
else {
/* these values are invalid (avoid odd behavior by relying on old mval values) */
event->mval[0] = -1;
event->mval[1] = -1;
}
}
#if 1 /* disabling for 2.63 release, since we keep getting reports some menu items are leaving props undefined */
int WM_operator_last_properties_init(wmOperator *op)
{
int change = FALSE;
if (op->type->last_properties) {
PropertyRNA *iterprop;
if (G.debug & G_DEBUG_WM) {
printf("%s: loading previous properties for '%s'\n", __func__, op->type->idname);
}
iterprop = RNA_struct_iterator_property(op->type->srna);
RNA_PROP_BEGIN (op->ptr, itemptr, iterprop)
{
PropertyRNA *prop = itemptr.data;
if ((RNA_property_flag(prop) & PROP_SKIP_SAVE) == 0) {
if (!RNA_property_is_set(op->ptr, prop)) { /* don't override a setting already set */
const char *identifier = RNA_property_identifier(prop);
IDProperty *idp_src = IDP_GetPropertyFromGroup(op->type->last_properties, identifier);
if (idp_src) {
IDProperty *idp_dst = IDP_CopyProperty(idp_src);
/* note - in the future this may need to be done recursively,
* but for now RNA doesn't access nested operators */
idp_dst->flag |= IDP_FLAG_GHOST;
IDP_ReplaceInGroup(op->properties, idp_dst);
change = TRUE;
}
}
}
}
RNA_PROP_END;
}
return change;
}
int WM_operator_last_properties_store(wmOperator *op)
{
if (op->type->last_properties) {
IDP_FreeProperty(op->type->last_properties);
MEM_freeN(op->type->last_properties);
op->type->last_properties = NULL;
}
if (op->properties) {
if (G.debug & G_DEBUG_WM) {
printf("%s: storing properties for '%s'\n", __func__, op->type->idname);
}
op->type->last_properties = IDP_CopyProperty(op->properties);
return TRUE;
}
else {
return FALSE;
}
}
#else
int WM_operator_last_properties_init(wmOperator *UNUSED(op))
{
return FALSE;
}
int WM_operator_last_properties_store(wmOperator *UNUSED(op))
{
return FALSE;
}
#endif
2012-08-01 10:44:55 +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
{
wmWindowManager *wm = CTX_wm_manager(C);
int 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
/* 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);
if (WM_operator_poll(C, ot)) {
2012-05-27 19:40:36 +00:00
wmOperator *op = wm_operator_create(wm, ot, properties, reports); /* if reports == NULL, they'll be initialized */
const short is_nested_call = (wm->op_undo_depth != 0);
/* initialize setting from previous run */
if (!is_nested_call) { /* not called by py script */
WM_operator_last_properties_init(op);
}
if ((G.debug & G_DEBUG_HANDLERS) && event && event->type != MOUSEMOVE) {
2012-08-01 10:44:55 +00:00
printf("%s: handle evt %d win %d op %s\n",
__func__, event ? event->type : 0, CTX_wm_screen(C)->subwinactive, ot->idname);
}
if (op->type->invoke && event) {
wm_region_mouse_co(C, event);
if (op->type->flag & OPTYPE_UNDO)
wm->op_undo_depth++;
retval = op->type->invoke(C, op, event);
OPERATOR_RETVAL_CHECK(retval);
if (op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
wm->op_undo_depth--;
}
else if (op->type->exec) {
if (op->type->flag & OPTYPE_UNDO)
wm->op_undo_depth++;
retval = op->type->exec(C, op);
OPERATOR_RETVAL_CHECK(retval);
if (op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
wm->op_undo_depth--;
}
else {
/* debug, important to leave a while, should never happen */
2012-06-17 11:36:28 +00:00
printf("%s: invalid operator call '%s'\n", __func__, ot->idname);
}
/* Note, if the report is given as an argument then assume the caller will deal with displaying them
* currently python only uses this */
if (!(retval & OPERATOR_HANDLED) && (retval & (OPERATOR_FINISHED | OPERATOR_CANCELLED))) {
/* only show the report if the report list was not given in the function */
2012-02-04 00:36:55 +00:00
wm_operator_reports(C, op, retval, (reports != NULL));
}
2012-10-14 13:08:19 +00:00
if (retval & OPERATOR_HANDLED) {
/* do nothing, wm_operator_exec() has been called somewhere */
}
else if (retval & OPERATOR_FINISHED) {
if (!is_nested_call) { /* not called by py script */
WM_operator_last_properties_store(op);
}
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
}
else if (retval & OPERATOR_RUNNING_MODAL) {
/* grab cursor during blocking modal ops (X11)
* Also check for macro
2012-02-04 00:36:55 +00:00
*/
if (ot->flag & OPTYPE_BLOCKING || (op->opm && op->opm->type->flag & OPTYPE_BLOCKING)) {
int bounds[4] = {-1, -1, -1, -1};
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));
}
/* exception, cont. grab in header is annoying */
if (wrap) {
ARegion *ar = CTX_wm_region(C);
if (ar && ar->regiontype == RGN_TYPE_HEADER) {
wrap = FALSE;
}
}
if (wrap) {
rcti *winrect = NULL;
ARegion *ar = CTX_wm_region(C);
ScrArea *sa = CTX_wm_area(C);
if (ar && ar->regiontype == RGN_TYPE_WINDOW && event &&
BLI_rcti_isect_pt_v(&ar->winrct, &event->x))
{
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;
}
}
2012-08-11 21:35:24 +00:00
WM_cursor_grab_enable(CTX_wm_window(C), wrap, FALSE, bounds);
}
/* cancel UI handlers, typically tooltips that can hang around
2012-03-09 18:28:30 +00:00
* 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
}
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;
}
/* 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 */
static int wm_operator_call_internal(bContext *C, wmOperatorType *ot, PointerRNA *properties, ReportList *reports,
short context, short poll_only)
{
wmWindow *window = CTX_wm_window(C);
wmEvent *event;
int retval;
CTX_wm_operator_poll_msg_set(C, NULL);
/* dummie test */
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;
}
switch (context) {
case WM_OP_EXEC_REGION_WIN:
case WM_OP_INVOKE_REGION_WIN:
case WM_OP_EXEC_REGION_CHANNELS:
case WM_OP_INVOKE_REGION_CHANNELS:
case WM_OP_EXEC_REGION_PREVIEW:
case WM_OP_INVOKE_REGION_PREVIEW:
{
/* 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
*/
ARegion *ar = CTX_wm_region(C);
ScrArea *area = CTX_wm_area(C);
int type = RGN_TYPE_WINDOW;
switch (context) {
case WM_OP_EXEC_REGION_CHANNELS:
case WM_OP_INVOKE_REGION_CHANNELS:
type = RGN_TYPE_CHANNELS;
break;
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);
if (ar1)
CTX_wm_region_set(C, ar1);
}
retval = wm_operator_invoke(C, ot, event, properties, reports, poll_only);
/* set region back */
CTX_wm_region_set(C, ar);
return retval;
}
case WM_OP_EXEC_AREA:
case WM_OP_INVOKE_AREA:
{
/* remove region from context */
ARegion *ar = CTX_wm_region(C);
CTX_wm_region_set(C, NULL);
retval = wm_operator_invoke(C, ot, event, properties, reports, poll_only);
CTX_wm_region_set(C, ar);
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);
retval = wm_operator_invoke(C, ot, event, properties, reports, poll_only);
CTX_wm_area_set(C, area);
CTX_wm_region_set(C, ar);
return retval;
}
case WM_OP_EXEC_DEFAULT:
case WM_OP_INVOKE_DEFAULT:
return wm_operator_invoke(C, ot, event, properties, reports, poll_only);
}
}
return 0;
}
/* invokes operator in context */
int WM_operator_name_call(bContext *C, const char *opstring, short context, PointerRNA *properties)
{
wmOperatorType *ot = WM_operatortype_find(opstring, 0);
if (ot)
return wm_operator_call_internal(C, ot, properties, NULL, context, FALSE);
return 0;
}
/* Similar to WM_operator_name_call called with WM_OP_EXEC_DEFAULT context.
2012-03-09 18:28:30 +00:00
* - wmOperatorType is used instead of operator name since python already has the operator type
* - poll() must be called by python before this runs.
* - reports can be passed to this function (so python can report them as exceptions)
*/
2012-08-01 10:44:55 +00:00
int WM_operator_call_py(bContext *C, wmOperatorType *ot, short context,
PointerRNA *properties, ReportList *reports, short is_undo)
{
int retval = OPERATOR_CANCELLED;
#if 0
wmOperator *op;
op = wm_operator_create(wm, ot, properties, reports);
if (op->type->exec) {
if (is_undo && op->type->flag & OPTYPE_UNDO)
wm->op_undo_depth++;
retval = op->type->exec(C, op);
OPERATOR_RETVAL_CHECK(retval);
if (is_undo && op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
wm->op_undo_depth--;
}
else
printf("error \"%s\" operator has no exec function, python cannot call it\n", op->type->name);
#endif
/* not especially nice using undo depth here, its used so py never
* triggers undo or stores operators last used state.
*
* we could have some more obvious way of doing this like passing a flag.
*/
wmWindowManager *wm = CTX_wm_manager(C);
if (!is_undo && wm) wm->op_undo_depth++;
retval = wm_operator_call_internal(C, ot, properties, reports, context, FALSE);
if (!is_undo && wm && (wm == CTX_wm_manager(C))) wm->op_undo_depth--;
/* keep the reports around if needed later */
if ((retval & OPERATOR_RUNNING_MODAL) ||
((retval & OPERATOR_FINISHED) && wm_operator_register_check(CTX_wm_manager(C), ot)))
{
reports->flag |= RPT_FREE; /* let blender manage freeing */
}
return retval;
}
/* ********************* handlers *************** */
/* future extra customadata free? */
void wm_event_free_handler(wmEventHandler *handler)
{
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
if (screen && handler->op) {
if (handler->op_area == NULL)
CTX_wm_area_set(C, NULL);
else {
ScrArea *sa;
for (sa = screen->areabase.first; sa; sa = sa->next)
if (sa == handler->op_area)
break;
if (sa == NULL) {
/* when changing screen layouts with running modal handlers (like render display), this
2012-03-09 18:28:30 +00:00
* is not an error to print */
if (handler->op == NULL)
printf("internal error: handler (%s) has invalid area\n", handler->op->type->idname);
}
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);
}
}
}
}
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)
{
wmEventHandler *handler;
wmWindowManager *wm = CTX_wm_manager(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
/* C is zero on freeing database, modal handlers then already were freed */
while ((handler = handlers->first)) {
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
BLI_remlink(handlers, handler);
if (handler->op) {
if (handler->op->type->cancel) {
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
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
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
if (handler->op->type->flag & OPTYPE_UNDO)
wm->op_undo_depth--;
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
}
WM_cursor_grab_disable(CTX_wm_window(C), NULL);
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
}
else if (handler->ui_remove) {
ScrArea *area = CTX_wm_area(C);
ARegion *region = CTX_wm_region(C);
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
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);
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->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
CTX_wm_area_set(C, area);
CTX_wm_region_set(C, region);
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
}
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
}
/* do userdef mappings */
int WM_userdef_event_map(int kmitype)
{
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;
}
return kmitype;
}
static int wm_eventmatch(wmEvent *winevent, wmKeyMapItem *kmi)
{
int kmitype = WM_userdef_event_map(kmi->type);
if (kmi->flag & KMI_INACTIVE) return 0;
/* the matching rules */
if (kmitype == KM_TEXTINPUT)
2012-11-18 01:22:31 +00:00
if (winevent->val == KM_PRESS) { /* prevent double clicks */
/* NOT using ISTEXTINPUT anymore because (at least on Windows) some key codes above 255
2012-11-18 01:22:31 +00:00
* could have printable ascii keys - BUG [#30479] */
if (ISKEYBOARD(winevent->type) && (winevent->ascii || winevent->utf8_buf[0])) return 1;
}
if (kmitype != KM_ANY)
if (winevent->type != kmitype) return 0;
if (kmi->val != KM_ANY)
if (winevent->val != kmi->val) return 0;
/* modifiers also check bits, so it allows modifier order */
if (kmi->shift != KM_ANY)
if (winevent->shift != kmi->shift && !(winevent->shift & kmi->shift)) return 0;
if (kmi->ctrl != KM_ANY)
if (winevent->ctrl != kmi->ctrl && !(winevent->ctrl & kmi->ctrl)) return 0;
if (kmi->alt != KM_ANY)
if (winevent->alt != kmi->alt && !(winevent->alt & kmi->alt)) return 0;
if (kmi->oskey != KM_ANY)
if (winevent->oskey != kmi->oskey && !(winevent->oskey & kmi->oskey)) return 0;
if (kmi->keymodifier)
if (winevent->keymodifier != kmi->keymodifier) return 0;
return 1;
}
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 */
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
{
/* support for modal keymap in macros */
if (op->opm)
op = op->opm;
if (op->type->modalkeymap) {
wmKeyMap *keymap = WM_keymap_active(CTX_wm_manager(C), op->type->modalkeymap);
wmKeyMapItem *kmi;
for (kmi = keymap->items.first; kmi; kmi = kmi->next) {
if (wm_eventmatch(event, kmi)) {
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->prevtype = event->type;
event->prevval = event->val;
event->type = EVT_MODAL_MAP;
event->val = kmi->propvalue;
break;
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
}
}
}
}
/* bad hacking event system... better restore event type for checking of KM_CLICK for example */
/* XXX modal maps could use different method (ton) */
static void wm_event_modalmap_end(wmEvent *event)
{
if (event->type == EVT_MODAL_MAP) {
event->type = event->prevtype;
event->prevtype = 0;
event->val = event->prevval;
event->prevval = 0;
}
}
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 */
static int wm_handler_operator_call(bContext *C, ListBase *handlers, wmEventHandler *handler,
wmEvent *event, PointerRNA *properties)
{
int retval = OPERATOR_PASS_THROUGH;
/* derived, modal or blocking operator */
if (handler->op) {
wmOperator *op = handler->op;
wmOperatorType *ot = op->type;
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
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 */
wmWindowManager *wm = CTX_wm_manager(C);
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
wm_handler_op_context(C, handler);
wm_region_mouse_co(C, event);
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
if (ot->flag & OPTYPE_UNDO)
wm->op_undo_depth++;
retval = ot->modal(C, op, event);
OPERATOR_RETVAL_CHECK(retval);
wm_event_modalmap_end(event);
/* 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) {
if (ot->flag & OPTYPE_UNDO)
wm->op_undo_depth--;
/* 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);
}
if (retval & (OPERATOR_CANCELLED | OPERATOR_FINISHED))
2012-02-04 00:36:55 +00:00
wm_operator_reports(C, op, retval, FALSE);
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;
}
2012-03-08 04:12:11 +00:00
/* remove modal handler, operator itself should have been canceled and freed */
if (retval & (OPERATOR_CANCELLED | OPERATOR_FINISHED)) {
WM_cursor_grab_disable(CTX_wm_window(C), NULL);
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
}
2012-06-17 11:36:28 +00:00
else {
printf("%s: error '%s' missing modal\n", __func__, op->idname);
2012-06-17 11:36:28 +00:00
}
}
else {
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
if (ot) {
retval = wm_operator_invoke(C, ot, event, properties, NULL, FALSE);
}
}
/* Finished and pass through flag as handled */
/* Finished and pass through flag as handled */
if (retval == (OPERATOR_FINISHED | OPERATOR_PASS_THROUGH))
return WM_HANDLER_HANDLED;
/* Modal unhandled, break */
if (retval == (OPERATOR_PASS_THROUGH | OPERATOR_RUNNING_MODAL))
return (WM_HANDLER_BREAK | WM_HANDLER_MODAL);
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;
}
/* 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)
{
wmWindowManager *wm = CTX_wm_manager(C);
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:
{
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;
}
else {
sa = handler->op_area;
}
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); */
/* settings for filebrowser, sfile is not operator owner but sends events */
sfile = (SpaceFile *)sa->spacedata.first;
sfile->op = handler->op;
ED_fileselect_set_params(sfile);
action = WM_HANDLER_BREAK;
}
break;
case EVT_FILESELECT_EXEC:
case EVT_FILESELECT_CANCEL:
case EVT_FILESELECT_EXTERNAL_CANCEL:
{
/* XXX validate area and region? */
bScreen *screen = CTX_wm_screen(C);
/* remlink now, for load file case before removing*/
BLI_remlink(handlers, handler);
if (event->val != EVT_FILESELECT_EXTERNAL_CANCEL) {
if (screen != handler->filescreen) {
ED_screen_full_prevspace(C, CTX_wm_area(C));
}
else {
ED_area_prevspace(C, CTX_wm_area(C));
2010-09-18 03:55:56 +00:00
}
}
wm_handler_op_context(C, handler);
/* needed for uiPupMenuReports */
if (event->val == EVT_FILESELECT_EXEC) {
int retval;
if (handler->op->type->flag & OPTYPE_UNDO)
wm->op_undo_depth++;
retval = handler->op->type->exec(C, handler->op);
/* XXX check this carefully, CTX_wm_manager(C) == wm is a bit hackish */
if (handler->op->type->flag & OPTYPE_UNDO && CTX_wm_manager(C) == wm)
wm->op_undo_depth--;
if (retval & OPERATOR_FINISHED)
if (G.debug & G_DEBUG_WM)
wm_operator_print(C, handler->op);
/* XXX check this carefully, CTX_wm_manager(C) == wm is a bit hackish */
if (CTX_wm_manager(C) == wm && wm->op_undo_depth == 0)
if (handler->op->type->flag & OPTYPE_UNDO)
ED_undo_push_op(C, handler->op);
if (handler->op->reports->list.first) {
/* FIXME, temp setting window, this is really bad!
2012-11-18 01:22:31 +00:00
* 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);
ScrArea *area_prev = CTX_wm_area(C);
ARegion *ar_prev = CTX_wm_region(C);
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);
/* XXX - copied from 'wm_operator_finished()' */
/* add reports to the global list, otherwise they are not seen */
BLI_movelisttolist(&CTX_wm_reports(C)->list, &handler->op->reports->list);
CTX_wm_window_set(C, win_prev);
CTX_wm_area_set(C, area_prev);
CTX_wm_region_set(C, ar_prev);
}
if (retval & OPERATOR_FINISHED) {
WM_operator_last_properties_store(handler->op);
}
WM_operator_free(handler->op);
}
else {
if (handler->op->type->cancel) {
if (handler->op->type->flag & OPTYPE_UNDO)
wm->op_undo_depth++;
handler->op->type->cancel(C, handler->op);
if (handler->op->type->flag & OPTYPE_UNDO)
wm->op_undo_depth--;
}
WM_operator_free(handler->op);
}
CTX_wm_area_set(C, NULL);
wm_event_free_handler(handler);
action = WM_HANDLER_BREAK;
}
break;
}
return action;
}
static int handler_boundbox_test(wmEventHandler *handler, wmEvent *event)
{
if (handler->bbwin) {
if (handler->bblocal) {
rcti rect = *handler->bblocal;
BLI_rcti_translate(&rect, handler->bbwin->xmin, handler->bbwin->ymin);
if (BLI_rcti_isect_pt_v(&rect, &event->x))
return 1;
else if (event->type == MOUSEMOVE && BLI_rcti_isect_pt_v(&rect, &event->prevx))
return 1;
else
return 0;
}
else {
if (BLI_rcti_isect_pt_v(handler->bbwin, &event->x))
return 1;
else if (event->type == MOUSEMOVE && BLI_rcti_isect_pt_v(handler->bbwin, &event->prevx))
return 1;
else
return 0;
}
}
return 1;
}
static int wm_action_not_handled(int action)
{
return action == WM_HANDLER_CONTINUE || action == (WM_HANDLER_BREAK | WM_HANDLER_MODAL);
}
static int wm_handlers_do_intern(bContext *C, wmEvent *event, ListBase *handlers)
{
#ifndef NDEBUG
const int do_debug_handler = (G.debug & G_DEBUG_HANDLERS) &&
/* comment this out to flood the console! (if you really want to test) */
!ELEM(event->type, MOUSEMOVE, INBETWEEN_MOUSEMOVE)
;
#endif
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;
int action = WM_HANDLER_CONTINUE;
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
if (handlers == NULL) {
return action;
}
/* modal handlers can get removed in this loop, we keep the loop this way
*
* note: check 'handlers->first' because in rare cases the handlers can be cleared
* by the event thats called, for eg:
*
* Calling a python script which changes the area.type, see [#32232] */
for (handler = handlers->first; handler && handlers->first; handler = nexthandler) {
nexthandler = handler->next;
/* during this loop, ui handlers for nested menus can tag multiple handlers free */
if (handler->flag & WM_HANDLER_DO_FREE) {
/* pass */
}
else if (handler_boundbox_test(handler, event)) { /* optional boundbox */
/* in advance to avoid access to freed event on window close */
always_pass = wm_event_always_pass(event);
/* modal+blocking handler */
if (handler->flag & WM_HANDLER_BLOCKING)
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
if (handler->keymap) {
wmKeyMap *keymap = WM_keymap_active(wm, handler->keymap);
wmKeyMapItem *kmi;
#ifndef NDEBUG
if (do_debug_handler) {
printf("%s: checking '%s' ...", __func__, keymap->idname);
}
#endif
if (!keymap->poll || keymap->poll(C)) {
#ifndef NDEBUG
if (do_debug_handler) {
printf("pass\n");
}
#endif
for (kmi = keymap->items.first; kmi; kmi = kmi->next) {
if (wm_eventmatch(event, kmi)) {
#ifndef NDEBUG
if (do_debug_handler) {
printf("%s: item matched '%s'\n", __func__, kmi->idname);
}
#endif
/* weak, but allows interactive callback to not use rawkey */
event->keymap_idname = kmi->idname;
action |= wm_handler_operator_call(C, handlers, handler, event, kmi->ptr);
if (action & WM_HANDLER_BREAK) {
/* not always_pass here, it denotes removed handler */
if (G.debug & (G_DEBUG_EVENTS | G_DEBUG_HANDLERS))
printf("%s: handled! '%s'\n", __func__, kmi->idname);
break;
}
else {
#ifndef NDEBUG
if (do_debug_handler) {
printf("%s: un-handled '%s'...", __func__, kmi->idname);
}
#endif
}
}
}
}
else {
#ifndef NDEBUG
if (do_debug_handler) {
printf("fail\n");
}
#endif
}
}
else if (handler->ui_handle) {
action |= wm_handler_ui_call(C, handler, event, always_pass);
}
else if (handler->type == WM_HANDLER_FILESELECT) {
/* screen context changes here */
action |= wm_handler_fileselect_call(C, handlers, handler, event);
}
else if (handler->dropboxes) {
if (event->type == EVT_DROP) {
wmDropBox *drop = handler->dropboxes->first;
for (; drop; drop = drop->next) {
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
/* other drop custom types allowed */
if (event->custom == EVT_DATA_LISTBASE) {
ListBase *lb = (ListBase *)event->customdata;
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
wmDrag *drag;
for (drag = lb->first; drag; drag = drag->next) {
if (drop->poll(C, drag, 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
drop->copy(drag, drop);
/* free the drags before calling operator */
BLI_freelistN(event->customdata);
event->customdata = NULL;
event->custom = 0;
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;
/* XXX fileread case */
if (CTX_wm_window(C) == NULL)
return action;
/* 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
}
}
}
}
}
}
else {
/* modal, swallows all */
action |= wm_handler_operator_call(C, handlers, handler, event, NULL);
}
if (action & WM_HANDLER_BREAK) {
if (always_pass)
action &= ~WM_HANDLER_BREAK;
else
break;
}
}
/* 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;
}
/* XXX code this for all modal ops, and ensure free only happens here */
/* modal ui handler can be tagged to be freed */
if (BLI_findindex(handlers, handler) != -1) { /* could be freed already by regular modal ops */
if (handler->flag & WM_HANDLER_DO_FREE) {
BLI_remlink(handlers, handler);
wm_event_free_handler(handler);
}
}
}
if (action == (WM_HANDLER_BREAK | WM_HANDLER_MODAL))
wm_cursor_arrow_move(CTX_wm_window(C), event);
return action;
}
/* this calls handlers twice - to solve (double-)click events */
static int wm_handlers_do(bContext *C, wmEvent *event, ListBase *handlers)
{
int action = wm_handlers_do_intern(C, event, handlers);
/* fileread case */
if (CTX_wm_window(C) == NULL)
return action;
2012-10-29 02:11:40 +00:00
if (!ELEM(event->type, MOUSEMOVE, INBETWEEN_MOUSEMOVE) && !ISTIMER(event->type)) {
/* test for CLICK events */
if (wm_action_not_handled(action)) {
wmWindow *win = CTX_wm_window(C);
/* eventstate stores if previous event was a KM_PRESS, in case that
2012-10-29 02:11:40 +00:00
* wasn't handled, the KM_RELEASE will become a KM_CLICK */
if (win && event->val == KM_PRESS) {
win->eventstate->check_click = TRUE;
}
if (win && win->eventstate->prevtype == event->type) {
if (event->val == KM_RELEASE && win->eventstate->prevval == KM_PRESS && win->eventstate->check_click == TRUE) {
event->val = KM_CLICK;
if (G.debug & (G_DEBUG_HANDLERS)) {
printf("%s: handling CLICK\n", __func__);
}
action |= wm_handlers_do_intern(C, event, handlers);
event->val = KM_RELEASE;
}
else if (event->val == KM_DBL_CLICK) {
event->val = KM_PRESS;
action |= wm_handlers_do_intern(C, event, handlers);
/* revert value if not handled */
if (wm_action_not_handled(action)) {
event->val = KM_DBL_CLICK;
}
}
}
}
else {
wmWindow *win = CTX_wm_window(C);
2012-10-30 12:18:45 +00:00
if (win)
win->eventstate->check_click = 0;
}
}
return action;
}
static int wm_event_inside_i(wmEvent *event, rcti *rect)
{
if (wm_event_always_pass(event))
return 1;
if (BLI_rcti_isect_pt_v(rect, &event->x))
return 1;
if (event->type == MOUSEMOVE) {
if (BLI_rcti_isect_pt_v(rect, &event->prevx)) {
return 1;
}
return 0;
}
return 0;
}
static ScrArea *area_event_inside(bContext *C, const int xy[2])
{
bScreen *screen = CTX_wm_screen(C);
ScrArea *sa;
if (screen)
for (sa = screen->areabase.first; sa; sa = sa->next)
if (BLI_rcti_isect_pt_v(&sa->totrct, xy))
return sa;
return NULL;
}
static ARegion *region_event_inside(bContext *C, const int xy[2])
{
bScreen *screen = CTX_wm_screen(C);
ScrArea *area = CTX_wm_area(C);
ARegion *ar;
if (screen && area)
for (ar = area->regionbase.first; ar; ar = ar->next)
if (BLI_rcti_isect_pt_v(&ar->winrct, xy))
return ar;
return NULL;
}
static void wm_paintcursor_tag(bContext *C, wmPaintCursor *pc, ARegion *ar)
{
if (ar) {
for (; pc; pc = pc->next) {
if (pc->poll == NULL || pc->poll(C)) {
wmWindow *win = CTX_wm_window(C);
win->screen->do_draw_paintcursor = TRUE;
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
}
}
}
}
/* 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);
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_rcti_isect_pt_v(&ar->winrct, &event->prevx)) {
ScrArea *sa = CTX_wm_area(C);
CTX_wm_area_set(C, area_event_inside(C, &event->prevx));
CTX_wm_region_set(C, region_event_inside(C, &event->prevx));
wm_paintcursor_tag(C, wm->paintcursors.first, CTX_wm_region(C));
CTX_wm_area_set(C, sa);
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
static void wm_event_drag_test(wmWindowManager *wm, wmWindow *win, wmEvent *event)
{
if (wm->drags.first == NULL) return;
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->type == MOUSEMOVE)
win->screen->do_draw_drag = TRUE;
else if (event->type == ESCKEY) {
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
BLI_freelistN(&wm->drags);
win->screen->do_draw_drag = TRUE;
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 (event->type == LEFTMOUSE && event->val == KM_RELEASE) {
event->type = 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
/* create customdata, first free existing */
if (event->customdata) {
if (event->customdatafree)
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
MEM_freeN(event->customdata);
}
event->custom = EVT_DATA_LISTBASE;
event->customdata = &wm->drags;
event->customdatafree = 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
/* clear drop icon */
win->screen->do_draw_drag = TRUE;
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
/* 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 = TRUE;
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
}
/* called in main loop */
/* goes over entire hierarchy: events -> window -> screen -> area -> region */
void wm_event_do_handlers(bContext *C)
{
wmWindowManager *wm = CTX_wm_manager(C);
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
/* update key configuration before handling events */
WM_keyconfig_update(wm);
for (win = wm->windows.first; win; win = win->next) {
wmEvent *event;
if (win->screen == NULL)
wm_event_free_all(win);
else {
Scene *scene = win->screen->scene;
if (scene) {
int is_playing_sound = sound_scene_playing(win->screen->scene);
if (is_playing_sound != -1) {
int is_playing_screen;
CTX_wm_window_set(C, win);
CTX_wm_screen_set(C, win->screen);
CTX_data_scene_set(C, scene);
is_playing_screen = (ED_screen_animation_playing(wm) != NULL);
if (((is_playing_sound == 1) && (is_playing_screen == 0)) ||
((is_playing_sound == 0) && (is_playing_screen == 1)))
2012-08-01 10:44:55 +00:00
{
ED_screen_animation_play(C, -1, 1);
}
if (is_playing_sound == 0) {
const float time = sound_sync_scene(scene);
if (finite(time)) {
int ncfra = time * (float)FPS + 0.5f;
if (ncfra != scene->r.cfra) {
scene->r.cfra = ncfra;
ED_update_for_newframe(CTX_data_main(C), scene, 1);
WM_event_add_notifier(C, NC_WINDOW, NULL);
}
}
}
CTX_data_scene_set(C, NULL);
CTX_wm_screen_set(C, NULL);
CTX_wm_window_set(C, NULL);
}
}
}
while ( (event = win->queue.first) ) {
int action = WM_HANDLER_CONTINUE;
2012-11-01 17:02:01 +00:00
#ifdef DEBUG
if (G.debug & (G_DEBUG_HANDLERS | G_DEBUG_EVENTS) && !ELEM(event->type, MOUSEMOVE, INBETWEEN_MOUSEMOVE)) {
printf("\n%s: Handling event\n", __func__);
WM_event_print(event);
}
2012-11-01 17:02:01 +00:00
#endif
CTX_wm_window_set(C, win);
/* 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));
CTX_wm_region_set(C, region_event_inside(C, &event->x));
/* MVC demands to not draw in event handlers... but we need to leave it for ogl selecting etc */
wm_window_make_drawable(C, win);
wm_region_mouse_co(C, event);
/* first we do priority handlers, modal + some limited keymaps */
action |= wm_handlers_do(C, event, &win->modalhandlers);
/* fileread case */
if (CTX_wm_window(C) == NULL)
return;
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 */
wm_tweakevent_test(C, event, action);
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;
int doit = 0;
/* 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);
}
else if (event->type == NDOF_MOTION) {
win->addmousemove = TRUE;
}
for (sa = win->screen->areabase.first; sa; sa = sa->next) {
if (wm_event_inside_i(event, &sa->totrct)) {
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
if ((action & WM_HANDLER_BREAK) == 0) {
for (ar = sa->regionbase.first; ar; ar = ar->next) {
if (wm_event_inside_i(event, &ar->winrct)) {
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
/* 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 */
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);
}
action |= wm_handlers_do(C, event, &ar->handlers);
/* fileread case (python), [#29489] */
if (CTX_wm_window(C) == NULL)
return;
doit |= (BLI_rcti_isect_pt_v(&ar->winrct, &event->x));
if (action & WM_HANDLER_BREAK)
break;
}
}
}
CTX_wm_region_set(C, NULL);
if ((action & WM_HANDLER_BREAK) == 0) {
wm_region_mouse_co(C, event); /* only invalidates event->mval in this case */
action |= wm_handlers_do(C, event, &sa->handlers);
}
CTX_wm_area_set(C, NULL);
/* NOTE: do not escape on WM_HANDLER_BREAK, mousemove needs handled for previous area */
}
}
if ((action & WM_HANDLER_BREAK) == 0) {
/* also some non-modal handlers need active area/region */
CTX_wm_area_set(C, area_event_inside(C, &event->x));
CTX_wm_region_set(C, region_event_inside(C, &event->x));
wm_region_mouse_co(C, event);
action |= wm_handlers_do(C, event, &win->handlers);
/* fileread case */
if (CTX_wm_window(C) == NULL)
return;
}
/* XXX hrmf, this gives reliable previous mouse coord for area change, feels bad?
2012-03-09 18:28:30 +00:00
* doing it on ghost queue gives errors when mousemoves go over area borders */
if (doit && win->screen && win->screen->subwinactive != win->screen->mainwin) {
win->eventstate->prevx = event->x;
win->eventstate->prevy = event->y;
//printf("win->eventstate->prev = %d %d\n", event->x, event->y);
}
2011-10-26 21:30:08 +00:00
else {
//printf("not setting prev to %d %d\n", event->x, event->y);
}
}
/* unlink and free here, blender-quit then frees all */
BLI_remlink(&win->queue, event);
wm_event_free(event);
}
/* only add mousemove when queue was read entirely */
if (win->addmousemove && win->eventstate) {
wmEvent tevent = *(win->eventstate);
//printf("adding MOUSEMOVE %d %d\n", tevent.x, tevent.y);
tevent.type = MOUSEMOVE;
tevent.prevx = tevent.x;
tevent.prevy = tevent.y;
wm_event_add(win, &tevent);
win->addmousemove = 0;
}
CTX_wm_window_set(C, NULL);
}
/* update key configuration after handling events */
WM_keyconfig_update(wm);
if (G.debug) {
GLenum error = glGetError();
if (error != GL_NO_ERROR) {
printf("GL error: %s\n", gluErrorString(error));
}
}
}
/* ********** 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);
}
}
/* operator is supposed to have a filled "path" property */
/* optional property: filetype (XXX enum?) */
/* Idea is to keep a handler alive on window queue, owning the operator.
2012-03-09 18:28:30 +00:00
* 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)
{
wmEventHandler *handler, *handlernext;
wmWindow *win = CTX_wm_window(C);
int full = 1; // XXX preset?
/* 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);
}
}
handler = MEM_callocN(sizeof(wmEventHandler), "fileselect handler");
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);
BLI_addhead(&win->modalhandlers, handler);
/* 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 */
}
WM_event_fileselect_event(C, op, full ? EVT_FILESELECT_FULL_OPEN : EVT_FILESELECT_OPEN);
}
#if 0
/* lets not expose struct outside wm? */
static void WM_event_set_handler_flag(wmEventHandler *handler, int flag)
{
handler->flag = flag;
}
#endif
wmEventHandler *WM_event_add_modal_handler(bContext *C, wmOperator *op)
{
wmEventHandler *handler = MEM_callocN(sizeof(wmEventHandler), "event modal handler");
wmWindow *win = CTX_wm_window(C);
/* 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;
handler->op_area = CTX_wm_area(C); /* means frozen screen context for modal handlers! */
handler->op_region = CTX_wm_region(C);
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
return handler;
}
wmEventHandler *WM_event_add_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;
if (!keymap) {
2012-06-17 11:36:28 +00:00
printf("%s: called with NULL keymap\n", __func__);
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)
return handler;
handler = MEM_callocN(sizeof(wmEventHandler), "event keymap handler");
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
return handler;
}
/* priorities not implemented yet, for time being just insert in begin of list */
wmEventHandler *WM_event_add_keymap_handler_priority(ListBase *handlers, wmKeyMap *keymap, int UNUSED(priority))
{
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;
}
wmEventHandler *WM_event_add_keymap_handler_bb(ListBase *handlers, wmKeyMap *keymap, rcti *bblocal, rcti *bbwin)
{
wmEventHandler *handler = WM_event_add_keymap_handler(handlers, keymap);
if (handler) {
handler->bblocal = bblocal;
handler->bbwin = bbwin;
}
return handler;
}
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) {
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
BLI_remlink(handlers, handler);
wm_event_free_handler(handler);
break;
}
}
}
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
{
wmEventHandler *handler = MEM_callocN(sizeof(wmEventHandler), "event ui handler");
handler->ui_handle = func;
handler->ui_remove = remove;
handler->ui_userdata = userdata;
handler->ui_area = (C) ? CTX_wm_area(C) : NULL;
handler->ui_region = (C) ? CTX_wm_region(C) : NULL;
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
/* 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) {
if (handler->ui_handle == func && handler->ui_remove == remove && handler->ui_userdata == userdata) {
/* 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)
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 handler;
handler = MEM_callocN(sizeof(wmEventHandler), "dropbox handler");
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
/* dropbox stored static, no free or copy */
handler->dropboxes = dropboxes;
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
BLI_addhead(handlers, handler);
return handler;
}
/* XXX solution works, still better check the real cause (ton) */
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;
if (handler->type != WM_HANDLER_FILESELECT) {
if (handler->ui_area == area) {
BLI_remlink(handlers, handler);
wm_event_free_handler(handler);
}
}
}
}
#if 0
static void WM_event_remove_handler(ListBase *handlers, wmEventHandler *handler)
{
BLI_remlink(handlers, handler);
wm_event_free_handler(handler);
}
#endif
void WM_event_add_mousemove(bContext *C)
{
wmWindow *window = CTX_wm_window(C);
window->addmousemove = 1;
}
void WM_event_add_mousemove_window(wmWindow *window)
{
window->addmousemove = 1;
}
/* for modal callbacks, check configuration for how to interpret exit with tweaks */
int WM_modal_tweak_exit(wmEvent *evt, int tweak_event)
{
/* if the release-confirm userpref setting is enabled,
2012-03-08 04:12:11 +00:00
* tweak events can be canceled 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;
}
}
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;
}
}
}
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;
}
return 0;
}
/* ********************* 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));
}
else if (key >= GHOST_kKeyF1 && key <= GHOST_kKeyF19) {
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;
case GHOST_kKeyOS: return OSKEY;
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;
case GHOST_kKeyMediaPlay: return MEDIAPLAY;
case GHOST_kKeyMediaStop: return MEDIASTOP;
case GHOST_kKeyMediaFirst: return MEDIAFIRST;
case GHOST_kKeyMediaLast: return MEDIALAST;
default:
return UNKNOWNKEY; /* GHOST_kKeyUnknown */
}
}
}
static void wm_eventemulation(wmEvent *event)
{
/* Store last mmb event value to make emulation work when modifier keys are released first. */
static int mmb_emulated = 0; /* this should be in a data structure somwhere */
/* middlemouse emulation */
if (U.flag & USER_TWOBUTTONMOUSE) {
if (event->type == LEFTMOUSE) {
if (event->val == KM_PRESS && event->alt) {
event->type = MIDDLEMOUSE;
event->alt = 0;
mmb_emulated = 1;
}
else if (event->val == KM_RELEASE) {
/* only send middle-mouse release if emulated */
if (mmb_emulated) {
event->type = MIDDLEMOUSE;
event->alt = 0;
}
mmb_emulated = 0;
}
}
}
#ifdef __APPLE__
/* rightmouse emulation */
if (U.flag & USER_TWOBUTTONMOUSE) {
if (event->type == LEFTMOUSE) {
if (event->val == KM_PRESS && event->oskey) {
event->type = RIGHTMOUSE;
event->oskey = 0;
mmb_emulated = 1;
}
else if (event->val == KM_RELEASE) {
if (mmb_emulated) {
event->oskey = RIGHTMOUSE;
event->alt = 0;
}
mmb_emulated = 0;
}
}
}
#endif
/* 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;
}
}
}
/* 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 */
if ((td != NULL) && td->Active != GHOST_kTabletModeNone) {
struct wmTabletData *wmtab = MEM_mallocN(sizeof(wmTabletData), "customdata tablet");
wmtab->Active = (int)td->Active;
wmtab->Pressure = td->Pressure;
wmtab->Xtilt = td->Xtilt;
wmtab->Ytilt = td->Ytilt;
event->custom = EVT_DATA_TABLET;
event->customdata = wmtab;
event->customdatafree = 1;
}
}
/* 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;
const float rs = U.ndof_orbit_sensitivity;
data->tx = s * ghost->tx;
data->rx = rs * ghost->rx;
data->ry = rs * ghost->ry;
data->rz = rs * ghost->rz;
if (U.ndof_flag & NDOF_ZOOM_UPDOWN) {
/* 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;
#endif
}
else {
data->ty = s * ghost->ty;
data->tz = s * ghost->tz;
}
data->dt = ghost->dt;
data->progress = (wmProgress) ghost->progress;
event->custom = EVT_DATA_NDOF_MOTION;
event->customdata = data;
event->customdatafree = 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
/* imperfect but probably usable... draw/enable drags to other windows */
static wmWindow *wm_event_cursor_other_windows(wmWindowManager *wm, wmWindow *win, wmEvent *evt)
{
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)
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 NULL;
/* in order to use window size and mouse position (pixels), we have to use a WM function */
/* check if outside, include top window bar... */
if (mx < 0 || my < 0 || mx > WM_window_pixels_x(win) || my > WM_window_pixels_y(win) + 30) {
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;
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)
if (handler->ui_handle || handler->op)
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 */
mx += (int) (U.pixelsize * win->posx);
my += (int) (U.pixelsize * 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) {
if (owin != win) {
int posx = (int) (U.pixelsize * owin->posx);
int posy = (int) (U.pixelsize * owin->posy);
if (mx - posx >= 0 && owin->posy >= 0 &&
mx - posx <= WM_window_pixels_x(owin) && my - posy <= WM_window_pixels_y(owin))
{
evt->x = mx - (int)(U.pixelsize * owin->posx);
evt->y = my - (int)(U.pixelsize * 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;
}
/* 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 */
void wm_event_add_ghostevent(wmWindowManager *wm, wmWindow *win, int type, int UNUSED(time), void *customdata)
{
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;
wmEvent event, *evt = win->eventstate;
2011-06-11 00:25:48 +00:00
/* initialize and copy state (only mouse x y and modifiers) */
event = *evt;
switch (type) {
/* mouse move, also to inactive window (X11 does this) */
2012-09-08 08:59:47 +00:00
case GHOST_kEventCursorMove:
{
GHOST_TEventCursorData *cd = customdata;
wmEvent *lastevent = win->queue.last;
Holiday coding log :) Nice formatted version (pictures soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability Short list of main changes: - Transparent region option (over main region), added code to blend in/out such panels. - Min size window now 640 x 480 - Fixed DPI for ui - lots of cleanup and changes everywhere. Icon image need correct size still, layer-in-use icon needs remake. - Macbook retina support, use command line --no-native-pixels to disable it - Timeline Marker label was drawing wrong - Trackpad and magic mouse: supports zoom (hold ctrl) - Fix for splash position: removed ghost function and made window size update after creation immediate - Fast undo buffer save now adds UI as well. Could be checked for regular file save even... Quit.blend and temp file saving use this now. - Dixed filename in window on reading quit.blend or temp saves, and they now add a warning in window title: "(Recovered)" - New Userpref option "Keep Session" - this always saves quit.blend, and loads on start. This allows keeping UI and data without actual saves, until you actually save. When you load startup.blend and quit, it recognises the quit.blend as a startup (no file name in header) - Added 3D view copy/paste buffers (selected objects). Shortcuts ctrl-c, ctrl-v (OSX, cmd-c, cmd-v). Coded partial file saving for it. Could be used for other purposes. Todo: use OS clipboards. - User preferences (themes, keymaps, user settings) now can be saved as a separate file. Old option is called "Save Startup File" the new one "Save User Settings". To visualise this difference, the 'save startup file' button has been removed from user preferences window. That option is available as CTRL+U and in File menu still. - OSX: fixed bug that stopped giving mouse events outside window. This also fixes "Continuous Grab" for OSX. (error since 2009)
2012-12-12 18:58:11 +00:00
evt->x = cd->x;
evt->y = cd->y;
event.x = evt->x;
event.y = 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
event.type = MOUSEMOVE;
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
/* some painting operators want accurate mouse events, they can
* handle in between mouse move moves, others can happily ignore
* them for better performance */
if (lastevent && lastevent->type == MOUSEMOVE)
lastevent->type = INBETWEEN_MOUSEMOVE;
update_tablet_data(win, &event);
wm_event_add(win, &event);
/* 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);
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.x = owin->eventstate->x = event.x;
oevent.y = owin->eventstate->y = event.y;
oevent.type = MOUSEMOVE;
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
update_tablet_data(owin, &oevent);
wm_event_add(owin, &oevent);
}
break;
}
2012-09-08 08:59:47 +00:00
case GHOST_kEventTrackpad:
{
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;
}
Holiday coding log :) Nice formatted version (pictures soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability Short list of main changes: - Transparent region option (over main region), added code to blend in/out such panels. - Min size window now 640 x 480 - Fixed DPI for ui - lots of cleanup and changes everywhere. Icon image need correct size still, layer-in-use icon needs remake. - Macbook retina support, use command line --no-native-pixels to disable it - Timeline Marker label was drawing wrong - Trackpad and magic mouse: supports zoom (hold ctrl) - Fix for splash position: removed ghost function and made window size update after creation immediate - Fast undo buffer save now adds UI as well. Could be checked for regular file save even... Quit.blend and temp file saving use this now. - Dixed filename in window on reading quit.blend or temp saves, and they now add a warning in window title: "(Recovered)" - New Userpref option "Keep Session" - this always saves quit.blend, and loads on start. This allows keeping UI and data without actual saves, until you actually save. When you load startup.blend and quit, it recognises the quit.blend as a startup (no file name in header) - Added 3D view copy/paste buffers (selected objects). Shortcuts ctrl-c, ctrl-v (OSX, cmd-c, cmd-v). Coded partial file saving for it. Could be used for other purposes. Todo: use OS clipboards. - User preferences (themes, keymaps, user settings) now can be saved as a separate file. Old option is called "Save Startup File" the new one "Save User Settings". To visualise this difference, the 'save startup file' button has been removed from user preferences window. That option is available as CTRL+U and in File menu still. - OSX: fixed bug that stopped giving mouse events outside window. This also fixes "Continuous Grab" for OSX. (error since 2009)
2012-12-12 18:58:11 +00:00
event.x = evt->x = pd->x;
event.y = evt->y = pd->y;
event.val = 0;
2012-06-17 11:36:28 +00:00
/* Use prevx/prevy so we can calculate the delta later */
event.prevx = event.x - pd->deltaX;
event.prevy = event.y - (-pd->deltaY);
update_tablet_data(win, &event);
wm_event_add(win, &event);
break;
}
/* mouse button */
case GHOST_kEventButtonDown:
2012-09-08 08:59:47 +00:00
case GHOST_kEventButtonUp:
{
GHOST_TEventButtonData *bd = customdata;
/* get value and type from ghost */
event.val = (type == GHOST_kEventButtonDown) ? KM_PRESS : KM_RELEASE;
if (bd->button == GHOST_kButtonMaskLeft)
event.type = LEFTMOUSE;
else if (bd->button == GHOST_kButtonMaskRight)
event.type = RIGHTMOUSE;
else if (bd->button == GHOST_kButtonMaskButton4)
event.type = BUTTON4MOUSE;
else if (bd->button == GHOST_kButtonMaskButton5)
event.type = BUTTON5MOUSE;
else
event.type = MIDDLEMOUSE;
wm_eventemulation(&event);
2012-10-29 15:40:43 +00:00
/* copy previous state to prev event state (two old!) */
evt->prevval = evt->val;
evt->prevtype = evt->type;
/* copy to event state */
2012-10-27 01:46:47 +00:00
evt->val = event.val;
evt->type = event.type;
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;
}
/* double click test */
if (event.type == evt->prevtype && event.val == KM_PRESS) {
if ((ABS(event.x - evt->prevclickx)) <= 2 &&
2012-10-27 01:46:47 +00:00
(ABS(event.y - evt->prevclicky)) <= 2 &&
((PIL_check_seconds_timer() - evt->prevclicktime) * 1000 < U.dbl_click_time))
{
if (G.debug & (G_DEBUG_HANDLERS | G_DEBUG_EVENTS) )
printf("%s Send double click\n", __func__);
event.val = KM_DBL_CLICK;
}
}
if (event.val == KM_PRESS) {
evt->prevclicktime = PIL_check_seconds_timer();
evt->prevclickx = event.x;
evt->prevclicky = 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
/* 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);
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.x = event.x;
oevent.y = event.y;
oevent.type = event.type;
oevent.val = event.val;
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
update_tablet_data(owin, &oevent);
wm_event_add(owin, &oevent);
}
else {
update_tablet_data(win, &event);
wm_event_add(win, &event);
}
break;
}
/* keyboard */
case GHOST_kEventKeyDown:
2012-09-08 08:59:47 +00:00
case GHOST_kEventKeyUp:
{
GHOST_TEventKeyData *kd = customdata;
event.type = convert_key(kd->key);
event.ascii = kd->ascii;
memcpy(event.utf8_buf, kd->utf8_buf, sizeof(event.utf8_buf)); /* might be not null terminated*/
event.val = (type == GHOST_kEventKeyDown) ? KM_PRESS : KM_RELEASE;
wm_eventemulation(&event);
2012-10-29 15:40:43 +00:00
/* copy previous state to prev event state (two old!) */
evt->prevval = evt->val;
evt->prevtype = evt->type;
/* copy to event state */
2012-10-27 01:46:47 +00:00
evt->val = event.val;
evt->type = event.type;
/* exclude arrow keys, esc, etc from text input */
if (type == GHOST_kEventKeyUp) {
event.ascii = '\0';
/* ghost should do this already for key up */
if (event.utf8_buf[0]) {
2011-10-23 15:27:36 +00:00
printf("%s: ghost on your platform is misbehaving, utf8 events on key up!\n", __func__);
}
event.utf8_buf[0] = '\0';
}
else {
if (event.ascii < 32 && event.ascii > 0)
event.ascii = '\0';
if (event.utf8_buf[0] < 32 && event.utf8_buf[0] > 0)
event.utf8_buf[0] = '\0';
2011-10-23 01:06:38 +00:00
}
if (event.utf8_buf[0]) {
if (BLI_str_utf8_size(event.utf8_buf) == -1) {
printf("%s: ghost detected an invalid unicode character '%d'!\n",
__func__, (int)(unsigned char)event.utf8_buf[0]);
event.utf8_buf[0] = '\0';
}
}
/* modifiers assign to eventstate, so next event gets the modifer (makes modifier key events work) */
/* assigning both first and second is strange - campbell */
switch (event.type) {
case LEFTSHIFTKEY: case RIGHTSHIFTKEY:
evt->shift = (event.val == KM_PRESS) ?
2012-10-28 15:23:16 +00:00
((evt->ctrl || evt->alt || evt->oskey) ? (KM_MOD_FIRST | KM_MOD_SECOND) : KM_MOD_FIRST) :
FALSE;
break;
case LEFTCTRLKEY: case RIGHTCTRLKEY:
evt->ctrl = (event.val == KM_PRESS) ?
2012-10-28 15:23:16 +00:00
((evt->shift || evt->alt || evt->oskey) ? (KM_MOD_FIRST | KM_MOD_SECOND) : KM_MOD_FIRST) :
FALSE;
break;
case LEFTALTKEY: case RIGHTALTKEY:
evt->alt = (event.val == KM_PRESS) ?
2012-10-28 15:23:16 +00:00
((evt->ctrl || evt->shift || evt->oskey) ? (KM_MOD_FIRST | KM_MOD_SECOND) : KM_MOD_FIRST) :
FALSE;
break;
case OSKEY:
evt->oskey = (event.val == KM_PRESS) ?
2012-10-28 15:23:16 +00:00
((evt->ctrl || evt->alt || evt->shift) ? (KM_MOD_FIRST | KM_MOD_SECOND) : KM_MOD_FIRST) :
FALSE;
break;
default:
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;
break;
}
/* double click test */
/* if previous event was same type, and previous was release, and now it presses... */
if (event.type == evt->prevtype && evt->prevval == KM_RELEASE && event.val == KM_PRESS) {
if ((ABS(event.x - evt->prevclickx)) <= 2 &&
2012-10-27 01:46:47 +00:00
(ABS(event.y - evt->prevclicky)) <= 2 &&
((PIL_check_seconds_timer() - evt->prevclicktime) * 1000 < U.dbl_click_time))
{
if (G.debug & (G_DEBUG_HANDLERS | G_DEBUG_EVENTS) )
printf("%s Send double click\n", __func__);
2012-10-27 01:46:47 +00:00
evt->val = event.val = KM_DBL_CLICK;
}
}
/* this case happens on holding a key pressed, it should not generate
* press events events with the same key as modifier */
if (event.keymodifier == event.type)
event.keymodifier = 0;
/* this case happened with an external numpad, it's not really clear
2012-03-09 18:28:30 +00:00
* why, but it's also impossible to map a key modifier to an unknwon
* key, so it shouldn't harm */
if (event.keymodifier == UNKNOWNKEY)
event.keymodifier = 0;
/* if test_break set, it catches this. Do not set with modifier presses. XXX Keep global for now? */
if ((event.type == ESCKEY && event.val == KM_PRESS) &&
/* check other modifiers because ms-windows uses these to bring up the task manager */
(event.shift == 0 && event.ctrl == 0 && event.alt == 0))
{
G.is_break = TRUE;
}
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
/* double click test - only for press */
if (event.val == KM_PRESS) {
evt->prevclicktime = PIL_check_seconds_timer();
evt->prevclickx = event.x;
evt->prevclicky = event.y;
}
wm_event_add(win, &event);
break;
}
2012-09-08 08:59:47 +00:00
case GHOST_kEventWheel:
{
GHOST_TEventWheelData *wheelData = customdata;
if (wheelData->z > 0)
event.type = WHEELUPMOUSE;
else
event.type = WHEELDOWNMOUSE;
event.val = KM_PRESS;
wm_event_add(win, &event);
break;
}
2012-09-08 08:59:47 +00:00
case GHOST_kEventTimer:
{
event.type = TIMER;
event.custom = EVT_DATA_TIMER;
event.customdata = customdata;
event.val = 0;
event.keymodifier = 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
wm_event_add(win, &event);
break;
}
2012-09-08 08:59:47 +00:00
case GHOST_kEventNDOFMotion:
{
event.type = NDOF_MOTION;
2012-10-29 15:40:43 +00:00
event.val = 0;
attach_ndof_data(&event, customdata);
wm_event_add(win, &event);
if (G.debug & (G_DEBUG_HANDLERS | G_DEBUG_EVENTS) )
printf("%s sending NDOF_MOTION, prev = %d %d\n", __func__, event.x, event.y);
break;
}
2012-09-08 08:59:47 +00:00
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;
}
case GHOST_kEventUnknown:
case GHOST_kNumEventTypes:
break;
2012-09-08 08:59:47 +00:00
case GHOST_kEventWindowDeactivate:
{
event.type = WINDEACTIVATE;
wm_event_add(win, &event);
break;
}
}
2011-10-22 01:53:35 +00:00
}