Every time I try to utilize workspaces, I break my teeth on the same problem - workspaces are a scene preference, not software preference. Let’s say I want to improve my workspace layout for shading in the scene I currently work on. If I do that, the change will only propagate to that scene. If I have 20 other scenes I work on, I now have to reproduce the same change, or usually set of changes on 20 different scenes, and then I also need to edit the startup file so that the change is propagated on every newly created file.
In contrast, when using normal software, such as Unreal Engine, workspace layout is software preference, which makes workspaces significantly more useful, as changing them according to the task becomes actually useful. In Blender the fact they are saved within the scene is so discouraging that I see almost no Blender users ever customizing the workspaces or creating their own as they know it’s all usually wasted work.
Therefore what we need is for the workspaces to be global. Not stored within .blend file, but within the blender itself. On top of that, as an extra, non default option, users would have an option to create local workspaces, which are stored within the .blend file. These would be appended to the list of workspace tabs upon opening of the .blend file, and would disappear as soon as the file is closed. Some slight UI separation would be in order to distinguish between global and local workspaces.
The ability to share workspaces across project files was an integral part of the workspace design. Unfortunately, the feature is currently a bit obfuscated, but it’s there.
While workspaces are stored inside project .blends, they can also be stored in the startup.blend of an application template. What that effectively means is that for each template, you can define you’re very own set of workspaces. From the + tab in the top-bar, you can add them to your current project file.
More concretely, to create a workspace that you can access in other project files, launch Blender, create a custom workspace and save the startup file (File > Defaults > Save Startup File). You can then access it from any project file via the + tab:
You can also append workspaces of any .blend file like regular data-blocks:
We are aware that this is still a bit cumbersome, and way to hard to discover. It’s a known TODO item to improve this process but there are other, higher priority tasks to work on first.
Yes, I have mentioned that possibility in my original post, but this does not change much. Still, if I want to change workspace currently, at the time I am working in certain file, I can’t do that. I have to close the file, and update startup.blend, and then I have to load that workspace in any other .blend file where I want to update it. And then if I decide to iterate on that workspace, I again need to do the same process. It just takes so incredibly much time that it ends up just not paying off at all to ever customize workspaces.
The only possible way to use workspaces currently is to try to think of all the future workflow possibilities and decide them ahead of time once and then save that in startup blend file. But this never works in practice. You will want to perform incremental tweaks on the workspace as you learn your needs, and Blender does not allow that.
At least you are aware of it. It’s just the general precendent that needs fixing. That workspaces should be global by default, and optionally local. Right now they are local by default with no option of being global.
It should be easy to add a python script (add-on) to automate this. Say with a “Save Workspace to Startup File” operator. It would save the current file, open the startup.blend, append the workspace (or possibly update an existing one) and save the startup file.
I don’t remember the details, but we do some trickery with UI data when run in background mode. So I’m not sure if this could all be done in background mode. Worth a try though.
Again, there should be a proper way to edit your workspace setup from within the Blender UI. For the time being, you’ll have to live with the non-optimal solution. But all you need should be there.
Yes, I understand. I am not searching a workaround urgently, so I probably won’t spend time making any python shenanigans. This post was more in a tone of that currently workspace customization is so cumbersome it’s just not worth the effort, so i’d like to see them improved so that I can comfortably utilize them on day to day basis, as they would really help my workflow if I did not have to set them up so many times over and over again. So I’ll rather way until (hopefully) official solution shows up instead of trying to hack it on my own.
I just hope it will be truly global, meaning if I change workspace in one file, I won’t have to take any manual steps to recover that workspace in another file.
I don’t know if I completely understood what your problem is, but I just wanted to expose how I adapted in comfort with my custom workspaces letting them be “managed by the software and not by the file” … I simply made sure that the files do not change my workspaces and ui at every start … in doing so it was enough for me to do a save startup file when all the workspaces I thought are optimal …
I actually see your problem here. You want the edits on your current workspace to propagate to all other files you are working on (workspaces stored in the program, not the files). While that is desireable in some cases I also like that Blender is able to save workspaces to a file. It’s a different kind of thinking. Also it’S not as easy to screw up your workspaces once and for all and for all your other files. That’s something I did in Modo more than once and it it was annoying as hell!
Bringing it over to the program side would probably screw up the work for many others. I kinda like @julianeisel’s proposal where an addon is able to propagate it back and forth to a central file. This way would make it a little less immediate to work with as you’d need to load in a file from the main workspace automatically. It would keep the existing compatibility and add another layer for people who work with layouts a lot, on top.
The individual .Blend files should be saved somewhere like the Startup files, maybe.
This would mean that you’d have to hit ‘load’ on a file where you have an old layout in use but it would mean that it’s just the click of a button and would not break logic for existing users.
Maybe you could even throw in an Auto-Load button that updates the workspace based on the name on loading up a new file. That would be a ‘sort of’ global workspace equivalent with the added bonus of having to use it globally on top.
Don’t know if that’s easy to implement, though. I’m also just a user, not a developer.
Yes, just read last paragraph of my original post. I mentioned that local workspaces should still be available, just not default.
Save and Load layout in the header would be really horrible way to go about it. The whole point of this is to remove the hassle of modifying the workspaces, not add it. As long as the process of loading and saving becomes manual, it completely defeats the point.
It should work following way: There should be two rows of tabs. One for global workspaces, then a little separator, and then one for local workspaces. When adding a new workspace, there would be a simple choice if you are adding global workspace or the local workspace. Once you add a global workspace, it’s added to the global workspace tab row, and if you open new, or different file, it will be there. If you add local workspace, it will go to the local workspace tab row, and once you open new or another file, it won’t be there. Simple as that. It makes absolutely no sense to do any manual save/load buttons.
Any workspace added left of the little separator would be global workspace, which would be saved within the Blender itself and immediately available in any new and existing .blend file. Its modification would be always saved as soon as modified like it’s the case with User Preferences.
Any workspace added right of the little separator would be saved within the .blend file and would be available only in that particular file.
So by default, for new files, area right of the separator for local workspaces would usually be empty except the + button to add new local workspace.
I like the idea about dividing global and local workspaces but it should not be stored in the program. This can easily be stored in a .blend file and made portable to any other installation or computer. As long as it’s loaded automatically there is no difference for you as the user.
Why not go ahead, make a mockup and post it at rightclickselect?
I don’t get it. If it would not be stored in a program it would not be global. Also, if you want portable blender, then the blender-wide config would be distributed with the blender folder in portable mode. You are really making no sense here. The whole meaning of the word “global” is “stored with the program configuration” in this particular context.
Of course it would be global. All a global workspace does is being saved automatically whenever you create an update and loaded automatically whenever you start the program or load any other file. It makes no logical difference to the user where it’s stored as long as it’s saved and loaded automatically and overarching any open scene.
If you store it in the program itself, every update will kill your workspaces again. If you store it in an external file (which Blender is very capable of alredy) then you can not only take this file everywhere you like. You can also take it across programm updates, store it on a server to load it into portable files on different computers etc.
Saving this inside a differnt file would be inconsistent to how Blender currently saves and handles workspaces. The startup scenes are .blend files, workspaces can be stored and imported from and to .blend files already. The only benefit of a program side storage in a configuration I could see is if it would mean that an external blend doesn’t performe well enough, otherwise.
Otherwise really - what diefference does it make to you how the global workspace is stored?
Have you Guys ever tried removing the “load ui” check from: Preferences > Save & Load > blend files > load ui and then try to open your files and see what happens to your workspaces …
well … but I am someone who does not understand …
… and so let’s continue we talk about the superfluous …
I fully admit that I was just trying to be constructive while not having needed the feature so far. ‘Load UI’ actually does pretty much that. There is a caveat, though, and I am not sure if it’s a bug or by design.
Loading a file works and preserves the Workspaces. Creating a new file, though, eliminates all of it and resets the workspaces to the defaults in the respective files.
Try this:
Disable Load UI, delete some workspaces, Add an object or two, and then create a new scene for the same layout.
→ Works as expected. UI tays put.
Now Create a new scene in, say, sculpting or 2D
→ Layout resets
Now create a new scene with the default Workspaces again.
→ Back to what they were before the first edit.
Am I doing something wrong or is Load UI behaving somewhat inconsistently?
And BTW - I think we could still benefit from a decoupled UI Split with one file preserving the UI all the time, while the other ones retain their internal Setup. I really do like the idea.
Adjust the interface, panels and all ui elements and all workspaces as desired so that they remain “universal and global”
Save default startup flile.
Save preferences (blender automatically does this on shutdown)
now you have:
load all the files you want, you will always have all the global interface that you have customized.
your files will still save the interface and the workspaces that you have “made global” or you have customized during your workflow but without having made a “save startup file”.
in case you want to open the scene with the “interface and local workspaces of the file” just select load ui again before loading the file.
Keep in mind that the save default startup files are valid for each type of workflow, this means that you can create 5 different startup files as far as the types of workflow are concerned:
It almost works the way I would expect except for some reason, after every 2 or 3rd load, the UI completely freezes and does not respond to any input at all
It will be probably some issue with customized keymap. I will try to narrow it down.
Also sorry for dismissing you after your first reply. I had no idea that they changed the Load UI to work like this. Now, when I work in already existing file, and change UI, it stays that way even in new clean file. It wasn’t that way before, and I am really surprised it works so well now. I thought they kept it the same.
The big problem here is that unfortunately the changes do not survive Blender restart. So yes, I can customize Blender UI even while working in existing file, and it will remain the same when I create a new file, but it will get thrown away if I close and reopen blender.
So we’re back at the start… We need global workspaces.
So it’s actually a lot worse than I thought. The “Load UI” option completely mixes up scene specific preferences with global preferences. It does not toggle just Loading of the UI arrangement, but it actually carries also properties of those editors! That’s scary. For example things like viewport field of view, which should be saved within the scenes, start bleeding in between completely different scenes when load UI is off.
Please make a fleshed out proposal on RightClickSelect, then. This is a new feature.
Lay out all the current shortcomings and how it could be implemented.
and then try to open your files and see what happens to your workspaces …
