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

927 lines
24 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
/**
Fix syntax for ID keyword.
2010-03-21 01:14:04 +00:00
* $Id$
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
*
* ***** 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,
correct fsf address
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
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
*
* The Original Code is Copyright (C) 2007 Blender Foundation.
* All rights reserved.
*
*
* Contributor(s): Blender Foundation
*
* ***** END GPL LICENSE BLOCK *****
*/
#include <string.h>
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
#include "DNA_object_types.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"
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
#include "DNA_space_types.h"
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
#include "DNA_userdef_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"
Operator Execution Contexts Bugfix: This commit adds a few more execution contexts for operators, given the increasing tendency for some special regiontypes to exist within areas that must have their own set of special operators. Examples of these include the "channel" operators in the Animation Editors (i.e. those in the 'Channels' menu), and the "Fit to Preview Window" operator for the Sequencer. Previously, operators such as these would not function when clicked on from the menus, and they would not show the hotkeys they were mapped to. Also, fixed a few operator definitions in the Animation Editors which were missing ot->prop defines. This meant that some hotkeys (mainly selection) were shown incorrectly in the menus.
2010-02-07 23:39:44 +00:00
#include "BKE_screen.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"
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"
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
/* ********************* key config ***********************/
PROP_ENUM_NO_CONTEXT flag for rna properties, forcing enum item functions to be passed a null context (to return non-contextual items). This is set on keymap item operator properties and macro definition operator properties to make them non-contextual (since the context at definition time is most likely not the same then at execution time, it's better to have all options visible). This removes some more errors in keymap export and import. This commit also sanitize some enum item function, making sure they can cope with null context and have usable defaults in that case.
2010-01-27 21:19:39 +00:00
static void keymap_properties_set(wmKeyMapItem *kmi)
{
WM_operator_properties_alloc(&(kmi->ptr), &(kmi->properties), kmi->idname);
Remove NO_CONTEXT flag from enum when copying operator properties to the operator itself.
2010-02-01 18:26:45 +00:00
WM_operator_properties_sanitize(kmi->ptr, 1);
PROP_ENUM_NO_CONTEXT flag for rna properties, forcing enum item functions to be passed a null context (to return non-contextual items). This is set on keymap item operator properties and macro definition operator properties to make them non-contextual (since the context at definition time is most likely not the same then at execution time, it's better to have all options visible). This removes some more errors in keymap export and import. This commit also sanitize some enum item function, making sure they can cope with null context and have usable defaults in that case.
2010-01-27 21:19:39 +00:00
}
bugfix [#24635] "Add Shortcut"
2010-11-10 11:19:52 +00:00
/* properties can be NULL, otherwise the arg passed is used and ownership is given to the kmi */
void WM_keymap_properties_reset(wmKeyMapItem *kmi, struct IDProperty *properties)
Reset operator properties for keymap items when operator idname is changed. This means added operators in the keymap editor will now show options correctly (maybe not for old .B25.blend)
2009-12-02 04:12:16 +00:00
{
WM_operator_properties_free(kmi->ptr);
MEM_freeN(kmi->ptr);
kmi->ptr = NULL;
bugfix [#24635] "Add Shortcut"
2010-11-10 11:19:52 +00:00
kmi->properties = properties;
Reset operator properties for keymap items when operator idname is changed. This means added operators in the keymap editor will now show options correctly (maybe not for old .B25.blend)
2009-12-02 04:12:16 +00:00
PROP_ENUM_NO_CONTEXT flag for rna properties, forcing enum item functions to be passed a null context (to return non-contextual items). This is set on keymap item operator properties and macro definition operator properties to make them non-contextual (since the context at definition time is most likely not the same then at execution time, it's better to have all options visible). This removes some more errors in keymap export and import. This commit also sanitize some enum item function, making sure they can cope with null context and have usable defaults in that case.
2010-01-27 21:19:39 +00:00
keymap_properties_set(kmi);
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
}
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
wmKeyConfig *WM_keyconfig_new(wmWindowManager *wm, const char *idname)
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
{
wmKeyConfig *keyconf;
keyconf= MEM_callocN(sizeof(wmKeyConfig), "wmKeyConfig");
BLI_strncpy(keyconf->idname, idname, sizeof(keyconf->idname));
BLI_addtail(&wm->keyconfigs, keyconf);
return keyconf;
}
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
wmKeyConfig *WM_keyconfig_new_user(wmWindowManager *wm, const char *idname)
Keyconfig import and remove - Keyconfig are now marked as user_defined when it is the case - Import keyconfig operator: select an exported keyconfig .py file, copies it to the scripts folder (keep the original copy if wanted, default True), imports and select as active config. The active keyconfig is stored in the user default file, so that still has to be saved after import. - Remove keyconfig operator and button next to the keyconfig name (poll False if not user_defined). Removes the keyconfig from the list and deletes the file from the folder. Remaining bug: The file is copied in the user defined script folder (if present) or the /scripts/ui folder. The problem is that it might be imported before operators defined in python are imported themselves. One solution would be to use a separate folder for keyconfigs that is imported after all others.
2010-01-28 19:54:06 +00:00
{
- keymap import/export works again (broke with own api changes) - function renames, move WM functions into collections wm.add_keymap() --> wm.keymaps.new() note: new is used for named items in a collection, which return the result. - Action.get_frame_range() is now a readonly property 'frame_range', floats rather then ints.
2010-08-30 13:50:59 +00:00
wmKeyConfig *keyconf = WM_keyconfig_new(wm, idname);
Keyconfig import and remove - Keyconfig are now marked as user_defined when it is the case - Import keyconfig operator: select an exported keyconfig .py file, copies it to the scripts folder (keep the original copy if wanted, default True), imports and select as active config. The active keyconfig is stored in the user default file, so that still has to be saved after import. - Remove keyconfig operator and button next to the keyconfig name (poll False if not user_defined). Removes the keyconfig from the list and deletes the file from the folder. Remaining bug: The file is copied in the user defined script folder (if present) or the /scripts/ui folder. The problem is that it might be imported before operators defined in python are imported themselves. One solution would be to use a separate folder for keyconfigs that is imported after all others.
2010-01-28 19:54:06 +00:00
keyconf->flag |= KEYCONF_USER;
return keyconf;
}
void WM_keyconfig_remove(wmWindowManager *wm, wmKeyConfig *keyconf)
{
if (keyconf) {
if (BLI_streq(U.keyconfigstr, keyconf->idname)) {
BLI_strncpy(U.keyconfigstr, wm->defaultconf->idname, sizeof(U.keyconfigstr));
}
BLI_remlink(&wm->keyconfigs, keyconf);
WM_keyconfig_free(keyconf);
}
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
void WM_keyconfig_free(wmKeyConfig *keyconf)
{
wmKeyMap *km;
while((km= keyconf->keymaps.first)) {
WM_keymap_free(km);
BLI_freelinkN(&keyconf->keymaps, km);
}
MEM_freeN(keyconf);
}
- UNUSED macro wasn't throwing an error with GCC if a var become used. - made interface, windowmanager, readfile build without unused warnings. - re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
2010-10-16 02:40:31 +00:00
void WM_keyconfig_userdef(void)
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
{
wmKeyMap *km;
wmKeyMapItem *kmi;
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
for(km=U.keymaps.first; km; km=km->next) {
/* modal keymaps don't have operator properties */
if ((km->flag & KEYMAP_MODAL) == 0) {
for(kmi=km->items.first; kmi; kmi=kmi->next) {
keymap_properties_set(kmi);
}
}
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
}
static wmKeyConfig *wm_keyconfig_list_find(ListBase *lb, char *idname)
{
wmKeyConfig *kc;
for(kc= lb->first; kc; kc= kc->next)
if(0==strncmp(idname, kc->idname, KMAP_MAX_NAME))
return kc;
return NULL;
}
/* ************************ free ************************* */
void WM_keymap_free(wmKeyMap *keymap)
{
wmKeyMapItem *kmi;
for(kmi=keymap->items.first; kmi; kmi=kmi->next) {
if(kmi->ptr) {
WM_operator_properties_free(kmi->ptr);
MEM_freeN(kmi->ptr);
}
}
BLI_freelistN(&keymap->items);
}
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
/* ***************** generic call, exported **************** */
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
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
}
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 */
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmKeyMapItem *WM_keymap_verify_item(wmKeyMap *keymap, char *idname, int type, int val, int modifier, int 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
{
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmKeyMapItem *kmi;
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
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
for(kmi= keymap->items.first; kmi; kmi= kmi->next)
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(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) {
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
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
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
BLI_addtail(&keymap->items, 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
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
Missing id assignment for kmi creation function (2 out of 3 isn't good enough).
2009-12-21 01:44:33 +00:00
if ((keymap->flag & KEYMAP_USER) == 0) {
keymap->kmi_id++;
kmi->id = keymap->kmi_id;
}
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 */
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
wmKeyMapItem *WM_keymap_add_item(wmKeyMap *keymap, const char *idname, int type, int val, int modifier, int 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
{
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmKeyMapItem *kmi= 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
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
BLI_addtail(&keymap->items, 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
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);
keymap editor New unique ID per keymap item (unique inside their keymap) for default and configuration keymaps. This allows restoring a single user defined kmi to its previous (default or config) values instead of having to restore the whole keymap. The restore item button is disabled for kmi added by the users (they don't have an ID). Also fixes a bug in the rna function for add keymap item (parameter order was incorrect, messing adding back saved configurations).
2009-12-17 03:32:33 +00:00
if ((keymap->flag & KEYMAP_USER) == 0) {
keymap->kmi_id++;
kmi->id = keymap->kmi_id;
}
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;
}
new function WM_keymap_add_menu(), similar to WM_keymap_add_item() except it takes a registered menu. the key will then trigger this menu.
2009-11-17 15:29:55 +00:00
/* menu wrapper for WM_keymap_add_item */
wmKeyMapItem *WM_keymap_add_menu(wmKeyMap *keymap, char *idname, int type, int val, int modifier, int keymodifier)
{
wmKeyMapItem *kmi= WM_keymap_add_item(keymap, "WM_OT_call_menu", type, val, modifier, keymodifier);
RNA_string_set(kmi->ptr, "name", idname);
return kmi;
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
void WM_keymap_remove_item(wmKeyMap *keymap, wmKeyMapItem *kmi)
{
if(BLI_findindex(&keymap->items, kmi) != -1) {
if(kmi->ptr) {
WM_operator_properties_free(kmi->ptr);
MEM_freeN(kmi->ptr);
}
BLI_freelinkN(&keymap->items, 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 */
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
wmKeyMap *WM_keymap_list_find(ListBase *lb, const char *idname, int spaceid, int 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;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
for(km= lb->first; km; km= km->next)
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->spaceid==spaceid && km->regionid==regionid)
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(0==strncmp(idname, km->idname, KMAP_MAX_NAME))
Keymaps now have a poll() function, rather than adding/removing their handlers based on notifiers, which is simpler and more reliable. This fixes for example editmode or uv edit keymaps not working when creating a new 3dview or image space.
2009-09-17 21:36:02 +00:00
return 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
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
return NULL;
}
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
wmKeyMap *WM_keymap_find(wmKeyConfig *keyconf, const char *idname, int spaceid, int regionid)
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
{
RNA functions to find keymaps in a keyconfig (from the usual idname + space or modal keymaps from operator id)
2009-12-08 18:02:50 +00:00
wmKeyMap *km= WM_keymap_list_find(&keyconf->keymaps, idname, spaceid, regionid);
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
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");
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
BLI_strncpy(km->idname, idname, KMAP_MAX_NAME);
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
km->spaceid= spaceid;
km->regionid= regionid;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
BLI_addtail(&keyconf->keymaps, km);
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
}
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;
}
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
wmKeyMap *WM_keymap_find_all(const bContext *C, const char *idname, int spaceid, int regionid)
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
{
wmWindowManager *wm = CTX_wm_manager(C);
wmKeyConfig *keyconf;
wmKeyMap *km;
/* first user defined keymaps */
km= WM_keymap_list_find(&U.keymaps, idname, spaceid, regionid);
if (km)
return km;
/* then user key config */
keyconf= wm_keyconfig_list_find(&wm->keyconfigs, U.keyconfigstr);
if(keyconf) {
km= WM_keymap_list_find(&keyconf->keymaps, idname, spaceid, regionid);
if (km)
return km;
}
/* then use default */
km= WM_keymap_list_find(&wm->defaultconf->keymaps, idname, spaceid, regionid);
if (km)
return km;
else
return NULL;
}
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 */
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
wmKeyMap *WM_modalkeymap_add(wmKeyConfig *keyconf, const char *idname, EnumPropertyItem *items)
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
{
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmKeyMap *km= WM_keymap_find(keyconf, idname, 0, 0);
km->flag |= KEYMAP_MODAL;
km->modal_items= items;
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;
}
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
wmKeyMap *WM_modalkeymap_get(wmKeyConfig *keyconf, const char *idname)
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
{
wmKeyMap *km;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
for(km= keyconf->keymaps.first; km; km= km->next)
if(km->flag & KEYMAP_MODAL)
if(0==strncmp(idname, km->idname, KMAP_MAX_NAME))
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
break;
return km;
}
Fixing keymap export: - Didn't support new userdef keymaps (new "active" rna function to get the active version of a keymap) - Didn't support modal keymaps (new "modal" param to add_keymap function, new "add_modal_item" function on keymaps (both functions now make sure the keymap is of the right type))
2009-11-16 20:50:02 +00:00
wmKeyMapItem *WM_modalkeymap_add_item(wmKeyMap *km, int type, int val, int modifier, int keymodifier, int value)
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
{
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmKeyMapItem *kmi= MEM_callocN(sizeof(wmKeyMapItem), "keymap entry");
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
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
BLI_addtail(&km->items, 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
kmi->propvalue= value;
keymap_event_set(kmi, type, val, modifier, keymodifier);
Fixing keymap export: - Didn't support new userdef keymaps (new "active" rna function to get the active version of a keymap) - Didn't support modal keymaps (new "modal" param to add_keymap function, new "add_modal_item" function on keymaps (both functions now make sure the keymap is of the right type))
2009-11-16 20:50:02 +00:00
keymap editor New unique ID per keymap item (unique inside their keymap) for default and configuration keymaps. This allows restoring a single user defined kmi to its previous (default or config) values instead of having to restore the whole keymap. The restore item button is disabled for kmi added by the users (they don't have an ID). Also fixes a bug in the rna function for add keymap item (parameter order was incorrect, messing adding back saved configurations).
2009-12-17 03:32:33 +00:00
if ((km->flag & KEYMAP_USER) == 0) {
km->kmi_id++;
kmi->id = km->kmi_id;
}
Fixing keymap export: - Didn't support new userdef keymaps (new "active" rna function to get the active version of a keymap) - Didn't support modal keymaps (new "modal" param to add_keymap function, new "add_modal_item" function on keymaps (both functions now make sure the keymap is of the right type))
2009-11-16 20:50:02 +00:00
return 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
}
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
void WM_modalkeymap_assign(wmKeyMap *km, const char *opname)
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
{
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 "";
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
char *WM_keymap_item_to_string(wmKeyMapItem *kmi, 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
{
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
char buf[128];
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
buf[0]= 0;
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
if (kmi->shift == KM_ANY &&
kmi->ctrl == KM_ANY &&
kmi->alt == KM_ANY &&
kmi->oskey == KM_ANY) {
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
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
strcat(buf, "Any ");
} else {
if(kmi->shift)
strcat(buf, "Shift ");
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
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
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
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
if(kmi->alt)
strcat(buf, "Alt ");
if(kmi->oskey)
strcat(buf, "Cmd ");
}
Toolbar Fixes: * Restored the Grease Pencil tools to the toolbar Probably, if the reason they were commented out before was so that the repeat stuff is visible, we can swap the order of those two. Otherwise, it's good to have somewhere for the operators now (so that the hotkeys can be found) * Hotkey displays in the tooltips now show the keymodifier too For example, "D LeftMouse" or "Ctrl D LeftMouse" for the Grease Pencil operators, instead of just "LeftMouse" or "Ctrl LeftMouse".
2009-10-25 03:47:14 +00:00
if(kmi->keymodifier) {
strcat(buf, WM_key_event_string(kmi->keymodifier));
strcat(buf, " ");
}
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;
}
- UNUSED macro wasn't throwing an error with GCC if a var become used. - made interface, windowmanager, readfile build without unused warnings. - re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
2010-10-16 02:40:31 +00:00
static wmKeyMapItem *wm_keymap_item_find_handlers(const bContext *C, ListBase *handlers, const char *opname, int UNUSED(opcontext), IDProperty *properties, int compare_props, int hotkey, wmKeyMap **keymap_r)
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
{
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmWindowManager *wm= CTX_wm_manager(C);
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;
Keymaps now have a poll() function, rather than adding/removing their handlers based on notifiers, which is simpler and more reliable. This fixes for example editmode or uv edit keymaps not working when creating a new 3dview or image space.
2009-09-17 21:36:02 +00:00
wmKeyMap *keymap;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmKeyMapItem *kmi;
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: * 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 */
UI: * layout.itemR now has icon_only option to show only icon in e.g. enums buttons, for uv editor header. * Automatic key shortcuts in menus now show the shortcut even if operator properties don't match. Not sure this will work well everywhere, but seems to be working ok for now. * Open recent now show shorter filenames instead of the whole file path. * Tweak object Duplicate menu item.
2009-09-10 14:20:21 +00:00
for(handler=handlers->first; handler; handler=handler->next) {
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
keymap= WM_keymap_active(wm, handler->keymap);
Keymaps now have a poll() function, rather than adding/removing their handlers based on notifiers, which is simpler and more reliable. This fixes for example editmode or uv edit keymaps not working when creating a new 3dview or image space.
2009-09-17 21:36:02 +00:00
if(keymap && (!keymap->poll || keymap->poll((bContext*)C))) {
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
for(kmi=keymap->items.first; kmi; kmi=kmi->next) {
UI: * layout.itemR now has icon_only option to show only icon in e.g. enums buttons, for uv editor header. * Automatic key shortcuts in menus now show the shortcut even if operator properties don't match. Not sure this will work well everywhere, but seems to be working ok for now. * Open recent now show shorter filenames instead of the whole file path. * Tweak object Duplicate menu item.
2009-09-10 14:20:21 +00:00
if(strcmp(kmi->idname, opname) == 0 && WM_key_event_string(kmi->type)[0]) {
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
if (hotkey)
if (!ISHOTKEY(kmi->type))
continue;
UI: * layout.itemR now has icon_only option to show only icon in e.g. enums buttons, for uv editor header. * Automatic key shortcuts in menus now show the shortcut even if operator properties don't match. Not sure this will work well everywhere, but seems to be working ok for now. * Open recent now show shorter filenames instead of the whole file path. * Tweak object Duplicate menu item.
2009-09-10 14:20:21 +00:00
if(compare_props) {
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(kmi->ptr && IDP_EqualsProperties(properties, kmi->ptr->data)) {
if(keymap_r) *keymap_r= keymap;
UI: * layout.itemR now has icon_only option to show only icon in e.g. enums buttons, for uv editor header. * Automatic key shortcuts in menus now show the shortcut even if operator properties don't match. Not sure this will work well everywhere, but seems to be working ok for now. * Open recent now show shorter filenames instead of the whole file path. * Tweak object Duplicate menu item.
2009-09-10 14:20:21 +00:00
return kmi;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
}
UI: * layout.itemR now has icon_only option to show only icon in e.g. enums buttons, for uv editor header. * Automatic key shortcuts in menus now show the shortcut even if operator properties don't match. Not sure this will work well everywhere, but seems to be working ok for now. * Open recent now show shorter filenames instead of the whole file path. * Tweak object Duplicate menu item.
2009-09-10 14:20:21 +00:00
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
else {
if(keymap_r) *keymap_r= keymap;
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
return kmi;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
}
UI: * layout.itemR now has icon_only option to show only icon in e.g. enums buttons, for uv editor header. * Automatic key shortcuts in menus now show the shortcut even if operator properties don't match. Not sure this will work well everywhere, but seems to be working ok for now. * Open recent now show shorter filenames instead of the whole file path. * Tweak object Duplicate menu item.
2009-09-10 14:20:21 +00:00
}
}
}
}
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
set the keymap to NULL if its not found so as not to use it un-initializes.
2010-01-26 10:14:39 +00:00
/* ensure un-initialized keymap is never used */
if(keymap_r) *keymap_r= 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
return NULL;
}
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
static wmKeyMapItem *wm_keymap_item_find_props(const bContext *C, const char *opname, int opcontext, IDProperty *properties, int compare_props, int hotkey, wmKeyMap **keymap_r)
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
{
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmWindow *win= CTX_wm_window(C);
ScrArea *sa= CTX_wm_area(C);
ARegion *ar= CTX_wm_region(C);
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 */
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(win)
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
found= wm_keymap_item_find_handlers(C, &win->handlers, opname, opcontext, properties, compare_props, hotkey, keymap_r);
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(sa && found==NULL)
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
found= wm_keymap_item_find_handlers(C, &sa->handlers, opname, opcontext, properties, compare_props, hotkey, keymap_r);
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
if(found==NULL) {
if(ELEM(opcontext, WM_OP_EXEC_REGION_WIN, WM_OP_INVOKE_REGION_WIN)) {
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(sa) {
Operator Execution Contexts Bugfix: This commit adds a few more execution contexts for operators, given the increasing tendency for some special regiontypes to exist within areas that must have their own set of special operators. Examples of these include the "channel" operators in the Animation Editors (i.e. those in the 'Channels' menu), and the "Fit to Preview Window" operator for the Sequencer. Previously, operators such as these would not function when clicked on from the menus, and they would not show the hotkeys they were mapped to. Also, fixed a few operator definitions in the Animation Editors which were missing ot->prop defines. This meant that some hotkeys (mainly selection) were shown incorrectly in the menus.
2010-02-07 23:39:44 +00:00
if (!(ar && ar->regiontype == RGN_TYPE_WINDOW))
ar= BKE_area_find_region_type(sa, RGN_TYPE_WINDOW);
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
if(ar)
Fix #21116: wrong shortcut key in view navigation menu.
2010-02-15 14:15:34 +00:00
found= wm_keymap_item_find_handlers(C, &ar->handlers, opname, opcontext, properties, compare_props, hotkey, keymap_r);
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
}
}
Operator Execution Contexts Bugfix: This commit adds a few more execution contexts for operators, given the increasing tendency for some special regiontypes to exist within areas that must have their own set of special operators. Examples of these include the "channel" operators in the Animation Editors (i.e. those in the 'Channels' menu), and the "Fit to Preview Window" operator for the Sequencer. Previously, operators such as these would not function when clicked on from the menus, and they would not show the hotkeys they were mapped to. Also, fixed a few operator definitions in the Animation Editors which were missing ot->prop defines. This meant that some hotkeys (mainly selection) were shown incorrectly in the menus.
2010-02-07 23:39:44 +00:00
else if(ELEM(opcontext, WM_OP_EXEC_REGION_CHANNELS, WM_OP_INVOKE_REGION_CHANNELS)) {
if (!(ar && ar->regiontype == RGN_TYPE_CHANNELS))
ar= BKE_area_find_region_type(sa, RGN_TYPE_CHANNELS);
if(ar)
Fix #21116: wrong shortcut key in view navigation menu.
2010-02-15 14:15:34 +00:00
found= wm_keymap_item_find_handlers(C, &ar->handlers, opname, opcontext, properties, compare_props, hotkey, keymap_r);
Operator Execution Contexts Bugfix: This commit adds a few more execution contexts for operators, given the increasing tendency for some special regiontypes to exist within areas that must have their own set of special operators. Examples of these include the "channel" operators in the Animation Editors (i.e. those in the 'Channels' menu), and the "Fit to Preview Window" operator for the Sequencer. Previously, operators such as these would not function when clicked on from the menus, and they would not show the hotkeys they were mapped to. Also, fixed a few operator definitions in the Animation Editors which were missing ot->prop defines. This meant that some hotkeys (mainly selection) were shown incorrectly in the menus.
2010-02-07 23:39:44 +00:00
}
else if(ELEM(opcontext, WM_OP_EXEC_REGION_PREVIEW, WM_OP_INVOKE_REGION_PREVIEW)) {
if (!(ar && ar->regiontype == RGN_TYPE_PREVIEW))
ar= BKE_area_find_region_type(sa, RGN_TYPE_PREVIEW);
if(ar)
Fix #21116: wrong shortcut key in view navigation menu.
2010-02-15 14:15:34 +00:00
found= wm_keymap_item_find_handlers(C, &ar->handlers, opname, opcontext, properties, compare_props, hotkey, keymap_r);
Operator Execution Contexts Bugfix: This commit adds a few more execution contexts for operators, given the increasing tendency for some special regiontypes to exist within areas that must have their own set of special operators. Examples of these include the "channel" operators in the Animation Editors (i.e. those in the 'Channels' menu), and the "Fit to Preview Window" operator for the Sequencer. Previously, operators such as these would not function when clicked on from the menus, and they would not show the hotkeys they were mapped to. Also, fixed a few operator definitions in the Animation Editors which were missing ot->prop defines. This meant that some hotkeys (mainly selection) were shown incorrectly in the menus.
2010-02-07 23:39:44 +00:00
}
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
else {
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(ar)
Fix #21116: wrong shortcut key in view navigation menu.
2010-02-15 14:15:34 +00:00
found= wm_keymap_item_find_handlers(C, &ar->handlers, opname, opcontext, properties, compare_props, hotkey, keymap_r);
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;
}
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
static wmKeyMapItem *wm_keymap_item_find(const bContext *C, const char *opname, int opcontext, IDProperty *properties, int hotkey, wmKeyMap **keymap_r)
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
{
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
wmKeyMapItem *found= wm_keymap_item_find_props(C, opname, opcontext, properties, 1, hotkey, keymap_r);
UI: * layout.itemR now has icon_only option to show only icon in e.g. enums buttons, for uv editor header. * Automatic key shortcuts in menus now show the shortcut even if operator properties don't match. Not sure this will work well everywhere, but seems to be working ok for now. * Open recent now show shorter filenames instead of the whole file path. * Tweak object Duplicate menu item.
2009-09-10 14:20:21 +00:00
if(!found)
Fix #21116: wrong shortcut key in view navigation menu.
2010-02-15 14:15:34 +00:00
found= wm_keymap_item_find_props(C, opname, opcontext, NULL, 0, hotkey, keymap_r);
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
return found;
}
char *WM_key_event_operator_string(const bContext *C, const char *opname, int opcontext, IDProperty *properties, char *str, int len)
{
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
wmKeyMapItem *kmi= wm_keymap_item_find(C, opname, opcontext, properties, 0, NULL);
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(kmi) {
WM_keymap_item_to_string(kmi, str, len);
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
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;
}
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
int WM_key_event_operator_id(const bContext *C, const char *opname, int opcontext, IDProperty *properties, int hotkey, wmKeyMap **keymap_r)
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
{
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
wmKeyMapItem *kmi= wm_keymap_item_find(C, opname, opcontext, properties, hotkey, keymap_r);
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
if(kmi)
return kmi->id;
else
return 0;
}
Keymap conflict detection operator. Takes into account the hierarchical structures of keymaps as well as wildcards (KM_ANY) in event definitions, user remaps (emulate numpad, action/select mouse buttons, ...) and event values that overlap (click, press and release) For now, doesn't do anything other than print conflicts in the console. As a result, I cleaned up a lot of keymaps that had double definitions, moved some keymap items in more appropriate places, fixed wrong definitions and removed kmi that were added for testing a long long time ago. Out of all the remaining conflicts, after removing obvious non-issues, here's what remains: http://www.pasteall.org/9898
2009-12-17 22:14:43 +00:00
int WM_keymap_item_compare(wmKeyMapItem *k1, wmKeyMapItem *k2)
{
int k1type, k2type;
if (k1->flag & KMI_INACTIVE || k2->flag & KMI_INACTIVE)
return 0;
/* take event mapping into account */
k1type = WM_userdef_event_map(k1->type);
k2type = WM_userdef_event_map(k2->type);
if(k1type != KM_ANY && k2type != KM_ANY && k1type != k2type)
return 0;
if(k1->val != KM_ANY && k2->val != KM_ANY) {
/* take click, press, release conflict into account */
if (k1->val == KM_CLICK && ELEM3(k2->val, KM_PRESS, KM_RELEASE, KM_CLICK) == 0)
return 0;
if (k2->val == KM_CLICK && ELEM3(k1->val, KM_PRESS, KM_RELEASE, KM_CLICK) == 0)
return 0;
if (k1->val != k2->val)
return 0;
}
if(k1->shift != KM_ANY && k2->shift != KM_ANY && k1->shift != k2->shift)
return 0;
if(k1->ctrl != KM_ANY && k2->ctrl != KM_ANY && k1->ctrl != k2->ctrl)
return 0;
if(k1->alt != KM_ANY && k2->alt != KM_ANY && k1->alt != k2->alt)
return 0;
if(k1->oskey != KM_ANY && k2->oskey != KM_ANY && k1->oskey != k2->oskey)
return 0;
if(k1->keymodifier != k2->keymodifier)
return 0;
return 1;
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
/* ***************** user preferences ******************* */
UI: * layout.itemR now has icon_only option to show only icon in e.g. enums buttons, for uv editor header. * Automatic key shortcuts in menus now show the shortcut even if operator properties don't match. Not sure this will work well everywhere, but seems to be working ok for now. * Open recent now show shorter filenames instead of the whole file path. * Tweak object Duplicate menu item.
2009-09-10 14:20:21 +00:00
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
int WM_keymap_user_init(wmWindowManager *wm, wmKeyMap *keymap)
{
wmKeyConfig *keyconf;
wmKeyMap *km;
if(!keymap)
return 0;
/* init from user key config */
keyconf= wm_keyconfig_list_find(&wm->keyconfigs, U.keyconfigstr);
if(keyconf) {
RNA functions to find keymaps in a keyconfig (from the usual idname + space or modal keymaps from operator id)
2009-12-08 18:02:50 +00:00
km= WM_keymap_list_find(&keyconf->keymaps, keymap->idname, keymap->spaceid, keymap->regionid);
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
if(km) {
keymap->poll= km->poll; /* lazy init */
keymap->modal_items= km->modal_items;
return 1;
}
}
/* or from default */
RNA functions to find keymaps in a keyconfig (from the usual idname + space or modal keymaps from operator id)
2009-12-08 18:02:50 +00:00
km= WM_keymap_list_find(&wm->defaultconf->keymaps, keymap->idname, keymap->spaceid, keymap->regionid);
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
if(km) {
keymap->poll= km->poll; /* lazy init */
keymap->modal_items= km->modal_items;
return 1;
}
return 0;
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmKeyMap *WM_keymap_active(wmWindowManager *wm, wmKeyMap *keymap)
{
wmKeyConfig *keyconf;
wmKeyMap *km;
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(!keymap)
return NULL;
/* first user defined keymaps */
RNA functions to find keymaps in a keyconfig (from the usual idname + space or modal keymaps from operator id)
2009-12-08 18:02:50 +00:00
km= WM_keymap_list_find(&U.keymaps, keymap->idname, keymap->spaceid, keymap->regionid);
Fix #19640: user defined keymaps did not use poll function.
2009-10-19 11:11:35 +00:00
if(km) {
km->poll= keymap->poll; /* lazy init */
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
km->modal_items= keymap->modal_items;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
return km;
Fix #19640: user defined keymaps did not use poll function.
2009-10-19 11:11:35 +00:00
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
/* then user key config */
keyconf= wm_keyconfig_list_find(&wm->keyconfigs, U.keyconfigstr);
if(keyconf) {
RNA functions to find keymaps in a keyconfig (from the usual idname + space or modal keymaps from operator id)
2009-12-08 18:02:50 +00:00
km= WM_keymap_list_find(&keyconf->keymaps, keymap->idname, keymap->spaceid, keymap->regionid);
Fix #19640: user defined keymaps did not use poll function.
2009-10-19 11:11:35 +00:00
if(km) {
km->poll= keymap->poll; /* lazy init */
=== Better support for user defined modal keymaps === Fixing/Missing RNA properties: - "virtual" property for "ANY" modifier for keymapitem - modal property for keymap - Look up modal_items in usermaps too Lazy init usermaps needs to init modal_items too. New function to initialize a user keymap (fill in modal_item and poll pointers). Operator modal keymaps now look up if there's a user defined keymap that overwrites it. Full Event UI buttons now show "Any" when modifier is set to that (instead of listing all of them). Note: Having the modifiers as boolean still doesn't express the full breath of values possible for them. There is commented code in this commit to represent them as enum, which would solve this, but make the keymap editor more cryptic.
2009-11-15 19:25:34 +00:00
km->modal_items= keymap->modal_items;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
return km;
Fix #19640: user defined keymaps did not use poll function.
2009-10-19 11:11:35 +00:00
}
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
/* then use default */
RNA functions to find keymaps in a keyconfig (from the usual idname + space or modal keymaps from operator id)
2009-12-08 18:02:50 +00:00
km= WM_keymap_list_find(&wm->defaultconf->keymaps, keymap->idname, keymap->spaceid, keymap->regionid);
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
return km;
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmKeyMap *WM_keymap_copy_to_user(wmKeyMap *keymap)
{
wmKeyMap *usermap;
wmKeyMapItem *kmi;
RNA functions to find keymaps in a keyconfig (from the usual idname + space or modal keymaps from operator id)
2009-12-08 18:02:50 +00:00
usermap= WM_keymap_list_find(&U.keymaps, keymap->idname, keymap->spaceid, keymap->regionid);
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(!usermap) {
/* not saved yet, duplicate existing */
usermap= MEM_dupallocN(keymap);
usermap->modal_items= NULL;
usermap->poll= NULL;
usermap->flag |= KEYMAP_USER;
BLI_addtail(&U.keymaps, usermap);
}
else {
/* already saved, free items for re-copy */
WM_keymap_free(usermap);
}
BLI_duplicatelist(&usermap->items, &keymap->items);
for(kmi=usermap->items.first; kmi; kmi=kmi->next) {
if(kmi->properties) {
kmi->ptr= MEM_callocN(sizeof(PointerRNA), "UserKeyMapItemPtr");
WM_operator_properties_create(kmi->ptr, kmi->idname);
kmi->properties= IDP_CopyProperty(kmi->properties);
kmi->ptr->data= kmi->properties;
}
}
for(kmi=keymap->items.first; kmi; kmi=kmi->next)
kmi->flag &= ~KMI_EXPANDED;
return usermap;
}
keymap editor New unique ID per keymap item (unique inside their keymap) for default and configuration keymaps. This allows restoring a single user defined kmi to its previous (default or config) values instead of having to restore the whole keymap. The restore item button is disabled for kmi added by the users (they don't have an ID). Also fixes a bug in the rna function for add keymap item (parameter order was incorrect, messing adding back saved configurations).
2009-12-17 03:32:33 +00:00
void WM_keymap_restore_item_to_default(bContext *C, wmKeyMap *keymap, wmKeyMapItem *kmi)
{
wmWindowManager *wm = CTX_wm_manager(C);
wmKeyConfig *keyconf;
wmKeyMap *km = NULL;
/* look in user key config */
keyconf= wm_keyconfig_list_find(&wm->keyconfigs, U.keyconfigstr);
if(keyconf) {
km= WM_keymap_list_find(&keyconf->keymaps, keymap->idname, keymap->spaceid, keymap->regionid);
}
if (!km) {
/* or from default */
km= WM_keymap_list_find(&wm->defaultconf->keymaps, keymap->idname, keymap->spaceid, keymap->regionid);
}
if (km) {
Speed up keymap editor a bit (less context changes)
2010-01-29 02:01:02 +00:00
wmKeyMapItem *orig = WM_keymap_item_find_id(km, kmi->id);
keymap editor New unique ID per keymap item (unique inside their keymap) for default and configuration keymaps. This allows restoring a single user defined kmi to its previous (default or config) values instead of having to restore the whole keymap. The restore item button is disabled for kmi added by the users (they don't have an ID). Also fixes a bug in the rna function for add keymap item (parameter order was incorrect, messing adding back saved configurations).
2009-12-17 03:32:33 +00:00
if (orig) {
if(strcmp(orig->idname, kmi->idname) != 0) {
BLI_strncpy(kmi->idname, orig->idname, sizeof(kmi->idname));
bugfix [#24635] "Add Shortcut"
2010-11-10 11:19:52 +00:00
WM_keymap_properties_reset(kmi, NULL);
keymap editor New unique ID per keymap item (unique inside their keymap) for default and configuration keymaps. This allows restoring a single user defined kmi to its previous (default or config) values instead of having to restore the whole keymap. The restore item button is disabled for kmi added by the users (they don't have an ID). Also fixes a bug in the rna function for add keymap item (parameter order was incorrect, messing adding back saved configurations).
2009-12-17 03:32:33 +00:00
}
[#22682] some missing keymaps Added proportional influence up/down to transform modal keymap. Also fixed a crash in restoring to previous key map item after edits.
2010-06-27 23:57:58 +00:00
if (orig->properties) {
kmi->properties= IDP_CopyProperty(orig->properties);
kmi->ptr->data= kmi->properties;
}
keymap editor New unique ID per keymap item (unique inside their keymap) for default and configuration keymaps. This allows restoring a single user defined kmi to its previous (default or config) values instead of having to restore the whole keymap. The restore item button is disabled for kmi added by the users (they don't have an ID). Also fixes a bug in the rna function for add keymap item (parameter order was incorrect, messing adding back saved configurations).
2009-12-17 03:32:33 +00:00
kmi->propvalue = orig->propvalue;
kmi->type = orig->type;
kmi->val = orig->val;
kmi->shift = orig->shift;
kmi->ctrl = orig->ctrl;
kmi->alt = orig->alt;
kmi->oskey = orig->oskey;
kmi->keymodifier = orig->keymodifier;
kmi->maptype = orig->maptype;
}
}
}
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
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
void WM_keymap_restore_to_default(wmKeyMap *keymap)
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
{
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
wmKeyMap *usermap;
RNA functions to find keymaps in a keyconfig (from the usual idname + space or modal keymaps from operator id)
2009-12-08 18:02:50 +00:00
usermap= WM_keymap_list_find(&U.keymaps, keymap->idname, keymap->spaceid, keymap->regionid);
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
if(usermap) {
WM_keymap_free(usermap);
BLI_freelinkN(&U.keymaps, usermap);
}
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
}
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
wmKeyMapItem *WM_keymap_item_find_id(wmKeyMap *keymap, int id)
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
{
wmKeyMapItem *kmi;
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
for (kmi=keymap->items.first; kmi; kmi=kmi->next) {
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
if (kmi->id == id) {
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
return kmi;
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
}
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
}
return NULL;
}
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
/* Guess an appropriate keymap from the operator name */
/* Needs to be kept up to date with Keymap and Operator naming */
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
wmKeyMap *WM_keymap_guess_opname(const bContext *C, const char *opname)
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
{
wmKeyMap *km=NULL;
SpaceLink *sl = CTX_wm_space_data(C);
/* Window */
if (strstr(opname, "WM_OT")) {
km = WM_keymap_find_all(C, "Window", 0, 0);
}
/* Screen */
else if (strstr(opname, "SCREEN_OT")) {
km = WM_keymap_find_all(C, "Screen", 0, 0);
}
/* Grease Pencil */
else if (strstr(opname, "GPENCIL_OT")) {
km = WM_keymap_find_all(C, "Grease Pencil", 0, 0);
}
/* Markers */
else if (strstr(opname, "MARKER_OT")) {
km = WM_keymap_find_all(C, "Markers", 0, 0);
}
/* 3D View */
else if (strstr(opname, "VIEW3D_OT")) {
revert keymap name commit, matt says everything should be '2D View', '3D View...' etc, so for now just go back to what we had. reverse merge: svn merge -r31774:31773 .
2010-09-06 05:40:52 +00:00
km = WM_keymap_find_all(C, "3D View", sl->spacetype, 0);
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
}
else if (strstr(opname, "OBJECT_OT")) {
km = WM_keymap_find_all(C, "Object Mode", 0, 0);
}
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
/* Editing Modes */
else if (strstr(opname, "MESH_OT")) {
km = WM_keymap_find_all(C, "Mesh", 0, 0);
}
else if (strstr(opname, "CURVE_OT")) {
km = WM_keymap_find_all(C, "Curve", 0, 0);
}
else if (strstr(opname, "ARMATURE_OT")) {
km = WM_keymap_find_all(C, "Armature", 0, 0);
}
else if (strstr(opname, "POSE_OT")) {
km = WM_keymap_find_all(C, "Pose", 0, 0);
}
else if (strstr(opname, "SCULPT_OT")) {
km = WM_keymap_find_all(C, "Sculpt", 0, 0);
}
else if (strstr(opname, "MBALL_OT")) {
km = WM_keymap_find_all(C, "Metaball", 0, 0);
}
else if (strstr(opname, "LATTICE_OT")) {
km = WM_keymap_find_all(C, "Lattice", 0, 0);
}
else if (strstr(opname, "PARTICLE_OT")) {
km = WM_keymap_find_all(C, "Particle", 0, 0);
}
else if (strstr(opname, "FONT_OT")) {
km = WM_keymap_find_all(C, "Font", 0, 0);
}
else if (strstr(opname, "PAINT_OT")) {
/* check for relevant mode */
switch(CTX_data_mode_enum(C)) {
case OB_MODE_WEIGHT_PAINT:
km = WM_keymap_find_all(C, "Weight Paint", 0, 0);
break;
case OB_MODE_VERTEX_PAINT:
km = WM_keymap_find_all(C, "Vertex Paint", 0, 0);
break;
case OB_MODE_TEXTURE_PAINT:
km = WM_keymap_find_all(C, "Image Paint", 0, 0);
break;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
}
}
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
/* Paint Face Mask */
else if (strstr(opname, "PAINT_OT_face_select")) {
km = WM_keymap_find_all(C, "Face Mask", sl->spacetype, 0);
}
/* Timeline */
else if (strstr(opname, "TIME_OT")) {
km = WM_keymap_find_all(C, "Timeline", sl->spacetype, 0);
}
/* Image Editor */
else if (strstr(opname, "IMAGE_OT")) {
km = WM_keymap_find_all(C, "Image", sl->spacetype, 0);
}
/* UV Editor */
else if (strstr(opname, "UV_OT")) {
km = WM_keymap_find_all(C, "UV Editor", sl->spacetype, 0);
}
/* Node Editor */
else if (strstr(opname, "NODE_OT")) {
km = WM_keymap_find_all(C, "Node Editor", sl->spacetype, 0);
}
/* Animation Editor Channels */
else if (strstr(opname, "ANIM_OT_channels")) {
km = WM_keymap_find_all(C, "Animation Channels", sl->spacetype, 0);
}
/* Animation Generic - after channels */
else if (strstr(opname, "ANIM_OT")) {
km = WM_keymap_find_all(C, "Animation", 0, 0);
}
/* Graph Editor */
else if (strstr(opname, "GRAPH_OT")) {
km = WM_keymap_find_all(C, "Graph Editor", sl->spacetype, 0);
}
/* Dopesheet Editor */
else if (strstr(opname, "ACTION_OT")) {
km = WM_keymap_find_all(C, "Dopesheet", sl->spacetype, 0);
}
/* NLA Editor */
else if (strstr(opname, "NLA_OT")) {
km = WM_keymap_find_all(C, "NLA Editor", sl->spacetype, 0);
}
/* Script */
else if (strstr(opname, "SCRIPT_OT")) {
km = WM_keymap_find_all(C, "Script", sl->spacetype, 0);
}
/* Text */
else if (strstr(opname, "TEXT_OT")) {
km = WM_keymap_find_all(C, "Text", sl->spacetype, 0);
}
/* Sequencer */
else if (strstr(opname, "SEQUENCER_OT")) {
km = WM_keymap_find_all(C, "Sequencer", sl->spacetype, 0);
}
/* Console */
else if (strstr(opname, "CONSOLE_OT")) {
km = WM_keymap_find_all(C, "Console", sl->spacetype, 0);
}
move report/operator view out of the 'Console' into the 'Info' space (file menu). Ton will work on moving the File menu out of the Info space before release. notes. - reply Operator isn't working anymore. - UI for reports is commented out so its not mixed with the file menu.
2010-11-11 13:36:57 +00:00
/* Console */
else if (strstr(opname, "INFO_OT")) {
km = WM_keymap_find_all(C, "Info", sl->spacetype, 0);
}
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
/* Transform */
else if (strstr(opname, "TRANSFORM_OT")) {
/* check for relevant editor */
switch(sl->spacetype) {
case SPACE_VIEW3D:
revert keymap name commit, matt says everything should be '2D View', '3D View...' etc, so for now just go back to what we had. reverse merge: svn merge -r31774:31773 .
2010-09-06 05:40:52 +00:00
km = WM_keymap_find_all(C, "3D View", sl->spacetype, 0);
Fix [#20798] - Add/change/remove shortcut options dissapearing from buttons @ Tool Shelf Made the RMB menus for manipulating shortcuts a bit more robust (only dealing with mouse clicks/key events, rather than all tweaks/timers/etc) and added ability to add key shortcuts for transform tools from the RMB menu.
2010-01-26 01:02:10 +00:00
break;
case SPACE_IPO:
km = WM_keymap_find_all(C, "Graph Editor", sl->spacetype, 0);
break;
case SPACE_ACTION:
km = WM_keymap_find_all(C, "Dopesheet", sl->spacetype, 0);
break;
case SPACE_NLA:
km = WM_keymap_find_all(C, "NLA Editor", sl->spacetype, 0);
break;
case SPACE_IMAGE:
km = WM_keymap_find_all(C, "UV Editor", sl->spacetype, 0);
break;
case SPACE_NODE:
km = WM_keymap_find_all(C, "Node Editor", sl->spacetype, 0);
break;
case SPACE_SEQ:
km = WM_keymap_find_all(C, "Sequencer", sl->spacetype, 0);
break;
}
}
Key map related things: * Moved 'change shortcut' (previously directly RMB on menu items) to a context-menu item, and added Remove Shortcut and Add Shortcut. This is all available now in a RMB context menu for operator buttons and menu entries. * Renamed a bunch of key maps to be consistent with UI names, and human-readable. Since these key map names are now being directly used in the UI for people to find things, they should be understandable and in plain language. This renaming may break some older saved key map setups - though previously saved .b25.blends should convert over ok. Exported .py files may need some find/replacing - in this commit check the changes in resources.c to see what's changed.
2009-12-24 09:26:06 +00:00
return km;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
}
Copy Permalink