Workspaces: Open Design Questions #50521

New Issue

Julian Eisel · 2017-01-24T20:46:32+01:00

Julian Eisel commented

2017-01-24 20:46:32 +01:00

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?

A proposal:

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.

# 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. ## Workspace Sharing During the 2.8 UI workshop we agreed on having workflow files that would store the workspace definitions: ![Workspaces.jpg](https://archive.blender.org/developer/F439621/Workspaces.jpg) 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? A proposal: * 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: ![customize_UI.png](https://archive.blender.org/developer/F439623/customize_UI.png) ---- 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.

Julian Eisel commented

2017-01-24 20:46:32 +01:00

Changed status to: 'Open'

Julian Eisel commented

2017-01-24 20:46:32 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2017-01-24 20:50:35 +01:00

The questions regarding workspace sharing and multi-window setups are the only ones that are a bit urgent, because they might have quite some influence on D2451. So I'd really appreciate feedback on those.

And sorry for the wall of text, but at this point we have to go into some more details :)

The questions regarding workspace sharing and multi-window setups are the only ones that are a bit urgent, because they might have quite some influence on [D2451](https://archive.blender.org/developer/D2451). So I'd really appreciate feedback on those. And sorry for the wall of text, but at this point we have to go into some more details :)

Vuk Gardašević commented

2017-01-25 04:45:21 +01:00

Added subscriber: @VukGardasevic

Vuk Gardašević commented

2017-01-25 04:45:21 +01:00

This is a small observation, but can the checkboxes for enabling/disabling panels be added at the beginning of the panel before the drop down icon?

Having them at the end is a bit confusing to navigate as their location is dependent on the size of the string for the panel name.
Also having a predefined checkbox icon can visually help identify them (having a specific color at least)?

Anyway i support the idea :)

This is a small observation, but can the checkboxes for enabling/disabling panels be added at the beginning of the panel before the drop down icon? Having them at the end is a bit confusing to navigate as their location is dependent on the size of the string for the panel name. Also having a predefined checkbox icon can visually help identify them (having a specific color at least)? Anyway i support the idea :)

Dalai Felinto commented

2017-01-25 10:29:44 +01:00

Added subscribers: @Sergey, @Ton, @dfelinto

Dalai Felinto commented

2017-01-25 10:29:44 +01:00

We are still a bit unsure how workspaces should work in multi-window setups. (...) Each window can show a different workspace, but it's possible to show the same workspace in multiple windows.

+1. It's also why not go with this and re-evaluate later? @Ton was behind this option too, and I think @Sergey ended up setting for this as well. I fail to see the points against this.

> We are still a bit unsure how workspaces should work in multi-window setups. (...) Each window can show a different workspace, but it's possible to show the same workspace in multiple windows. +1. It's also why not go with this and re-evaluate later? @Ton was behind this option too, and I think @Sergey ended up setting for this as well. I fail to see the points against this.

ronan ducluzeau commented

2017-01-25 11:43:06 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2017-01-25 11:43:06 +01:00

Blender Institute guys suggested to go with the second option.

Each window can show a different workspace, but it's possible to show the same workspace in multiple windows.

+1
We can easily imagine a window for a screen dedicated to inspect result (3DView, Viewer, Preview) for many task.
It will correspond to multiple views engaged in one workflow : so, one workspace.

An generalist artist making a casual and complex task (like a previz animation for example) could combine its regular simpler tasks (3D animation, video editing) without the need to create a specific workspace.
This flexibility will help user to face a bigger task than usual ones without taking too much time to think in depth to another workflow. The balance will stay in user's hands.

About sharing workflows, I think that most options should be in the hands of the provider of the .blend.
Provider of the .blend shares its workflow.
Receiver of the .blend choose to accept it (to conform its future work to this or to learn ) or he does not (because he is only interested by the data).

Mentionned actions are sufficient for loading options to show to receiver. (Load UI, Load Addons, Load Keymaps)
But provider have to define which needed data is necessary to workflow.
If you share a rigged character with the entire community, sharing your workspace with it have absolutely no value.

But if you share a .blend to create robots with a bunch of addons to add and manipulate parametric models; you are sharing your whole workflow. Receiver of the .blend have absolutely no idea which addon is important or not in this workflow.
Enabling of a general modeling addon (like Inset Polygon) can be just a preference of the author of the .blend.
But it will be contained in same workspace as parametric modeling addons written by creator of the .blend.

So, responsability to keep .blend file low size goes to provider of the .blend.
Situation will be a lot more comfortable for receiver; if he does not have to sort what in .blend is just a preference and what is essential.

