Workspaces: Open Design Questions
There are few open question that still need to be figured out for the workspace design:
- How will sharing of workspaces work? (Will they be saved in regular .blends? Will they only be saved in workflow files? ...)
- How should workspaces behave on multi-window setups?
- How would users configure per workspace settings like add-ons and keymaps?
- How would users configure per workspace GUI setups (panels, buttons and tool-shelves)?
- Should we keep Ctrl+Left and Ctrl+Right to cycle through screen-layouts? Should they cycle through workspaces instead?
Below are some details about these questions, including some proposed answers.
During the 2.8 UI workshop we agreed on having workflow files that would store the workspace definitions:https://code.blender.org/wp-content/uploads/2016/12/Workspaces.jpg
That makes it possible to have your workspaces stored as part of your Blender setup, but separate of User Preferences and System Preferences.
But what should happen when opening a file from a different user, who used different workspaces? Would Blender also load these workspaces, or would it just load the non-UI data?
Right now, Blender stores the UI in .blends and gives users the option Load UI which is enabled by default. Loading the UI stored in .blends is useful because it makes Blender pretty much ready to go for work with the opened .blend. If we want to keep supporting this, how should we make it work with the workspaces stored in workflow files?
- Have a single workflow file stored as part of the user's Blender configuration.
- Have a '+' button in the top-bar spawning a list of the workspaces stored in the workflow file. Choosing one appends appends it from the workflow file, including add-on and keymap settings. Of course there would also be the option to create a new workspace by copying the currently active one.
- Saving a regular .blend also saves the workspaces into the .blend.
- Keep the option Load UI which loads the workspaces, screen-layouts and other UI setups (hidden panels, etc) as saved in the .blend, but also have subordinated options Load Workspace Add-ons, Load Workspace Keymaps. Load UI would be enabled by default, others not.
- Allow users to append workspaces with the same options (Load UI, Load Workspace Add-ons, Load Workspace Keymaps)
- The startup configuration remains a regular .blend, meaning it can have a number of workspaces, independent from the ones saved in the workflow file.
To sum it up: The .blend file saving and reading would handle the UI mostly like it does now, but with the option to quickly append custom workspace pre-configurations from the workflow file at any point.
Maybe it should also be possible to copy the add-on and keymap configurations of a workspace to another one.
Note that this topic overlaps with template sharing quite a bit: If a user opens a file that a different user created using the Blender Simplified template, will he/she also load the workspace of the template? With the proposal above it would by default, but when disabling Load UI it wouldn't.
Workspaces With Multiple windows
We are still a bit unsure how workspaces should work in multi-window setups. Basically there are three approaches:
- All windows show the same active workspace (screen-layouts could still be independent).
- Each window can show a different workspace, but it's possible to show the same workspace in multiple windows.
- Each window has to show a different workspace. When copying a window or area into a new window, an independent copy of the active workspace is created. It would match the current behavior of screen-layouts.
Blender Institute guys suggested to go with the second option.
Configuring Workspace Settings (Add-ons & Keymaps)
We want to support storing different add-on and keymap configurations per workspace. This would likely be realized using per workspace overrides. Users would simply override the add-on and keymap settings from the User Preferences.
We still need to figure out how that would actually happen in the UI though. Some ideas:
- Add a Workspace Preference editor, similar to the User Preferences. The top-bar could have a button to open the settings for the current workspace in a separate window.
- Have a button in the top-bar to configure the active workspace. Would open a popup for configuring.
Configuring Panels, Buttons and Tool-Shelves
There are also plans to support hiding of panels and buttons from displaying in the UI and to support customizable tool-shelves. These setups would be per workspace, too. It's still uncertain how users would do this. There were ideas like tagging systems, but a more usable idea might be the 'Configure UI' button:
I think this single task will be enough for now, we can open child-tasks if there's a need for more discussion.
Please ask if things are unclear from available info about workspace plans. Most of their design was discussed during the 2.8 UI workshop, there may be things that are obvious for us, but not for people who haven't attended it.