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
0865bf295947e5cd0b59429edf084f738321aef0
blender-archive/source/blender/windowmanager/intern/wm_keymap.c

240 lines
6.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 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 */
ListBase *WM_keymap_listbase(wmWindowManager *wm, const char *nameid, int spaceid, int regionid)
{
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;
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
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);
}
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
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)
strcat(buf, "OS ");
strcat(buf, WM_key_event_string(kmi->type));
BLI_strncpy(str, buf, len);
return str;
}
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
static char *wm_keymap_item_find(ListBase *handlers, const char *opname, int opcontext, IDProperty *properties, char *str, int len)
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))
return wm_keymap_item_to_string(kmi, str, len);
return NULL;
}
char *WM_key_event_operator_string(const bContext *C, const char *opname, int opcontext, IDProperty *properties, char *str, int len)
{
char *found= NULL;
/* look into multiple handler lists to find the item */
if(CTX_wm_window(C))
if((found= wm_keymap_item_find(&CTX_wm_window(C)->handlers, opname, opcontext, properties, str, len)))
return found;
if(CTX_wm_area(C))
if((found= wm_keymap_item_find(&CTX_wm_area(C)->handlers, opname, opcontext, properties, str, len)))
return found;
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
if(ELEM(opcontext, WM_OP_EXEC_REGION_WIN, WM_OP_INVOKE_REGION_WIN)) {
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
if(CTX_wm_area(C)) {
ARegion *ar= CTX_wm_area(C)->regionbase.first;
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
for(; ar; ar= ar->next)
if(ar->regiontype==RGN_TYPE_WINDOW)
break;
if(ar)
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
if((found= wm_keymap_item_find(&ar->handlers, opname, opcontext, properties, str, len)))
return found;
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
}
}
else {
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
if(CTX_wm_region(C))
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
if((found= wm_keymap_item_find(&CTX_wm_region(C)->handlers, opname, opcontext, properties, str, len)))
return found;
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;
}
Copy Permalink