> Blender Institute guys suggested to go with the second option. > Each window can show a different workspace, but it's possible to show the same workspace in multiple windows. +1 We can easily imagine a window for a screen dedicated to inspect result (3DView, Viewer, Preview) for many task. It will correspond to multiple views engaged in one workflow : so, one workspace. An generalist artist making a casual and complex task (like a previz animation for example) could combine its regular simpler tasks (3D animation, video editing) without the need to create a specific workspace. This flexibility will help user to face a bigger task than usual ones without taking too much time to think in depth to another workflow. The balance will stay in user's hands. About sharing workflows, I think that most options should be in the hands of the provider of the .blend. Provider of the .blend shares its workflow. Receiver of the .blend choose to accept it (to conform its future work to this or to learn ) or he does not (because he is only interested by the data). Mentionned actions are sufficient for loading options to show to receiver. (Load UI, Load Addons, Load Keymaps) But provider have to define which needed data is necessary to workflow. If you share a rigged character with the entire community, sharing your workspace with it have absolutely no value. But if you share a .blend to create robots with a bunch of addons to add and manipulate parametric models; you are sharing your whole workflow. Receiver of the .blend have absolutely no idea which addon is important or not in this workflow. Enabling of a general modeling addon (like Inset Polygon) can be just a preference of the author of the .blend. But it will be contained in same workspace as parametric modeling addons written by creator of the .blend. So, responsability to keep .blend file low size goes to provider of the .blend. Situation will be a lot more comfortable for receiver; if he does not have to sort what in .blend is just a preference and what is essential.

Claus commented

2017-01-25 15:33:34 +01:00

Added subscriber: @Claus

Claus commented

2017-01-25 15:33:34 +01:00

Loading the UI stored in .blends is useful because it makes Blender pretty much ready to go for work with the opened .blend.

This is useful for someone using a computer that he didn't set up and wants to continue work on his own file. It's not useful for passing a file on to someone else because that person would have Blender set up the way he likes already.

I think having some options available when opening a file (for the first time?) would be a good compromise. I propose they should be separated in

