2011-02-17 21:48:12 +01:00
|
|
|
/*
|
2007-12-24 19:53:37 +01: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
|
2018-06-01 18:19:39 +02:00
|
|
|
* of the License, or (at your option) any later version.
|
2007-12-24 19:53:37 +01:00
|
|
|
*
|
|
|
|
* 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,
|
2010-02-12 14:34:04 +01:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2007-12-24 19:53:37 +01:00
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2007 Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2007-12-24 19:53:37 +01:00
|
|
|
* Contributor(s): Blender Foundation
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
2011-02-17 21:48:12 +01:00
|
|
|
/** \file DNA_windowmanager_types.h
|
|
|
|
* \ingroup DNA
|
|
|
|
*/
|
|
|
|
|
2012-02-17 19:59:41 +01:00
|
|
|
#ifndef __DNA_WINDOWMANAGER_TYPES_H__
|
|
|
|
#define __DNA_WINDOWMANAGER_TYPES_H__
|
2011-12-30 08:25:49 +01:00
|
|
|
|
2007-12-24 19:53:37 +01:00
|
|
|
#include "DNA_listBase.h"
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
#include "DNA_screen_types.h"
|
2007-12-24 19:53:37 +01:00
|
|
|
#include "DNA_vec_types.h"
|
2015-04-06 15:40:12 +02:00
|
|
|
#include "DNA_userdef_types.h"
|
2007-12-24 19:53:37 +01:00
|
|
|
|
|
|
|
#include "DNA_ID.h"
|
|
|
|
|
|
|
|
/* defined here: */
|
|
|
|
struct wmWindowManager;
|
|
|
|
struct wmWindow;
|
|
|
|
|
2017-11-13 09:43:34 +01:00
|
|
|
struct wmMsgBus;
|
2007-12-24 19:53:37 +01:00
|
|
|
struct wmEvent;
|
2.5
Sanitized the 'tweak' event.
Original idea was to have WM event system generating it
automatically. However, I first tested it via a handler
and operator, to check what kind of configurations would
be useful. It appeared to not work nice, also because
that inserting a tweak operator in a keymap is confusing.
Now 'tweaks' are generated automatically, and can be
catched by keymaps as any event. The current definition
of tweak is:
- if Left/Middle/Rightmouse pressed
if event wasn't handled by window queue (modal handlers)
start checking mousepositions
- while mousepositions are checked
- escape on any event other than mouse
- on mouse events:
- add tweak event if mousemove > 10 pixels
- stop checking for tweak if mousebutton released
- Tweak events have a define indicating mousebutton used
EVT_TWEAK_L, EVT_TWEAK_M, EVT_TWEAK_R
- In keymap definitions you can use _S or _A to map to
action or select mouse userdef.
- Event value in keymap should be KM_ANY for all tweaks,
or use one of the eight directions:
EVT_GESTURE_E, _SE, _S, _SW, _W, _NW, _N, _NE
- And of course you can add modifier checks in keymaps for it.
- Because tweaks are a result of mouse events, the handlers get
both to evaluate. That means that RMB-select + tweak will work
correctly.
In case you don't want both to be handled, for example the
CTRL+LMB 'extrude' and CTRL+LMB-tweak 'lasso select', you will
need to set the first acting on a EVT_RELEASE, this event only
gets passed on when tweak fails.
The current system allows all options, configurable, we had in 2.48,
and many more! A diagram of what's possible is on the todo. :)
Also in this commit: lasso select editmesh failed with 'zbuffer
occluded select'. Also circle-select failed.
2009-02-02 15:13:14 +01:00
|
|
|
struct wmGesture;
|
2007-12-24 19:53:37 +01:00
|
|
|
struct wmOperatorType;
|
|
|
|
struct wmOperator;
|
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 13:03:07 +02:00
|
|
|
struct wmKeyMap;
|
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 20:40:03 +02:00
|
|
|
struct wmKeyConfig;
|
2007-12-24 19:53:37 +01:00
|
|
|
|
|
|
|
/* forwards */
|
|
|
|
struct bContext;
|
|
|
|
struct bScreen;
|
2008-01-01 16:53:38 +01:00
|
|
|
struct wmSubWindow;
|
2008-12-22 13:57:53 +01:00
|
|
|
struct wmTimer;
|
2008-11-21 20:14:38 +01:00
|
|
|
struct PointerRNA;
|
2008-12-29 14:38:08 +01:00
|
|
|
struct ReportList;
|
2009-07-17 00:47:27 +02:00
|
|
|
struct Report;
|
2009-08-16 22:23:34 +02:00
|
|
|
struct uiLayout;
|
2015-04-06 15:40:12 +02:00
|
|
|
struct Stereo3dFormat;
|
2018-03-19 14:17:59 +01:00
|
|
|
struct UndoStep;
|
2009-07-17 00:47:27 +02:00
|
|
|
|
2013-10-15 10:05:57 +02:00
|
|
|
#define OP_MAX_TYPENAME 64
|
|
|
|
#define KMAP_MAX_NAME 64
|
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 13:03:07 +02:00
|
|
|
|
2015-11-23 03:49:52 +01:00
|
|
|
/* keep in sync with 'rna_enum_wm_report_items' in wm_rna.c */
|
2009-07-17 00:47:27 +02:00
|
|
|
typedef enum ReportType {
|
2013-10-15 10:05:57 +02:00
|
|
|
RPT_DEBUG = (1 << 0),
|
|
|
|
RPT_INFO = (1 << 1),
|
|
|
|
RPT_OPERATOR = (1 << 2),
|
|
|
|
RPT_PROPERTY = (1 << 3),
|
|
|
|
RPT_WARNING = (1 << 4),
|
|
|
|
RPT_ERROR = (1 << 5),
|
|
|
|
RPT_ERROR_INVALID_INPUT = (1 << 6),
|
|
|
|
RPT_ERROR_INVALID_CONTEXT = (1 << 7),
|
|
|
|
RPT_ERROR_OUT_OF_MEMORY = (1 << 8),
|
2009-07-17 00:47:27 +02:00
|
|
|
} ReportType;
|
|
|
|
|
2013-10-15 10:05:57 +02:00
|
|
|
#define RPT_DEBUG_ALL (RPT_DEBUG)
|
|
|
|
#define RPT_INFO_ALL (RPT_INFO)
|
|
|
|
#define RPT_OPERATOR_ALL (RPT_OPERATOR)
|
|
|
|
#define RPT_PROPERTY_ALL (RPT_PROPERTY)
|
|
|
|
#define RPT_WARNING_ALL (RPT_WARNING)
|
|
|
|
#define RPT_ERROR_ALL (RPT_ERROR|RPT_ERROR_INVALID_INPUT|RPT_ERROR_INVALID_CONTEXT|RPT_ERROR_OUT_OF_MEMORY)
|
2009-07-17 00:47:27 +02:00
|
|
|
|
|
|
|
enum ReportListFlags {
|
2013-10-15 10:05:57 +02:00
|
|
|
RPT_PRINT = (1 << 0),
|
|
|
|
RPT_STORE = (1 << 1),
|
|
|
|
RPT_FREE = (1 << 2),
|
|
|
|
RPT_OP_HOLD = (1 << 3), /* don't move them into the operator global list (caller will use) */
|
2009-07-17 00:47:27 +02:00
|
|
|
};
|
2013-10-15 10:05:57 +02:00
|
|
|
|
|
|
|
/* These two Lines with # tell makesdna this struct can be excluded. */
|
2010-10-01 17:59:34 +02:00
|
|
|
#
|
|
|
|
#
|
2009-07-17 00:47:27 +02:00
|
|
|
typedef struct Report {
|
|
|
|
struct Report *next, *prev;
|
2013-10-15 10:05:57 +02:00
|
|
|
short type; /* ReportType */
|
2009-07-19 02:49:44 +02:00
|
|
|
short flag;
|
2013-10-15 10:05:57 +02:00
|
|
|
int len; /* strlen(message), saves some time calculating the word wrap */
|
2010-12-03 18:05:21 +01:00
|
|
|
const char *typestr;
|
|
|
|
const char *message;
|
2009-07-17 00:47:27 +02:00
|
|
|
} Report;
|
2010-10-01 17:59:34 +02:00
|
|
|
|
2012-03-18 08:38:51 +01:00
|
|
|
/* saved in the wm, don't remove */
|
2009-07-17 00:47:27 +02:00
|
|
|
typedef struct ReportList {
|
|
|
|
ListBase list;
|
2013-10-15 10:05:57 +02:00
|
|
|
int printlevel; /* ReportType */
|
|
|
|
int storelevel; /* ReportType */
|
2009-07-17 00:47:27 +02:00
|
|
|
int flag, pad;
|
2010-06-03 09:27:55 +02:00
|
|
|
struct wmTimer *reporttimer;
|
2009-07-17 00:47:27 +02:00
|
|
|
} ReportList;
|
2010-06-03 09:27:55 +02:00
|
|
|
|
|
|
|
/* timer customdata to control reports display */
|
2013-10-15 10:05:57 +02:00
|
|
|
/* These two Lines with # tell makesdna this struct can be excluded. */
|
2010-10-01 17:59:34 +02:00
|
|
|
#
|
|
|
|
#
|
2010-06-03 09:27:55 +02:00
|
|
|
typedef struct ReportTimerInfo {
|
2018-10-19 17:14:27 +02:00
|
|
|
float col[4];
|
2010-06-03 09:27:55 +02:00
|
|
|
float widthfac;
|
|
|
|
} ReportTimerInfo;
|
|
|
|
|
2009-07-17 00:47:27 +02:00
|
|
|
/* reports need to be before wmWindowManager */
|
|
|
|
|
2007-12-24 19:53:37 +01:00
|
|
|
|
|
|
|
/* windowmanager is saved, tag WMAN */
|
|
|
|
typedef struct wmWindowManager {
|
|
|
|
ID id;
|
2013-10-15 10:05:57 +02:00
|
|
|
|
|
|
|
struct wmWindow *windrawable, *winactive; /* separate active from drawable */
|
2007-12-24 19:53:37 +01:00
|
|
|
ListBase windows;
|
2013-10-15 10:05:57 +02:00
|
|
|
|
|
|
|
int initialized; /* set on file read */
|
|
|
|
short file_saved; /* indicator whether data was saved */
|
|
|
|
short op_undo_depth; /* operator stack depth to avoid nested undo pushes */
|
|
|
|
|
|
|
|
ListBase operators; /* operator registry */
|
|
|
|
|
|
|
|
ListBase queue; /* refresh/redraw wmNotifier structs */
|
|
|
|
|
|
|
|
struct ReportList reports; /* information and error reports */
|
|
|
|
|
|
|
|
ListBase jobs; /* threaded jobs manager */
|
|
|
|
|
|
|
|
ListBase paintcursors; /* extra overlay cursors to draw, like circles */
|
|
|
|
|
|
|
|
ListBase drags; /* active dragged items */
|
|
|
|
|
|
|
|
ListBase keyconfigs; /* known key configurations */
|
|
|
|
struct wmKeyConfig *defaultconf; /* default configuration */
|
|
|
|
struct wmKeyConfig *addonconf; /* addon configuration */
|
|
|
|
struct wmKeyConfig *userconf; /* user configuration */
|
|
|
|
|
|
|
|
ListBase timers; /* active timers */
|
|
|
|
struct wmTimer *autosavetimer; /* timer for auto save */
|
Option to lock the interface while rendering
Added function called WM_set_locked_interface which does
two things:
- Prevents event queue from being handled, so no operators
(see below) or values are even possible to run or change.
This prevents any kind of "destructive" action performed
from user while rendering.
- Locks interface refresh for regions which does have lock
set to truth in their template. Currently it's just a 3D
viewport, but in the future more regions could be considered
unsafe, or we could want to lock different parts of
interface when doing different jobs.
This is needed because 3D viewport could be using or changing
the same data as renderer currently uses, leading to threading
conflict.
Notifiers are still allowed to handle, so render progress is
seen on the screen, but would need to doublecheck on this, in
terms some notifiers could be changing the data.
For now interface locking happens for render job only in case
"Lock Interface" checkbox is enabled.
Other tools like backing would also benefit of this option.
It is possible to mark operator as safe to be used in locked
interface mode by adding OPTYPE_ALLOW_LOCKED bit to operator
template flags.
This bit is completely handled by wm_evem_system, not
with operator run routines, so it's still possible to
run operators from drivers and handlers.
Currently allowed image editor navigation and zooming.
Reviewers: brecht, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D142
2014-01-29 11:07:14 +01:00
|
|
|
|
2018-03-19 14:17:59 +01:00
|
|
|
struct UndoStack *undo_stack; /* all undo history (runtime only). */
|
|
|
|
|
Option to lock the interface while rendering
Added function called WM_set_locked_interface which does
two things:
- Prevents event queue from being handled, so no operators
(see below) or values are even possible to run or change.
This prevents any kind of "destructive" action performed
from user while rendering.
- Locks interface refresh for regions which does have lock
set to truth in their template. Currently it's just a 3D
viewport, but in the future more regions could be considered
unsafe, or we could want to lock different parts of
interface when doing different jobs.
This is needed because 3D viewport could be using or changing
the same data as renderer currently uses, leading to threading
conflict.
Notifiers are still allowed to handle, so render progress is
seen on the screen, but would need to doublecheck on this, in
terms some notifiers could be changing the data.
For now interface locking happens for render job only in case
"Lock Interface" checkbox is enabled.
Other tools like backing would also benefit of this option.
It is possible to mark operator as safe to be used in locked
interface mode by adding OPTYPE_ALLOW_LOCKED bit to operator
template flags.
This bit is completely handled by wm_evem_system, not
with operator run routines, so it's still possible to
run operators from drivers and handlers.
Currently allowed image editor navigation and zooming.
Reviewers: brecht, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D142
2014-01-29 11:07:14 +01:00
|
|
|
char is_interface_locked; /* indicates whether interface is locked for user interaction */
|
|
|
|
char par[7];
|
2017-11-13 09:43:34 +01:00
|
|
|
|
|
|
|
struct wmMsgBus *message_bus;
|
|
|
|
|
2007-12-24 19:53:37 +01:00
|
|
|
} wmWindowManager;
|
|
|
|
|
2009-07-18 21:40:26 +02:00
|
|
|
/* wmWindowManager.initialized */
|
2013-10-15 10:05:57 +02:00
|
|
|
enum {
|
2017-11-09 04:57:14 +01:00
|
|
|
WM_WINDOW_IS_INITIALIZED = (1<<0),
|
2018-11-13 19:02:12 +01:00
|
|
|
WM_KEYCONFIG_IS_INITIALIZED = (1<<1),
|
2013-10-15 10:05:57 +02:00
|
|
|
};
|
2007-12-24 19:53:37 +01:00
|
|
|
|
2018-11-19 03:16:18 +01:00
|
|
|
#define WM_KEYCONFIG_STR_DEFAULT "blender"
|
|
|
|
|
2014-12-07 00:58:17 +01:00
|
|
|
/* IME is win32 only! */
|
|
|
|
#ifndef WIN32
|
|
|
|
# ifdef __GNUC__
|
|
|
|
# define ime_data ime_data __attribute__ ((deprecated))
|
|
|
|
# endif
|
|
|
|
#endif
|
|
|
|
|
2018-09-24 17:27:41 +02:00
|
|
|
/* the saveable part, rest of data is local in ghostwinlay */
|
2007-12-24 19:53:37 +01:00
|
|
|
typedef struct wmWindow {
|
|
|
|
struct wmWindow *next, *prev;
|
2009-12-07 19:05:51 +01:00
|
|
|
|
2013-10-15 10:05:57 +02:00
|
|
|
void *ghostwin; /* don't want to include ghost.h stuff */
|
2018-07-18 00:12:21 +02:00
|
|
|
void *gpuctx; /* don't want to include gpu stuff */
|
2013-10-15 10:05:57 +02:00
|
|
|
|
2018-07-03 15:34:26 +02:00
|
|
|
struct wmWindow *parent; /* Parent window */
|
|
|
|
|
2018-07-04 13:00:46 +02:00
|
|
|
struct Scene *scene; /* Active scene displayed in this window. */
|
2018-07-03 15:34:26 +02:00
|
|
|
struct Scene *new_scene; /* temporary when switching */
|
2018-07-04 13:00:46 +02:00
|
|
|
char view_layer_name[64]; /* Active view layer displayed in this window. */
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
|
|
|
|
struct WorkSpaceInstanceHook *workspace_hook;
|
|
|
|
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
/** Global areas aren't part of the screen, but part of the window directly.
|
|
|
|
* \note Code assumes global areas with fixed height, fixed width not supported yet */
|
|
|
|
ScrAreaMap global_areas;
|
|
|
|
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
struct bScreen *screen DNA_DEPRECATED;
|
2013-10-15 10:05:57 +02:00
|
|
|
|
|
|
|
short posx, posy, sizex, sizey; /* window coords */
|
|
|
|
short windowstate; /* borderless, full */
|
|
|
|
short monitor; /* multiscreen... no idea how to store yet */
|
|
|
|
short active; /* set to 1 if an active window, for quick rejects */
|
|
|
|
short cursor; /* current mouse cursor type */
|
|
|
|
short lastcursor; /* previous cursor when setting modal one */
|
|
|
|
short modalcursor; /* the current modal cursor */
|
2014-10-10 19:13:40 +02:00
|
|
|
short grabcursor; /* cursor grab mode */
|
2013-10-15 10:05:57 +02:00
|
|
|
short addmousemove; /* internal: tag this for extra mousemove event, makes cursors/buttons active on UI switching */
|
2018-02-13 19:15:34 +01:00
|
|
|
short pad[4];
|
2014-10-10 19:13:40 +02:00
|
|
|
|
|
|
|
int winid; /* winid also in screens, is for retrieving this window after read */
|
|
|
|
|
|
|
|
short lock_pie_event; /* internal, lock pie creation from this event until released */
|
|
|
|
short last_pie_event; /* exception to the above rule for nested pies, store last pie event for operators
|
|
|
|
* that spawn a new pie right after destruction of last pie */
|
2009-11-23 17:24:28 +01:00
|
|
|
|
2013-10-15 10:05:57 +02:00
|
|
|
struct wmEvent *eventstate; /* storage for event system */
|
|
|
|
|
|
|
|
struct wmGesture *tweak; /* internal for wm_operators.c */
|
|
|
|
|
2014-12-07 00:58:17 +01:00
|
|
|
/* Input Method Editor data - complex character input (esp. for asian character input)
|
|
|
|
* Currently WIN32, runtime-only data */
|
|
|
|
struct wmIMEData *ime_data;
|
|
|
|
|
2013-10-15 10:05:57 +02:00
|
|
|
ListBase queue; /* all events (ghost level events were handled) */
|
|
|
|
ListBase handlers; /* window+screen handlers, handled last */
|
|
|
|
ListBase modalhandlers; /* priority handlers, handled first */
|
|
|
|
|
|
|
|
ListBase gesture; /* gesture stuff */
|
2015-04-06 15:40:12 +02:00
|
|
|
|
|
|
|
struct Stereo3dFormat *stereo3d_format; /* properties for stereoscopic displays */
|
2018-01-19 07:14:27 +01:00
|
|
|
|
|
|
|
/* custom drawing callbacks */
|
|
|
|
ListBase drawcalls;
|
2018-06-26 12:18:54 +02:00
|
|
|
|
|
|
|
/* Private runtime info to show text in the status bar. */
|
|
|
|
void *cursor_keymap_status;
|
2007-12-24 19:53:37 +01:00
|
|
|
} wmWindow;
|
|
|
|
|
2014-12-07 00:58:17 +01:00
|
|
|
#ifdef ime_data
|
|
|
|
# undef ime_data
|
|
|
|
#endif
|
|
|
|
|
2013-10-15 10:05:57 +02:00
|
|
|
/* These two Lines with # tell makesdna this struct can be excluded. */
|
2018-06-17 17:04:09 +02:00
|
|
|
/* should be something like DNA_EXCLUDE
|
2009-02-15 14:53:26 +01:00
|
|
|
* but the preprocessor first removes all comments, spaces etc */
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 19:56:38 +02:00
|
|
|
#
|
|
|
|
#
|
|
|
|
typedef struct wmOperatorTypeMacro {
|
|
|
|
struct wmOperatorTypeMacro *next, *prev;
|
2009-12-24 17:10:26 +01:00
|
|
|
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 19:56:38 +02:00
|
|
|
/* operator id */
|
2010-01-05 21:18:45 +01:00
|
|
|
char idname[64];
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 19:56:38 +02:00
|
|
|
/* rna pointer to access properties, like keymap */
|
2013-10-15 10:05:57 +02:00
|
|
|
struct IDProperty *properties; /* operator properties, assigned to ptr->data and can be written to a file */
|
2009-12-24 17:10:26 +01:00
|
|
|
struct PointerRNA *ptr;
|
2.5
Operator goodies!
--- Macro operators
Operators now can consist of multiple operators. Such a macro operator
is identical and behaves identical to other opererators. Macros can
also be constructed of macros even! Currently only hardcoded macros are
implemented, this to solve combined operators such as 'add duplicate' or
'extrude' (both want a transform appended).
Usage is simple:
- WM_operatortype_append_macro() : add new operatortype, name, flags
- WM_operatortype_macro_define() : add existing operator to macro
(Note: macro_define will also allow properties to be set, doesnt work
right now)
On converting the macro wmOperatorType to a real operator, it makes a
list of all operators, and the standard macro callbacks (exec, invoke,
modal, poll) just will use all.
Important note; switching to a modal operator only works as last in the
chain now!
Macros implemented for duplicate, extrude and rip. Tool menu works fine
for it, also the redo hotkey F4 works properly.
--- Operator redo fix
The operators use the undo system to switch back, but this could give
errors if other actions added undo pushes (buttons, outliner). Now the
redo for operator searches back for the correct undo level.
This fixes issues with many redos.
Note for brecht: removed the ED_undo_push for buttons... it was called
on *every* button now, which is probably too much? For example, using
the 'toolbar' redo also caused this...
2009-07-29 19:56:38 +02:00
|
|
|
} wmOperatorTypeMacro;
|
|
|
|
|
2007-12-24 19:53:37 +01:00
|
|
|
/* partial copy of the event, for matching by eventhandler */
|
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 20:40:03 +02:00
|
|
|
typedef struct wmKeyMapItem {
|
|
|
|
struct wmKeyMapItem *next, *prev;
|
2013-10-15 10:05:57 +02: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 20:40:03 +02:00
|
|
|
/* operator */
|
2013-10-15 10:05:57 +02:00
|
|
|
char idname[64]; /* used to retrieve operator type pointer */
|
|
|
|
IDProperty *properties; /* operator properties, assigned to ptr->data and can be written to a file */
|
|
|
|
|
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 20:40:03 +02:00
|
|
|
/* modal */
|
2013-10-15 10:05:57 +02:00
|
|
|
char propvalue_str[64]; /* runtime temporary storage for loading */
|
|
|
|
short propvalue; /* if used, the item is from modal map */
|
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 20:40:03 +02:00
|
|
|
|
|
|
|
/* event */
|
2013-10-15 10:05:57 +02:00
|
|
|
short type; /* event code itself */
|
2015-04-07 14:08:30 +02:00
|
|
|
short val; /* KM_ANY, KM_PRESS, KM_NOTHING etc */
|
2013-10-15 10:05:57 +02:00
|
|
|
short shift, ctrl, alt, oskey; /* oskey is apple or windowskey, value denotes order of pressed */
|
|
|
|
short keymodifier; /* rawkey modifier */
|
|
|
|
|
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 20:40:03 +02:00
|
|
|
/* flag: inactive, expanded */
|
|
|
|
short flag;
|
2007-12-24 19:53:37 +01: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 20:40:03 +02:00
|
|
|
/* runtime */
|
2013-10-15 10:05:57 +02:00
|
|
|
short maptype; /* keymap editor */
|
|
|
|
short id; /* unique identifier. Positive for kmi that override builtins, negative otherwise */
|
2009-12-17 04:32:33 +01:00
|
|
|
short pad;
|
2013-10-15 10:05:57 +02:00
|
|
|
struct PointerRNA *ptr; /* rna pointer to access properties */
|
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 20:40:03 +02:00
|
|
|
} wmKeyMapItem;
|
|
|
|
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 22:45:26 +02:00
|
|
|
/* used instead of wmKeyMapItem for diff keymaps */
|
|
|
|
typedef struct wmKeyMapDiffItem {
|
|
|
|
struct wmKeyMapDiffItem *next, *prev;
|
|
|
|
|
|
|
|
wmKeyMapItem *remove_item;
|
|
|
|
wmKeyMapItem *add_item;
|
|
|
|
} wmKeyMapDiffItem;
|
|
|
|
|
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 20:40:03 +02:00
|
|
|
/* wmKeyMapItem.flag */
|
2013-10-15 10:05:57 +02:00
|
|
|
enum {
|
|
|
|
KMI_INACTIVE = (1 << 0),
|
|
|
|
KMI_EXPANDED = (1 << 1),
|
|
|
|
KMI_USER_MODIFIED = (1 << 2),
|
|
|
|
KMI_UPDATE = (1 << 3),
|
|
|
|
};
|
2008-12-08 16:02:57 +01:00
|
|
|
|
2013-10-15 15:55:06 +02:00
|
|
|
/* wmKeyMapItem.maptype */
|
|
|
|
enum {
|
|
|
|
KMI_TYPE_KEYBOARD = 0,
|
|
|
|
KMI_TYPE_MOUSE = 1,
|
|
|
|
KMI_TYPE_TWEAK = 2,
|
|
|
|
KMI_TYPE_TEXTINPUT = 3,
|
|
|
|
KMI_TYPE_TIMER = 4,
|
|
|
|
KMI_TYPE_NDOF = 5,
|
|
|
|
};
|
|
|
|
|
2008-12-08 16:02:57 +01:00
|
|
|
/* stored in WM, the actively used keymaps */
|
|
|
|
typedef struct wmKeyMap {
|
|
|
|
struct wmKeyMap *next, *prev;
|
2013-10-15 10:05:57 +02: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 20:40:03 +02:00
|
|
|
ListBase items;
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 22:45:26 +02:00
|
|
|
ListBase diff_items;
|
2013-10-15 10:05:57 +02:00
|
|
|
|
|
|
|
char idname[64]; /* global editor keymaps, or for more per space/region */
|
|
|
|
short spaceid; /* same IDs as in DNA_space_types.h */
|
|
|
|
short regionid; /* see above */
|
2018-02-28 15:26:02 +01:00
|
|
|
char owner_id[64]; /* optional, see: #wmOwnerID */
|
2013-10-15 10:05:57 +02:00
|
|
|
|
|
|
|
short flag; /* general flags */
|
|
|
|
short kmi_id; /* last kmi 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 20:40:03 +02:00
|
|
|
/* runtime */
|
2018-02-23 02:50:56 +01:00
|
|
|
/** Verify if enabled in the current context, use #WM_keymap_poll instead of direct calls. */
|
2018-07-02 11:47:00 +02:00
|
|
|
bool (*poll)(struct bContext *);
|
2018-07-09 08:39:09 +02:00
|
|
|
bool (*poll_modal_item)(const struct wmOperator *op, int value);
|
|
|
|
|
2018-02-23 02:50:56 +01:00
|
|
|
/** For modal, #EnumPropertyItem for now. */
|
|
|
|
const void *modal_items;
|
2008-12-08 16:02:57 +01:00
|
|
|
} wmKeyMap;
|
|
|
|
|
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 20:40:03 +02:00
|
|
|
/* wmKeyMap.flag */
|
2013-10-15 10:05:57 +02:00
|
|
|
enum {
|
|
|
|
KEYMAP_MODAL = (1 << 0), /* modal map, not using operatornames */
|
|
|
|
KEYMAP_USER = (1 << 1), /* user keymap */
|
|
|
|
KEYMAP_EXPANDED = (1 << 2),
|
|
|
|
KEYMAP_CHILDREN_EXPANDED = (1 << 3),
|
|
|
|
KEYMAP_DIFF = (1 << 4), /* diff keymap for user preferences */
|
|
|
|
KEYMAP_USER_MODIFIED = (1 << 5), /* keymap has user modifications */
|
|
|
|
KEYMAP_UPDATE = (1 << 6),
|
2018-11-13 21:01:32 +01:00
|
|
|
KEYMAP_TOOL = (1 << 7), /* keymap for active tool system */
|
2013-10-15 10:05:57 +02: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 20:40:03 +02:00
|
|
|
|
2018-11-16 01:24:49 +01:00
|
|
|
/**
|
|
|
|
* This is similar to addon-preferences,
|
|
|
|
* however unlike add-ons key-config's aren't saved to disk.
|
|
|
|
*
|
2018-11-18 20:14:20 +01:00
|
|
|
* #wmKeyConfigPref is written to DNA,
|
2018-11-16 01:24:49 +01:00
|
|
|
* #wmKeyConfigPrefType_Runtime has the RNA type.
|
|
|
|
*/
|
2018-11-18 20:14:20 +01:00
|
|
|
typedef struct wmKeyConfigPref {
|
|
|
|
struct wmKeyConfigPref *next, *prev;
|
2018-11-16 01:24:49 +01:00
|
|
|
char idname[64]; /* unique name */
|
|
|
|
IDProperty *prop;
|
2018-11-18 20:14:20 +01:00
|
|
|
} wmKeyConfigPref;
|
2018-11-16 01:24:49 +01: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 20:40:03 +02:00
|
|
|
typedef struct wmKeyConfig {
|
|
|
|
struct wmKeyConfig *next, *prev;
|
|
|
|
|
2013-10-15 10:05:57 +02:00
|
|
|
char idname[64]; /* unique name */
|
|
|
|
char basename[64]; /* idname of configuration this is derives from, "" if none */
|
|
|
|
|
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 20:40:03 +02:00
|
|
|
ListBase keymaps;
|
2018-11-15 22:28:58 +01:00
|
|
|
int actkeymap;
|
|
|
|
short flag;
|
2018-11-18 20:14:20 +01:00
|
|
|
char _pad0[2];
|
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 20:40:03 +02:00
|
|
|
} wmKeyConfig;
|
|
|
|
|
|
|
|
/* wmKeyConfig.flag */
|
2013-10-15 10:05:57 +02:00
|
|
|
enum {
|
|
|
|
KEYCONF_USER = (1 << 1), /* And what about (1 << 0)? */
|
2018-11-15 22:28:58 +01:00
|
|
|
KEYCONF_INIT_DEFAULT = (1 << 2), /* Has default keymap been initialized? */
|
2013-10-15 10:05:57 +02:00
|
|
|
};
|
2007-12-24 19:53:37 +01:00
|
|
|
|
|
|
|
/* this one is the operator itself, stored in files for macros etc */
|
|
|
|
/* operator + operatortype should be able to redo entirely, but for different contextes */
|
|
|
|
typedef struct wmOperator {
|
|
|
|
struct wmOperator *next, *prev;
|
|
|
|
|
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 14:10:29 +01:00
|
|
|
/* saved */
|
2013-10-15 10:05:57 +02:00
|
|
|
char idname[64]; /* used to retrieve type pointer */
|
|
|
|
IDProperty *properties; /* saved, user-settable properties */
|
2009-12-24 17:10:26 +01:00
|
|
|
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 16:18:21 +01:00
|
|
|
/* runtime */
|
2013-10-15 10:05:57 +02:00
|
|
|
struct wmOperatorType *type; /* operator type definition from idname */
|
|
|
|
void *customdata; /* custom storage, only while operator runs */
|
|
|
|
void *py_instance; /* python stores the class instance here */
|
2009-12-24 17:10:26 +01:00
|
|
|
|
2013-10-15 10:05:57 +02:00
|
|
|
struct PointerRNA *ptr; /* rna pointer to access properties */
|
|
|
|
struct ReportList *reports; /* errors and warnings storage */
|
2009-12-24 17:10:26 +01:00
|
|
|
|
2013-10-15 10:05:57 +02:00
|
|
|
ListBase macro; /* list of operators, can be a tree */
|
|
|
|
struct wmOperator *opm; /* current running macro, not saved */
|
|
|
|
struct uiLayout *layout; /* runtime for drawing */
|
2009-09-04 00:37:09 +02:00
|
|
|
short flag, pad[3];
|
2007-12-24 19:53:37 +01:00
|
|
|
} wmOperator;
|
|
|
|
|
2011-08-25 18:42:42 +02:00
|
|
|
/* operator type return flags: exec(), invoke() modal(), return values */
|
2013-10-15 10:05:57 +02:00
|
|
|
enum {
|
|
|
|
OPERATOR_RUNNING_MODAL = (1 << 0),
|
|
|
|
OPERATOR_CANCELLED = (1 << 1),
|
|
|
|
OPERATOR_FINISHED = (1 << 2),
|
2014-10-28 17:51:06 +01:00
|
|
|
/* add this flag if the event should pass through */
|
2013-10-15 10:05:57 +02:00
|
|
|
OPERATOR_PASS_THROUGH = (1 << 3),
|
2014-10-28 17:51:06 +01:00
|
|
|
/* in case operator got executed outside WM code... like via fileselect */
|
2013-10-15 10:05:57 +02:00
|
|
|
OPERATOR_HANDLED = (1 << 4),
|
2014-10-28 17:51:06 +01:00
|
|
|
/* used for operators that act indirectly (eg. popup menu)
|
|
|
|
* note: this isn't great design (using operators to trigger UI) avoid where possible. */
|
|
|
|
OPERATOR_INTERFACE = (1 << 5),
|
2013-10-15 10:05:57 +02:00
|
|
|
};
|
2014-10-28 17:51:06 +01:00
|
|
|
#define OPERATOR_FLAGS_ALL ( \
|
|
|
|
OPERATOR_RUNNING_MODAL | \
|
|
|
|
OPERATOR_CANCELLED | \
|
|
|
|
OPERATOR_FINISHED | \
|
|
|
|
OPERATOR_PASS_THROUGH | \
|
|
|
|
OPERATOR_HANDLED | \
|
|
|
|
OPERATOR_INTERFACE | \
|
|
|
|
0)
|
2011-08-25 18:42:42 +02:00
|
|
|
|
|
|
|
/* sanity checks for debug mode only */
|
2012-10-12 01:46:12 +02:00
|
|
|
#define OPERATOR_RETVAL_CHECK(ret) (void)ret, BLI_assert(ret != 0 && (ret & OPERATOR_FLAGS_ALL) == ret)
|
2007-12-24 19:53:37 +01:00
|
|
|
|
2009-09-04 00:37:09 +02:00
|
|
|
/* wmOperator flag */
|
2013-09-16 06:04:44 +02:00
|
|
|
enum {
|
|
|
|
/* low level flag so exec() operators can tell if they were invoked, use with care.
|
|
|
|
* typically this shouldn't make any difference, but it rare cases its needed (see smooth-view) */
|
2015-04-27 10:53:45 +02:00
|
|
|
OP_IS_INVOKE = (1 << 0),
|
2018-01-19 11:07:43 +01:00
|
|
|
/* So we can detect if an operators exec() call is activated from an interactive repeat. */
|
|
|
|
OP_IS_REPEAT = (1 << 1),
|
2015-04-27 10:53:45 +02:00
|
|
|
|
|
|
|
/* When the cursor is grabbed */
|
2018-01-19 11:07:43 +01:00
|
|
|
OP_IS_MODAL_GRAB_CURSOR = (1 << 2),
|
2015-04-27 10:53:45 +02:00
|
|
|
|
|
|
|
/* allow modal operators to have the region under the cursor for their context
|
|
|
|
* (the regiontype is maintained to prevent errors) */
|
2018-01-19 11:07:43 +01:00
|
|
|
OP_IS_MODAL_CURSOR_REGION = (1 << 3),
|
2013-09-16 06:04:44 +02:00
|
|
|
};
|
2009-01-25 08:28:11 +01:00
|
|
|
|
2012-02-17 19:59:41 +01:00
|
|
|
#endif /* __DNA_WINDOWMANAGER_TYPES_H__ */
|