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

170 lines
4.4 KiB
C
Raw Normal View History

Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
/**
* $Id:
*
* ***** BEGIN GPL LICENSE BLOCK *****
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* The Original Code is Copyright (C) 2007 Blender Foundation.
* All rights reserved.
*
*
* Contributor(s): Blender Foundation
*
* ***** END GPL LICENSE BLOCK *****
*/
#include <string.h>
#include "DNA_windowmanager_types.h"
#include "MEM_guardedalloc.h"
#include "BLI_blenlib.h"
#include "BKE_blender.h"
#include "BKE_global.h"
#include "BKE_library.h"
#include "BKE_main.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
#include "RNA_access.h"
#include "RNA_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 "WM_api.h"
#include "WM_types.h"
#include "wm_window.h"
#include "wm_event_system.h"
#include "wm_event_types.h"
/* ***************** generic call, exported **************** */
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
static void keymap_event_set(wmKeymapItem *kmi, short type, short val, int modifier, short keymodifier)
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
{
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
kmi->type= type;
kmi->val= val;
kmi->keymodifier= keymodifier;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
if(modifier & KM_SHIFT)
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->shift= 1;
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
else if(modifier & KM_SHIFT2)
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->shift= 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
if(modifier & KM_CTRL)
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->ctrl= 1;
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
else if(modifier & KM_CTRL2)
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->ctrl= 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
if(modifier & KM_ALT)
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->alt= 1;
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
else if(modifier & KM_ALT2)
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->alt= 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
if(modifier & KM_OSKEY)
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->oskey= 1;
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
else if(modifier & KM_OSKEY2)
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->oskey= 2;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
}
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
static void keymap_properties_set(wmKeymapItem *kmi)
{
wmOperatorType *ot;
if(!kmi->ptr) {
ot= WM_operatortype_find(kmi->idname);
if(ot) {
kmi->ptr= MEM_callocN(sizeof(PointerRNA), "wmKeymapItemPtr");
RNA_pointer_create(NULL, NULL, ot->srna, kmi, kmi->ptr);
}
}
}
Work on gesture, some more cleaning. - Added standard "tweak" gesture operator, which can be set per region, to generate EVT_TWEAK events. You can configure tweaks for any mouse button and have handlers for such events check for modifiers etc. It even stores tweak direction (8 directions). Might be fun to experiment with tweak gestures N, S, etc. :) In general it can be used to replace the current tweak code in 2.48 (std_rmouse_transform). Test added: on screen level it now adds LMB tweaks, if tweak-South it splits the area. Will be removed of course. - Added to Border operator a property to store event used to end border with. - Moved the "AZone" triangle drawing to the right context (area). It was on screen level, not respecting area-redraws. Also cleaned up drawing for it, and moved the "swap buffers indicator" square to look nicer. Those squares are only for test! - event-match function had bad code for checking for event-value. Made a "KM_ANY" define so keymaps can be defined ignoring event values. - Gesture todo: lasso, "real gesture" (like blender now has)
2008-11-24 10:45:36 +00:00
/* if item was added, then bail out */
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
wmKeymapItem *WM_keymap_verify_item(ListBase *lb, char *idname, short type, short val, int modifier, short keymodifier)
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
{
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
wmKeymapItem *kmi;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
for(kmi= lb->first; kmi; kmi= kmi->next)
if(strncmp(kmi->idname, idname, OP_MAX_TYPENAME)==0)
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
break;
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
if(kmi==NULL) {
kmi= MEM_callocN(sizeof(wmKeymapItem), "keymap entry");
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
BLI_addtail(lb, kmi);
BLI_strncpy(kmi->idname, idname, OP_MAX_TYPENAME);
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
keymap_event_set(kmi, type, val, modifier, keymodifier);
keymap_properties_set(kmi);
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
}
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
return kmi;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
}
/* if item was added, then replace */
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
wmKeymapItem *WM_keymap_set_item(ListBase *lb, char *idname, short type, short val, int modifier, short keymodifier)
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
{
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
wmKeymapItem *kmi;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
for(kmi= lb->first; kmi; kmi= kmi->next)
if(strncmp(kmi->idname, idname, OP_MAX_TYPENAME)==0)
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
break;
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
if(kmi==NULL) {
kmi= MEM_callocN(sizeof(wmKeymapItem), "keymap entry");
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
BLI_addtail(lb, kmi);
BLI_strncpy(kmi->idname, idname, OP_MAX_TYPENAME);
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
}
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
keymap_event_set(kmi, type, val, modifier, keymodifier);
keymap_properties_set(kmi);
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
return kmi;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
}
Blender 2.5 project: added first more complex handler + operator - on mouse-over edge, you can drag area borders around. - note it's a handerized system now, so it updates UI while you move mouse. Feedback needed: - read bottom part of the screen_edit.c file. It's the proposed method for adding tools and handlers. I think it's close, but might need some tweaks.
2008-01-10 17:38:17 +00:00
/* always add item */
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
wmKeymapItem *WM_keymap_add_item(ListBase *lb, char *idname, short type, short val, int modifier, short keymodifier)
Blender 2.5 project: added first more complex handler + operator - on mouse-over edge, you can drag area borders around. - note it's a handerized system now, so it updates UI while you move mouse. Feedback needed: - read bottom part of the screen_edit.c file. It's the proposed method for adding tools and handlers. I think it's close, but might need some tweaks.
2008-01-10 17:38:17 +00:00
{
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
wmKeymapItem *kmi= MEM_callocN(sizeof(wmKeymapItem), "keymap entry");
Blender 2.5 project: added first more complex handler + operator - on mouse-over edge, you can drag area borders around. - note it's a handerized system now, so it updates UI while you move mouse. Feedback needed: - read bottom part of the screen_edit.c file. It's the proposed method for adding tools and handlers. I think it's close, but might need some tweaks.
2008-01-10 17:38:17 +00:00
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
BLI_addtail(lb, kmi);
BLI_strncpy(kmi->idname, idname, OP_MAX_TYPENAME);
Blender 2.5 project: added first more complex handler + operator - on mouse-over edge, you can drag area borders around. - note it's a handerized system now, so it updates UI while you move mouse. Feedback needed: - read bottom part of the screen_edit.c file. It's the proposed method for adding tools and handlers. I think it's close, but might need some tweaks.
2008-01-10 17:38:17 +00:00
2.5: added support for setting RNA properties in keymap item, which will then be set when the operator is called, example: kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, 0, 0); RNA_enum_set(kmi->ptr, "dir", 'h'); kmi= WM_keymap_add_item(keymap, "ED_SCR_OT_region_split", SKEY, KM_PRESS, KM_SHIFT, 0); RNA_enum_set(kmi->ptr, "dir", 'v'); There is a hack I had to do here, since properties are defined as member of wmOperator, will try to fix later, committing now so it can be used already.
2008-12-15 13:10:29 +00:00
keymap_event_set(kmi, type, val, modifier, keymodifier);
keymap_properties_set(kmi);
2.5 funtion WM_keymap_add_item() now returns keymap-item, so you can use it to set default properties for operators with WM_keymap_property_set(). Brecht will fill in this function, requires rna magic! Example: an operator ED_OB_OT_add_primitive can be configured with keymap like this: WM_keymap_property_set(keymapitem, "Primitivetype", "Sphere"); Similar conventions we can use later for button/menu calls. This will make creating operators easier, allowing a developer to group tools functionality nicely.
2008-12-15 11:45:17 +00:00
return kmi;
}
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
/* ****************** storage in WM ************ */
/* name id's are for storing general or multiple keymaps,
space/region ids are same as DNA_space_types.h */
/* gets free'd in wm.c */
ListBase *WM_keymap_listbase(wmWindowManager *wm, const char *nameid, int spaceid, int regionid)
{
wmKeyMap *km;
for(km= wm->keymaps.first; km; km= km->next)
if(km->spaceid==spaceid && km->regionid==regionid)
if(0==strncmp(nameid, km->nameid, KMAP_MAX_NAME))
break;
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
if(km==NULL) {
km= MEM_callocN(sizeof(struct wmKeyMap), "keymap list");
BLI_strncpy(km->nameid, nameid, KMAP_MAX_NAME);
km->spaceid= spaceid;
km->regionid= regionid;
printf("added keymap %s %d %d\n", nameid, spaceid, regionid);
BLI_addtail(&wm->keymaps, km);
}
return &km->keymap;
}
Step 3 for the initial commits for 2.5: removing src/ and python, adding new windowmanager module, and the first bits of new editors module.
2007-12-24 18:27:28 +00:00
Copy Permalink