Full Interface:
- don't load
- load [default?] (the complete setup of the original file, greying out every sub-element like workspaces, ...)
Workspaces:
- don't load [default] (leave as is)
- load (replace your workspaces with the blend file's workspaces)
- append (add blend file's workspaces to your workspaces)
Add-ons:
- don't load (leave as is !might break functionality)
- load (enabling+disabling and additionally installing original blend file addons)
- append [default] (enable/install addons on top of your own already enabled/installed ones)

The same could be reflected on saving a file. Allowing users to choose what configuration information they save with a file.

> Loading the UI stored in .blends is useful because it makes Blender pretty much ready to go for work with the opened .blend. This is useful for someone using a computer that he didn't set up and wants to continue work on his own file. It's not useful for passing a file on to someone else because that person would have Blender set up the way he likes already. I think having some options available when opening a file (for the first time?) would be a good compromise. I propose they should be separated in - Full Interface: - don't load - load [default?] (the complete setup of the original file, greying out every sub-element like workspaces, ...) - Workspaces: - don't load [default] (leave as is) - load (replace your workspaces with the blend file's workspaces) - append (add blend file's workspaces to your workspaces) - Add-ons: - don't load (leave as is !might break functionality) - load (enabling+disabling and additionally installing original blend file addons) - append [default] (enable/install addons on top of your own already enabled/installed ones) The same could be reflected on saving a file. Allowing users to choose what configuration information they save with a file.

Julian Eisel commented

2017-04-09 23:38:39 +02:00

In #50521#413887, @Claus wrote:

Loading the UI stored in .blends is useful because it makes Blender pretty much ready to go for work with the opened .blend.

This is useful for someone using a computer that he didn't set up and wants to continue work on his own file. It's not useful for passing a file on to someone else because that person would have Blender set up the way he likes already.

Just to name some use-cases:
It's common to save .blends for sharing with a text editor opened, with a text giving all kinds of information about usage of the .blend file. I think that's a pretty useful trick that would be nice to keep working.
Also, when working in the motion tracker, opening a .blend file that contains some 3D scene should move you to a working enviornment setup for the 3D scene, users wouldn't want to stay in the motion tracking environment.

In any case, I've never heard that users don't like the current behavior of loading/storing UI by default. So I don't think we should change that unless there are good reasons.

I think having some options available when opening a file (for the first time?) would be a good compromise. I propose they should be separated in

Full Interface:

don't load

load [default?] (the complete setup of the original file, greying out every sub-element like workspaces, ...)

Workspaces:

don't load [default] (leave as is)

load (replace your workspaces with the blend file's workspaces)

append (add blend file's workspaces to your workspaces)

Thing is that the workspace actually defines the UI setup. Meaning there's effectively no difference between loading the full UI and loading all workspaces.
The option to add workspaces when opening a .blend as opposed to replacing current ones sounds indeed useful. Not a crucial part of the design though, we can keep it in mind and check on it later.

So we would end up with the options to load with/without UI and - when loading with UI - the option to add instead of replacing the workspaces from the read .blend.

@zeauro, @Claus so if I'm not mistaken what you propose agrees pretty much with what I proposed in essence? Basically keeping the option to load with or without UI, but allowing both the creators and the users of a .blend file to define which parts of the workspaces/UI they want to use (only pure UI, add-on preferences, keymap preferences, etc). And you don't disagree with the idea of making the button to add a new workspace spawn a menu showing Duplicate Current and the list of workspaces from the workflow file (stored as part of the user configuration)?
Did I get that right?
If so, I think the remaining question in regards to workspace sharing would be if the Load UI option should be turned on by default.

> In #50521#413887, @Claus wrote: >> Loading the UI stored in .blends is useful because it makes Blender pretty much ready to go for work with the opened .blend. > This is useful for someone using a computer that he didn't set up and wants to continue work on his own file. It's not useful for passing a file on to someone else because that person would have Blender set up the way he likes already. Just to name some use-cases: It's common to save .blends for sharing with a text editor opened, with a text giving all kinds of information about usage of the .blend file. I think that's a pretty useful trick that would be nice to keep working. Also, when working in the motion tracker, opening a .blend file that contains some 3D scene should move you to a working enviornment setup for the 3D scene, users wouldn't want to stay in the motion tracking environment. In any case, I've never heard that users don't like the current behavior of loading/storing UI by default. So I don't think we should change that unless there are good reasons. > I think having some options available when opening a file (for the first time?) would be a good compromise. I propose they should be separated in > > - Full Interface: > - don't load > - load [default?] (the complete setup of the original file, greying out every sub-element like workspaces, ...) > - Workspaces: > - don't load [default] (leave as is) > - load (replace your workspaces with the blend file's workspaces) > - append (add blend file's workspaces to your workspaces) Thing is that the workspace actually defines the UI setup. Meaning there's effectively no difference between loading the full UI and loading all workspaces. The option to add workspaces when opening a .blend as opposed to replacing current ones sounds indeed useful. Not a crucial part of the design though, we can keep it in mind and check on it later. So we would end up with the options to load with/without UI and - when loading with UI - the option to add instead of replacing the workspaces from the read .blend. ---- @zeauro, @Claus so if I'm not mistaken what you propose agrees pretty much with what I proposed in essence? Basically keeping the option to load with or without UI, but allowing both the creators and the users of a .blend file to define which parts of the workspaces/UI they want to use (only pure UI, add-on preferences, keymap preferences, etc). And you don't disagree with the idea of making the button to add a new workspace spawn a menu showing *Duplicate Current* and the list of workspaces from the workflow file (stored as part of the user configuration)? Did I get that right? If so, I think the remaining question in regards to workspace sharing would be if the *Load UI* option should be turned on by default.

JT Nelson commented

2017-04-26 22:23:12 +02:00

Added subscriber: @jta

Albert commented

2017-06-03 23:04:24 +02:00

Added subscriber: @wevon-2

Albert commented

2017-06-03 23:04:24 +02:00

Just a mockup of Property Editor more responsive to the area width.
It involves vertically dividing the editor and setting the visibility of the panels located on the left partition.
Here an animated .gif

Just a mockup of Property Editor more responsive to the area width. It involves vertically dividing the editor and setting the visibility of the panels located on the left partition. Here an animated .gif ![PropertyEditor-Layout.gif](https://archive.blender.org/developer/F617898/PropertyEditor-Layout.gif)

Julian Eisel commented

2020-06-26 19:19:14 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Julian Eisel closed this issue

2020-06-26 19:19:14 +02:00

Julian Eisel self-assigned this 2020-06-26 19:19:14 +02:00

Julian Eisel commented

2020-06-26 19:19:14 +02:00

While not all of this is done (e.g. GUI customization is still missing), most things are. Much has changed in the design meanwhile.

So closing this. Further improvements or additions are possible, but that's regular development and we can create new tasks as needed.

While not all of this is done (e.g. GUI customization is still missing), most things are. Much has changed in the design meanwhile. So closing this. Further improvements or additions are possible, but that's regular development and we can create new tasks as needed.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Workspaces: Open Design Questions #50521

Workspaces: Open Design Questions

Workspace Sharing

Workspaces With Multiple windows

Configuring Workspace Settings (Add-ons & Keymaps)

Configuring Panels, Buttons and Tool-Shelves