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

148 lines
3.9 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"
#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 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
static void keymap_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
}
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 */
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
void WM_keymap_verify_item(ListBase *lb, char *idname, short type, short val, int modifier, short keymodifier)
{
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 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
keymap_set(kmi, type, val, modifier, 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 item was added, then replace */
void WM_keymap_set_item(ListBase *lb, char *idname, short type, short val, int modifier, short keymodifier)
{
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 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
keymap_set(kmi, type, val, modifier, 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
}
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 */
void WM_keymap_add_item(ListBase *lb, char *idname, short type, short val, int modifier, short keymodifier)
{
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 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
keymap_set(kmi, type, val, modifier, 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
/* ****************** 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