archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
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
15d77f17a40398a63f95e16607deb81257c02698
blender-archive/source/blender/windowmanager/intern/wm_keymap.c

326 lines
8.1 KiB
C
Raw Normal View History

Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
/**
* $Id:
*
* ***** 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,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* The Original Code is Copyright (C) 2007 Blender Foundation.
* All rights reserved.
*
*
* Contributor(s): Blender Foundation
*
* ***** END GPL LICENSE BLOCK *****
*/
#include <string.h>
WM: changed WM_operator_call to take an argument, which specifies in which context to run the operator: WM_OP_DEFAULT, WM_OP_REGION_WIN, WM_OP_AREA or WM_OP_SCREEN. This also replaces WM_operator_call_rwin since it is more general. This is useful for buttons and popup menus to run operators, and also used by a new function to lookup the keymap item for that operator in the right context.
2008-12-16 07:44:21 +00:00
#include "DNA_screen_types.h"
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
#include "DNA_windowmanager_types.h"
#include "MEM_guardedalloc.h"
#include "BLI_blenlib.h"
#include "BKE_blender.h"
2.5 Context API This adds the context API as described here. The main practical change now is that C is not longer directly accessible but has to be accessed through accessor functions. This basically adds the implementation of the API and adaption of existing code with some minor changes. The next task of course is to actually use this design to cleanup of bad level calls and global access, in blenkernel, blenloader. http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Context Error, Warning and Debug Info Reporting This adds the error reporting API as described here. It should help clean up error() calls in non-ui code, but eventually can become used for gathering messages for a console window, and throwing exceptions in python scripts when an error happens executing something. http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Reports
2008-12-18 02:56:48 +00:00
#include "BKE_context.h"
2.5: * Automatic shortcut keys in menus now compare operator properties as well. Implemented IDP_EqualsProperties for this. * I imagine all these compares may be a bit slow, for this case it's not so bad though because it only happens for one menu when it is opened.
2009-01-28 23:29:27 +00:00
#include "BKE_idprop.h"
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
#include "BKE_library.h"
#include "BKE_main.h"
2.5 Operator calls: extended WM_operator_name_call() with options whether to call the exec() (operate immediate) or invoke() (check user input) entry. This will allow python to use it more efficiently, but also solves the dreaded pulldown case that showed another menu for confirmation. New names to learn: :) WM_OP_EXEC_DEFAULT WM_OP_INVOKE_DEFAULT on todo still: allow hotkey definitions to do same.
2008-12-26 12:21:06 +00:00
#include "BKE_utildefines.h"
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
#include "RNA_access.h"
#include "RNA_types.h"
RNA read-only wrapped wmEvent so python operators invoke functions * 2 new enums event_value_items and event_type_items in RNA_enum_types.h * WM_key_event_string now uses an RNA enum lookup rather then its own switch statement. * moved wmEvent from WM_types.h into DNA_windowmanager_types.h * added RNA_enum_identifier and RNA_enum_name to get strings from an enum value.
2009-06-21 14:30:59 +00:00
#include "RNA_enum_types.h"
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
#include "WM_api.h"
#include "WM_types.h"
#include "wm_window.h"
#include "wm_event_system.h"
#include "wm_event_types.h"
/* ***************** generic call, exported **************** */
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
static void keymap_event_set(wmKeymapItem *kmi, short type, short val, int modifier, short keymodifier)
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
{
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
kmi->type= type;
kmi->val= val;
kmi->keymodifier= keymodifier;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5 Better implementation of own window timers, not using ghost. That makes blender's WM nice in control, and gives callers of timers the opportunitie to evaluate time passed since previous step. This system also only generates one timer event per main loop (events - handlers - notifiers - draw) Small fix: allow keymap modifier to give KM_ANY to ignore modifier keys, this to have TIMER keymap work.
2008-12-22 12:57:53 +00:00
if(modifier == KM_ANY) {
kmi->shift= kmi->ctrl= kmi->alt= kmi->oskey= KM_ANY;
}
else {
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
kmi->shift= kmi->ctrl= kmi->alt= kmi->oskey= 0;
2.5 Big commit, but mainly adminstration. - Enabled ot->flag OPTYPE_UNDO to work. - Removed all redundant ED_undo_pushes, but I'd recommend everyone to check it while testing. :) - Added view manipulations as OPTYPE_REGISTER, although this will flood the redo stack a bit... Nevertheless; for a "redo last action" panel we can simply check if both flags are set for redo. - Bugfix in editmode undo: selectmode was cleared, so you couldn't select after undo - Bugfix in mixing tweaks and keymaps... solution works but is weak, need to think over a while.
2009-01-31 19:40:40 +00:00
/* defines? */
2.5 Better implementation of own window timers, not using ghost. That makes blender's WM nice in control, and gives callers of timers the opportunitie to evaluate time passed since previous step. This system also only generates one timer event per main loop (events - handlers - notifiers - draw) Small fix: allow keymap modifier to give KM_ANY to ignore modifier keys, this to have TIMER keymap work.
2008-12-22 12:57:53 +00:00
if(modifier & KM_SHIFT)
kmi->shift= 1;
else if(modifier & KM_SHIFT2)
kmi->shift= 2;
if(modifier & KM_CTRL)
kmi->ctrl= 1;
else if(modifier & KM_CTRL2)
kmi->ctrl= 2;
if(modifier & KM_ALT)
kmi->alt= 1;
else if(modifier & KM_ALT2)
kmi->alt= 2;
if(modifier & KM_OSKEY)
kmi->oskey= 1;
else if(modifier & KM_OSKEY2)
kmi->oskey= 2;
}
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
}
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
static void keymap_properties_set(wmKeymapItem *kmi)
{
if(!kmi->ptr) {
RNA * Object has some more properties wrapped, mostly game related. * Scene frame changes now send a notifier. * Added functions to create/free operator properties for calling operators. This also simplifies some duplicated code that did this. Ideally though this kind of thing should use the properties pointer provided by buttons and keymap items. Example code: PointerRNA ptr; WM_operator_properties_create(&ptr, "SOME_OT_name"); RNA_int_set(&ptr, "value", 42); WM_operator_name_call(C, "SOME_OT_name", WM_OP_EXEC_DEFAULT, &ptr); WM_operator_properties_free(&ptr);
2009-01-01 20:44:40 +00:00
kmi->ptr= MEM_callocN(sizeof(PointerRNA), "wmKeymapItemPtr");
WM_operator_properties_create(kmi->ptr, kmi->idname);
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
}
}
Work on gesture, some more cleaning. - Added standard "tweak" gesture operator, which can be set per region, to generate EVT_TWEAK events. You can configure tweaks for any mouse button and have handlers for such events check for modifiers etc. It even stores tweak direction (8 directions). Might be fun to experiment with tweak gestures N, S, etc. :) In general it can be used to replace the current tweak code in 2.48 (std_rmouse_transform). Test added: on screen level it now adds LMB tweaks, if tweak-South it splits the area. Will be removed of course. - Added to Border operator a property to store event used to end border with. - Moved the "AZone" triangle drawing to the right context (area). It was on screen level, not respecting area-redraws. Also cleaned up drawing for it, and moved the "swap buffers indicator" square to look nicer. Those squares are only for test! - event-match function had bad code for checking for event-value. Made a "KM_ANY" define so keymaps can be defined ignoring event values. - Gesture todo: lasso, "real gesture" (like blender now has)
2008-11-24 10:45:36 +00:00
/* if item was added, then bail out */
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
wmKeymapItem *WM_keymap_verify_item(ListBase *lb, char *idname, short type, short val, int modifier, short keymodifier)
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
{
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
wmKeymapItem *kmi;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
for(kmi= lb->first; kmi; kmi= kmi->next)
if(strncmp(kmi->idname, idname, OP_MAX_TYPENAME)==0)
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
break;
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
if(kmi==NULL) {
kmi= MEM_callocN(sizeof(wmKeymapItem), "keymap entry");
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
BLI_addtail(lb, kmi);
BLI_strncpy(kmi->idname, idname, OP_MAX_TYPENAME);
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
keymap_event_set(kmi, type, val, modifier, keymodifier);
keymap_properties_set(kmi);
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
}
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
return kmi;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
}
Blender 2.5 project: added first more complex handler + operator - on mouse-over edge, you can drag area borders around. - note it's a handerized system now, so it updates UI while you move mouse. Feedback needed: - read bottom part of the screen_edit.c file. It's the proposed method for adding tools and handlers. I think it's close, but might need some tweaks.
2008-01-10 17:38:17 +00:00
/* always add item */
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
wmKeymapItem *WM_keymap_add_item(ListBase *lb, char *idname, short type, short val, int modifier, short keymodifier)
Blender 2.5 project: added first more complex handler + operator - on mouse-over edge, you can drag area borders around. - note it's a handerized system now, so it updates UI while you move mouse. Feedback needed: - read bottom part of the screen_edit.c file. It's the proposed method for adding tools and handlers. I think it's close, but might need some tweaks.
2008-01-10 17:38:17 +00:00
{
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
wmKeymapItem *kmi= MEM_callocN(sizeof(wmKeymapItem), "keymap entry");
Blender 2.5 project: added first more complex handler + operator - on mouse-over edge, you can drag area borders around. - note it's a handerized system now, so it updates UI while you move mouse. Feedback needed: - read bottom part of the screen_edit.c file. It's the proposed method for adding tools and handlers. I think it's close, but might need some tweaks.
2008-01-10 17:38:17 +00:00
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
BLI_addtail(lb, kmi);
BLI_strncpy(kmi->idname, idname, OP_MAX_TYPENAME);
Blender 2.5 project: added first more complex handler + operator - on mouse-over edge, you can drag area borders around. - note it's a handerized system now, so it updates UI while you move mouse. Feedback needed: - read bottom part of the screen_edit.c file. It's the proposed method for adding tools and handlers. I think it's close, but might need some tweaks.
2008-01-10 17:38:17 +00:00
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
keymap_event_set(kmi, type, val, modifier, keymodifier);
keymap_properties_set(kmi);
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
return kmi;
}
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
/* ****************** storage in WM ************ */
/* name id's are for storing general or multiple keymaps,
space/region ids are same as DNA_space_types.h */
/* gets free'd in wm.c */
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
static wmKeyMap *wm_keymap_add(wmWindowManager *wm, const char *nameid, short spaceid, short regionid)
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
{
wmKeyMap *km;
for(km= wm->keymaps.first; km; km= km->next)
if(km->spaceid==spaceid && km->regionid==regionid)
if(0==strncmp(nameid, km->nameid, KMAP_MAX_NAME))
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
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
if(km==NULL) {
km= MEM_callocN(sizeof(struct wmKeyMap), "keymap list");
BLI_strncpy(km->nameid, nameid, KMAP_MAX_NAME);
km->spaceid= spaceid;
km->regionid= regionid;
BLI_addtail(&wm->keymaps, km);
}
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
return km;
}
ListBase *WM_keymap_listbase(wmWindowManager *wm, const char *nameid, short spaceid, short regionid)
{
wmKeyMap *km= wm_keymap_add(wm, nameid, spaceid, regionid);
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
return &km->keymap;
}
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5 Modal keymaps. I've tried to make it as simple as possible, yet still using sufficient facilities to enable self-documenting UIs, saving/reading in files, and proper Python support. The simplicity is: the 'modal keymap' just checks an event, uses event matching similarly to other keymap matching, and if there's a match it changes the event type, and sets the event value to what the modal keymap has defined. The event values are being defined using EnumPropertyItem structs, so the UI will be able to show all options in self-documenting way. This system also allows to still handle hardcoded own events. Tech doc: 1) define keymap - Create map with unique name, WM_modalkeymap_add() - Give map property definitions (EnumPropertyItem *) This only for UI, so user can get information on available options 2) items - WM_modalkeymap_add_item(): give it an enum value for events 3) activate - In keymap definition code, assign the modal keymap to operatortype WM_modalkeymap_assign() 4) event manager - The event handler will check for modal keymap, if so: - If the modal map has a match: - Sets event->type to EVT_MODAL_MAP - Sets event->val to the enum value 5) modal handler - If event type is EVT_MODAL_MAP: - Check event->val, handle it - Other events can just be handled still Two examples added in the code: editors/transform/transform.c: transform_modal_keymap() editors/screen/screen_ops.c: keymap_modal_set() Also: to support 'key release' the define KM_RELEASE now is officially used in event manager, this is not '0', so don't check key events with the old convention if(event->val) but use if(event->val==KM_PRESS)
2009-07-21 11:03:07 +00:00
/* ****************** modal keymaps ************ */
/* modal maps get linked to a running operator, and filter the keys before sending to modal() callback */
wmKeyMap *WM_modalkeymap_add(wmWindowManager *wm, const char *nameid, EnumPropertyItem *items)
{
wmKeyMap *km= wm_keymap_add(wm, nameid, 0, 0);
km->is_modal= 1;
km->items= items;
return km;
}
wmKeyMap *WM_modalkeymap_get(wmWindowManager *wm, const char *nameid)
{
wmKeyMap *km;
for(km= wm->keymaps.first; km; km= km->next)
if(km->is_modal)
if(0==strncmp(nameid, km->nameid, KMAP_MAX_NAME))
break;
return km;
}
void WM_modalkeymap_add_item(wmKeyMap *km, short type, short val, int modifier, short keymodifier, short value)
{
wmKeymapItem *kmi= MEM_callocN(sizeof(wmKeymapItem), "keymap entry");
BLI_addtail(&km->keymap, kmi);
kmi->propvalue= value;
keymap_event_set(kmi, type, val, modifier, keymodifier);
}
void WM_modalkeymap_assign(wmKeyMap *km, const char *opname)
{
wmOperatorType *ot= WM_operatortype_find(opname, 0);
if(ot)
ot->modalkeymap= km;
else
printf("error: modalkeymap_assign, unknown operator %s\n", opname);
}
UI: bring back function to convert keyboard event to string, and make the key event button work again.
2008-12-16 07:32:12 +00:00
/* ***************** get string from key events **************** */
BGE PyAPI support for subclassing any BGE game type from python, scripters define extra functions on gameObjects. Adding a UI to set the type on startup can be added easily. # ---- class myPlayer(GameTypes.KX_GameObject): def die(self): # ... do stuff ... self.endObject() # make an instance player = myPlayer(gameOb) # gameOb is made invalid now. player.die() # ---- One limitation (which could also be an advantage), is making the subclass instance will return that subclass everywhere, you cant have 2 different subclasses of the same BGE data at once.
2009-06-29 12:06:46 +00:00
const char *WM_key_event_string(short type)
UI: bring back function to convert keyboard event to string, and make the key event button work again.
2008-12-16 07:32:12 +00:00
{
RNA read-only wrapped wmEvent so python operators invoke functions * 2 new enums event_value_items and event_type_items in RNA_enum_types.h * WM_key_event_string now uses an RNA enum lookup rather then its own switch statement. * moved wmEvent from WM_types.h into DNA_windowmanager_types.h * added RNA_enum_identifier and RNA_enum_name to get strings from an enum value.
2009-06-21 14:30:59 +00:00
const char *name= NULL;
if(RNA_enum_name(event_type_items, (int)type, &name))
return name;
UI: bring back function to convert keyboard event to string, and make the key event button work again.
2008-12-16 07:32:12 +00:00
return "";
}
WM: changed WM_operator_call to take an argument, which specifies in which context to run the operator: WM_OP_DEFAULT, WM_OP_REGION_WIN, WM_OP_AREA or WM_OP_SCREEN. This also replaces WM_operator_call_rwin since it is more general. This is useful for buttons and popup menus to run operators, and also used by a new function to lookup the keymap item for that operator in the right context.
2008-12-16 07:44:21 +00:00
static char *wm_keymap_item_to_string(wmKeymapItem *kmi, char *str, int len)
{
char buf[100];
buf[0]= 0;
if(kmi->shift)
strcat(buf, "Shift ");
if(kmi->ctrl)
strcat(buf, "Ctrl ");
UI: * Only open tooltip when the mouse is still over the button. * Remove an unnecessary redraw call, though the two mentioned in the previous commit seem to be working OK (it's for action buttons when you move the mouse away from the button, holding the mouse button down). * Fix missing alt key in key event strings.
2008-12-16 17:36:51 +00:00
if(kmi->alt)
strcat(buf, "Alt ");
WM: changed WM_operator_call to take an argument, which specifies in which context to run the operator: WM_OP_DEFAULT, WM_OP_REGION_WIN, WM_OP_AREA or WM_OP_SCREEN. This also replaces WM_operator_call_rwin since it is more general. This is useful for buttons and popup menus to run operators, and also used by a new function to lookup the keymap item for that operator in the right context.
2008-12-16 07:44:21 +00:00
if(kmi->oskey)
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
strcat(buf, "Cmd ");
WM: changed WM_operator_call to take an argument, which specifies in which context to run the operator: WM_OP_DEFAULT, WM_OP_REGION_WIN, WM_OP_AREA or WM_OP_SCREEN. This also replaces WM_operator_call_rwin since it is more general. This is useful for buttons and popup menus to run operators, and also used by a new function to lookup the keymap item for that operator in the right context.
2008-12-16 07:44:21 +00:00
strcat(buf, WM_key_event_string(kmi->type));
BLI_strncpy(str, buf, len);
return str;
}
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
static wmKeymapItem *wm_keymap_item_find_handlers(ListBase *handlers, const char *opname, int opcontext, IDProperty *properties)
WM: changed WM_operator_call to take an argument, which specifies in which context to run the operator: WM_OP_DEFAULT, WM_OP_REGION_WIN, WM_OP_AREA or WM_OP_SCREEN. This also replaces WM_operator_call_rwin since it is more general. This is useful for buttons and popup menus to run operators, and also used by a new function to lookup the keymap item for that operator in the right context.
2008-12-16 07:44:21 +00:00
{
wmEventHandler *handler;
wmKeymapItem *kmi;
2.5: * Automatic shortcut keys in menus now compare operator properties as well. Implemented IDP_EqualsProperties for this. * I imagine all these compares may be a bit slow, for this case it's not so bad though because it only happens for one menu when it is opened.
2009-01-28 23:29:27 +00:00
/* find keymap item in handlers */
for(handler=handlers->first; handler; handler=handler->next)
if(handler->keymap)
for(kmi=handler->keymap->first; kmi; kmi=kmi->next)
if(strcmp(kmi->idname, opname) == 0 && WM_key_event_string(kmi->type)[0])
if(kmi->ptr && IDP_EqualsProperties(properties, kmi->ptr->data))
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
return kmi;
2.5: * Automatic shortcut keys in menus now compare operator properties as well. Implemented IDP_EqualsProperties for this. * I imagine all these compares may be a bit slow, for this case it's not so bad though because it only happens for one menu when it is opened.
2009-01-28 23:29:27 +00:00
return NULL;
}
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
static wmKeymapItem *wm_keymap_item_find(const bContext *C, const char *opname, int opcontext, IDProperty *properties)
2.5: * Automatic shortcut keys in menus now compare operator properties as well. Implemented IDP_EqualsProperties for this. * I imagine all these compares may be a bit slow, for this case it's not so bad though because it only happens for one menu when it is opened.
2009-01-28 23:29:27 +00:00
{
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
wmKeymapItem *found= NULL;
2.5: * Automatic shortcut keys in menus now compare operator properties as well. Implemented IDP_EqualsProperties for this. * I imagine all these compares may be a bit slow, for this case it's not so bad though because it only happens for one menu when it is opened.
2009-01-28 23:29:27 +00:00
/* look into multiple handler lists to find the item */
if(CTX_wm_window(C))
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
found= wm_keymap_item_find_handlers(&CTX_wm_window(C)->handlers, opname, opcontext, properties);
if(CTX_wm_area(C) && found==NULL)
found= wm_keymap_item_find_handlers(&CTX_wm_area(C)->handlers, opname, opcontext, properties);
if(found==NULL) {
if(ELEM(opcontext, WM_OP_EXEC_REGION_WIN, WM_OP_INVOKE_REGION_WIN)) {
if(CTX_wm_area(C)) {
ARegion *ar= CTX_wm_area(C)->regionbase.first;
for(; ar; ar= ar->next)
if(ar->regiontype==RGN_TYPE_WINDOW)
break;
if(ar)
found= wm_keymap_item_find_handlers(&ar->handlers, opname, opcontext, properties);
}
}
else {
if(CTX_wm_region(C))
found= wm_keymap_item_find_handlers(&CTX_wm_region(C)->handlers, opname, opcontext, properties);
WM: changed WM_operator_call to take an argument, which specifies in which context to run the operator: WM_OP_DEFAULT, WM_OP_REGION_WIN, WM_OP_AREA or WM_OP_SCREEN. This also replaces WM_operator_call_rwin since it is more general. This is useful for buttons and popup menus to run operators, and also used by a new function to lookup the keymap item for that operator in the right context.
2008-12-16 07:44:21 +00:00
}
}
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
return found;
}
char *WM_key_event_operator_string(const bContext *C, const char *opname, int opcontext, IDProperty *properties, char *str, int len)
{
wmKeymapItem *found= wm_keymap_item_find(C, opname, opcontext, properties);
if(found) {
wm_keymap_item_to_string(found, str, len);
return str;
WM: changed WM_operator_call to take an argument, which specifies in which context to run the operator: WM_OP_DEFAULT, WM_OP_REGION_WIN, WM_OP_AREA or WM_OP_SCREEN. This also replaces WM_operator_call_rwin since it is more general. This is useful for buttons and popup menus to run operators, and also used by a new function to lookup the keymap item for that operator in the right context.
2008-12-16 07:44:21 +00:00
}
return NULL;
}
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
/* searches context and changes keymap item, if found */
void WM_key_event_operator_change(const bContext *C, const char *opname, int opcontext, IDProperty *properties, short key, short modifier)
{
wmKeymapItem *found= wm_keymap_item_find(C, opname, opcontext, properties);
if(found) {
keymap_event_set(found, key, KM_PRESS, modifier, 0);
}
}
2.5 First step towards keymap editor! Before getting too excited: - doesn't save yet - no rna properties can be defined - no insert/remove keymap options yet - no option yet to set 'key press/release' But what does work; - Keymap list is in outliner, new category (Keymaps are listed in order as being created now) - enable/disable a keymap entry: click on dot icon - it displays python api names for ops - browse new operator for keymap (menu button) - set keymap to use other keys, mouse or tweak events - four modifier key options I first intent to test it all well, there are still quite some modal map conflicts (like border select) and there's problems assigning items to tweaks Another issue is that a visual editor for keymaps might be quite hard to use... the amount of data and options is just not so fun for a buttons menu. There are ways to improve this though. Maybe do this via a script?
2009-07-26 12:52:39 +00:00
/* ********************* */
int WM_key_event_is_tweak(short type)
{
if(type>=EVT_TWEAK_L && type<=EVT_GESTURE)
return 1;
return 0;
}
Copy Permalink