tornavis/source/blender/makesdna/DNA_windowmanager_types.h

449 lines
14 KiB
C
Raw Normal View History

/*
* ***** 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,
2010-02-12 14:34:04 +01:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2007 Blender Foundation.
* All rights reserved.
*
*
* Contributor(s): Blender Foundation
*
* ***** END GPL LICENSE BLOCK *****
*/
/** \file DNA_windowmanager_types.h
* \ingroup DNA
*/
#ifndef __DNA_WINDOWMANAGER_TYPES_H__
#define __DNA_WINDOWMANAGER_TYPES_H__
2011-12-30 08:25:49 +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"
#include "DNA_vec_types.h"
Multi-View and Stereo 3D Official Documentation: http://www.blender.org/manual/render/workflows/multiview.html Implemented Features ==================== Builtin Stereo Camera * Convergence Mode * Interocular Distance * Convergence Distance * Pivot Mode Viewport * Cameras * Plane * Volume Compositor * View Switch Node * Image Node Multi-View OpenEXR support Sequencer * Image/Movie Strips 'Use Multiview' UV/Image Editor * Option to see Multi-View images in Stereo-3D or its individual images * Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images I/O * Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images Scene Render Views * Ability to have an arbitrary number of views in the scene Missing Bits ============ First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report. Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report. Everything else is likely small todos, and may wait until we are sure none of the above is happening. Apart from that there are those known issues: * Compositor Image Node poorly working for Multi-View OpenEXR (this was working prefectly before the 'Use Multi-View' functionality) * Selecting camera from Multi-View when looking from camera is problematic * Animation Playback (ctrl+F11) doesn't support stereo formats * Wrong filepath when trying to play back animated scene * Viewport Rendering doesn't support Multi-View * Overscan Rendering * Fullscreen display modes need to warn the user * Object copy should be aware of views suffix Acknowledgments =============== * Francesco Siddi for the help with the original feature specs and design * Brecht Van Lommel for the original review of the code and design early on * Blender Foundation for the Development Fund to support the project wrap up Final patch reviewers: * Antony Riakiotakis (psy-fi) * Campbell Barton (ideasman42) * Julian Eisel (Severin) * Sergey Sharybin (nazgul) * Thomas Dinged (dingto) Code contributors of the original branch in github: * Alexey Akishin * Gabriel Caraballo
2015-04-06 15:40:12 +02:00
#include "DNA_userdef_types.h"
#include "DNA_ID.h"
/* defined here: */
struct wmWindowManager;
struct wmWindow;
struct wmMsgBus;
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;
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;
struct wmKeyConfig;
/* forwards */
struct bContext;
struct bScreen;
struct wmSubWindow;
struct wmTimer;
struct PointerRNA;
struct ReportList;
struct Report;
struct uiLayout;
Multi-View and Stereo 3D Official Documentation: http://www.blender.org/manual/render/workflows/multiview.html Implemented Features ==================== Builtin Stereo Camera * Convergence Mode * Interocular Distance * Convergence Distance * Pivot Mode Viewport * Cameras * Plane * Volume Compositor * View Switch Node * Image Node Multi-View OpenEXR support Sequencer * Image/Movie Strips 'Use Multiview' UV/Image Editor * Option to see Multi-View images in Stereo-3D or its individual images * Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images I/O * Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images Scene Render Views * Ability to have an arbitrary number of views in the scene Missing Bits ============ First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report. Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report. Everything else is likely small todos, and may wait until we are sure none of the above is happening. Apart from that there are those known issues: * Compositor Image Node poorly working for Multi-View OpenEXR (this was working prefectly before the 'Use Multi-View' functionality) * Selecting camera from Multi-View when looking from camera is problematic * Animation Playback (ctrl+F11) doesn't support stereo formats * Wrong filepath when trying to play back animated scene * Viewport Rendering doesn't support Multi-View * Overscan Rendering * Fullscreen display modes need to warn the user * Object copy should be aware of views suffix Acknowledgments =============== * Francesco Siddi for the help with the original feature specs and design * Brecht Van Lommel for the original review of the code and design early on * Blender Foundation for the Development Fund to support the project wrap up Final patch reviewers: * Antony Riakiotakis (psy-fi) * Campbell Barton (ideasman42) * Julian Eisel (Severin) * Sergey Sharybin (nazgul) * Thomas Dinged (dingto) Code contributors of the original branch in github: * Alexey Akishin * Gabriel Caraballo
2015-04-06 15:40:12 +02:00
struct Stereo3dFormat;
struct UndoStep;
#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
/* keep in sync with 'rna_enum_wm_report_items' in wm_rna.c */
typedef enum ReportType {
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),
} ReportType;
#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)
enum ReportListFlags {
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) */
};
/* These two Lines with # tell makesdna this struct can be excluded. */
#
#
typedef struct Report {
struct Report *next, *prev;
short type; /* ReportType */
short flag;
int len; /* strlen(message), saves some time calculating the word wrap */
const char *typestr;
const char *message;
} Report;
2012-03-18 08:38:51 +01:00
/* saved in the wm, don't remove */
typedef struct ReportList {
ListBase list;
int printlevel; /* ReportType */
int storelevel; /* ReportType */
int flag, pad;
struct wmTimer *reporttimer;
} ReportList;
/* timer customdata to control reports display */
/* These two Lines with # tell makesdna this struct can be excluded. */
#
#
typedef struct ReportTimerInfo {
float col[4];
float widthfac;
} ReportTimerInfo;
/* reports need to be before wmWindowManager */
/* windowmanager is saved, tag WMAN */
typedef struct wmWindowManager {
ID id;
struct wmWindow *windrawable, *winactive; /* separate active from drawable */
ListBase windows;
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
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];
struct wmMsgBus *message_bus;
} wmWindowManager;
/* wmWindowManager.initialized */
enum {
WM_WINDOW_IS_INITIALIZED = (1<<0),
WM_KEYCONFIG_IS_INITIALIZED = (1<<1),
};
#define WM_KEYCONFIG_STR_DEFAULT "blender"
/* IME is win32 only! */
#ifndef WIN32
# ifdef __GNUC__
# define ime_data ime_data __attribute__ ((deprecated))
# endif
#endif
/* the saveable part, rest of data is local in ghostwinlay */
typedef struct wmWindow {
struct wmWindow *next, *prev;
void *ghostwin; /* don't want to include ghost.h stuff */
void *gpuctx; /* don't want to include gpu stuff */
struct wmWindow *parent; /* Parent window */
struct Scene *scene; /* Active scene displayed in this window. */
struct Scene *new_scene; /* temporary when switching */
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;
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 */
short grabcursor; /* cursor grab mode */
short addmousemove; /* internal: tag this for extra mousemove event, makes cursors/buttons active on UI switching */
short pad[4];
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 */
struct wmEvent *eventstate; /* storage for event system */
struct wmGesture *tweak; /* internal for wm_operators.c */
/* Input Method Editor data - complex character input (esp. for asian character input)
* Currently WIN32, runtime-only data */
struct wmIMEData *ime_data;
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 */
Multi-View and Stereo 3D Official Documentation: http://www.blender.org/manual/render/workflows/multiview.html Implemented Features ==================== Builtin Stereo Camera * Convergence Mode * Interocular Distance * Convergence Distance * Pivot Mode Viewport * Cameras * Plane * Volume Compositor * View Switch Node * Image Node Multi-View OpenEXR support Sequencer * Image/Movie Strips 'Use Multiview' UV/Image Editor * Option to see Multi-View images in Stereo-3D or its individual images * Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images I/O * Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images Scene Render Views * Ability to have an arbitrary number of views in the scene Missing Bits ============ First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report. Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report. Everything else is likely small todos, and may wait until we are sure none of the above is happening. Apart from that there are those known issues: * Compositor Image Node poorly working for Multi-View OpenEXR (this was working prefectly before the 'Use Multi-View' functionality) * Selecting camera from Multi-View when looking from camera is problematic * Animation Playback (ctrl+F11) doesn't support stereo formats * Wrong filepath when trying to play back animated scene * Viewport Rendering doesn't support Multi-View * Overscan Rendering * Fullscreen display modes need to warn the user * Object copy should be aware of views suffix Acknowledgments =============== * Francesco Siddi for the help with the original feature specs and design * Brecht Van Lommel for the original review of the code and design early on * Blender Foundation for the Development Fund to support the project wrap up Final patch reviewers: * Antony Riakiotakis (psy-fi) * Campbell Barton (ideasman42) * Julian Eisel (Severin) * Sergey Sharybin (nazgul) * Thomas Dinged (dingto) Code contributors of the original branch in github: * Alexey Akishin * Gabriel Caraballo
2015-04-06 15:40:12 +02:00
struct Stereo3dFormat *stereo3d_format; /* properties for stereoscopic displays */
/* custom drawing callbacks */
ListBase drawcalls;
/* Private runtime info to show text in the status bar. */
void *cursor_keymap_status;
} wmWindow;
#ifdef ime_data
# undef ime_data
#endif
/* These two Lines with # tell makesdna this struct can be excluded. */
/* should be something like DNA_EXCLUDE
* but the preprocessor first removes all comments, spaces etc */
#
#
typedef struct wmOperatorTypeMacro {
struct wmOperatorTypeMacro *next, *prev;
/* operator id */
char idname[64];
/* rna pointer to access properties, like keymap */
struct IDProperty *properties; /* operator properties, assigned to ptr->data and can be written to a file */
struct PointerRNA *ptr;
} wmOperatorTypeMacro;
/* partial copy of the event, for matching by eventhandler */
typedef struct wmKeyMapItem {
struct wmKeyMapItem *next, *prev;
/* operator */
char idname[64]; /* used to retrieve operator type pointer */
IDProperty *properties; /* operator properties, assigned to ptr->data and can be written to a file */
/* modal */
char propvalue_str[64]; /* runtime temporary storage for loading */
short propvalue; /* if used, the item is from modal map */
/* event */
short type; /* event code itself */
short val; /* KM_ANY, KM_PRESS, KM_NOTHING etc */
short shift, ctrl, alt, oskey; /* oskey is apple or windowskey, value denotes order of pressed */
short keymodifier; /* rawkey modifier */
/* flag: inactive, expanded */
short flag;
/* runtime */
short maptype; /* keymap editor */
short id; /* unique identifier. Positive for kmi that override builtins, negative otherwise */
short pad;
struct PointerRNA *ptr; /* rna pointer to access properties */
} wmKeyMapItem;
/* used instead of wmKeyMapItem for diff keymaps */
typedef struct wmKeyMapDiffItem {
struct wmKeyMapDiffItem *next, *prev;
wmKeyMapItem *remove_item;
wmKeyMapItem *add_item;
} wmKeyMapDiffItem;
/* wmKeyMapItem.flag */
enum {
KMI_INACTIVE = (1 << 0),
KMI_EXPANDED = (1 << 1),
KMI_USER_MODIFIED = (1 << 2),
KMI_UPDATE = (1 << 3),
};
/* 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,
};
/* stored in WM, the actively used keymaps */
typedef struct wmKeyMap {
struct wmKeyMap *next, *prev;
ListBase items;
ListBase diff_items;
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 */
char owner_id[64]; /* optional, see: #wmOwnerID */
short flag; /* general flags */
short kmi_id; /* last kmi id */
/* runtime */
/** 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 *);
bool (*poll_modal_item)(const struct wmOperator *op, int value);
/** For modal, #EnumPropertyItem for now. */
const void *modal_items;
} wmKeyMap;
/* wmKeyMap.flag */
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),
KEYMAP_TOOL = (1 << 7), /* keymap for active tool system */
};
/**
* This is similar to addon-preferences,
* however unlike add-ons key-config's aren't saved to disk.
*
* #wmKeyConfigPref is written to DNA,
* #wmKeyConfigPrefType_Runtime has the RNA type.
*/
typedef struct wmKeyConfigPref {
struct wmKeyConfigPref *next, *prev;
char idname[64]; /* unique name */
IDProperty *prop;
} wmKeyConfigPref;
typedef struct wmKeyConfig {
struct wmKeyConfig *next, *prev;
char idname[64]; /* unique name */
char basename[64]; /* idname of configuration this is derives from, "" if none */
ListBase keymaps;
int actkeymap;
short flag;
char _pad0[2];
} wmKeyConfig;
/* wmKeyConfig.flag */
enum {
KEYCONF_USER = (1 << 1), /* And what about (1 << 0)? */
KEYCONF_INIT_DEFAULT = (1 << 2), /* Has default keymap been initialized? */
};
/* 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;
/* saved */
char idname[64]; /* used to retrieve type pointer */
IDProperty *properties; /* saved, user-settable properties */
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 */
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 */
struct PointerRNA *ptr; /* rna pointer to access properties */
struct ReportList *reports; /* errors and warnings storage */
ListBase macro; /* list of operators, can be a tree */
struct wmOperator *opm; /* current running macro, not saved */
struct uiLayout *layout; /* runtime for drawing */
short flag, pad[3];
} wmOperator;
/* operator type return flags: exec(), invoke() modal(), return values */
enum {
OPERATOR_RUNNING_MODAL = (1 << 0),
OPERATOR_CANCELLED = (1 << 1),
OPERATOR_FINISHED = (1 << 2),
/* add this flag if the event should pass through */
OPERATOR_PASS_THROUGH = (1 << 3),
/* in case operator got executed outside WM code... like via fileselect */
OPERATOR_HANDLED = (1 << 4),
/* 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),
};
#define OPERATOR_FLAGS_ALL ( \
OPERATOR_RUNNING_MODAL | \
OPERATOR_CANCELLED | \
OPERATOR_FINISHED | \
OPERATOR_PASS_THROUGH | \
OPERATOR_HANDLED | \
OPERATOR_INTERFACE | \
0)
/* sanity checks for debug mode only */
#define OPERATOR_RETVAL_CHECK(ret) (void)ret, BLI_assert(ret != 0 && (ret & OPERATOR_FLAGS_ALL) == ret)
/* wmOperator flag */
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) */
OP_IS_INVOKE = (1 << 0),
/* So we can detect if an operators exec() call is activated from an interactive repeat. */
OP_IS_REPEAT = (1 << 1),
/* When the cursor is grabbed */
OP_IS_MODAL_GRAB_CURSOR = (1 << 2),
/* allow modal operators to have the region under the cursor for their context
* (the regiontype is maintained to prevent errors) */
OP_IS_MODAL_CURSOR_REGION = (1 << 3),
};
#endif /* __DNA_WINDOWMANAGER_TYPES_H__ */