Per-Workspace viewport shading needs to be an override, not default state

Archive User Feedback
1

As the the title says, the fact that per-workspace shading is something that happens by default is not very well thought through design.

Here’s a typical scenario:
1, You spend quite some time customizing all the viewport shading settings (which have grown quite extensive in 2.8) to your liking.
2, You then decide to try any of the different available workspaces
3, You realize that you will have to manually re-set up all the viewport shading settings, wireframes, overlays, visibility settings, etc… to the same configuration as the workspace you started in, usually layout.
4, You give up on that, and return to your initial workspace, and switch it around for the task you want to do.

The fact that per-workspace viewport shading is mandatory significantly reduces incentive to use the workspaces, for the sole fact that many things need to be re-setup from scratch. It’s the general problem of Blender, constantly duplicating settings instead of unifying. It is the reason that keymap and theme editor both became complex to the point of being nearly impossible manage. It’s understandable since keymap and theme editors both endured decades of chaotic open source development, but it can’t be justified in case of workspaces, which are a new feature implemented during the new, well coordinated 2.8 development.

So, how to solve this:
1, There needs to be global viewport shading settings state
2, Then, user will have a choice to either use this global state in all the workspaces, or manually flip a switch to make the viewport shading settings unique to a given workspace
3, Of course some workspaces can default to have this override enabled, so that for example sculpting workspace can come with the clay matcap
4, At the same time, this global/local override toggle would ensure that if user doesn’t like the changed shading of the workspace, he can toggle it to global one with just a single click, rather than spending minutes configuring all the large amount of the knobs to the same constellation as in his primary workspace.

3 Likes
2

Any news on this? I break my teeth on this every single time I want to use another workspace :frowning: Right now, due to this limitation, workspace tabs are just taking space in the UI without being useful.

3

at the moment since blender is in development and in transition, and often open files that come from 2.79 blender with the old operating structure, I preferred to disable the “loadUI” from the preferences … so for any file I open, I always have my composition of workspaces and configuration of panels that I saved with “save startup file” …

sure, I admit that I miss the old customization of the workspace structure included in the blend files.

I think that the devs must put a check if the files come from 2.79 blender and automatically disable the “loadui” function in case the verification is positive.

said that … I agree with your observations of polishing on the workspaces,
plus ,
having every blend file that respects all the settings of the work interface is a very convenient function.
it was valid in blender 2.79, it is also valid for blender 2.80

4

I don’t think what you are saying is related to my post.

5

man, but how rigid and schematic are you?

off course I did not repeat what you have already explained well

I added suggestions and momentary solutions “to the problem” related to what you said with some enrichment in terms of observation.
I confirmed your intuitions.