Workspaces change content of floating window

Hi,

I am noticing something very weird. When I shift+drag corner to quickly create a new floating window to put on my second monitor, once I switch workspaces, the floating window contents are replaced with startup .blend file layout:

Workspaces are now already hardly usable due to the fact one has to manually set all the super granular viewport settings per workspace, and then manually keep them in sync when changing them. This adds another layer of inconvenience on top of that, having to manually set up contents of floating window for every single workspace, and then once that content changes, manually update it in all other workspaces. That would be so consuming it would make usage of workspaces pointless.

2 Likes

I agree, it is inconvenient. There needs a way to “pin” any editor on workspace change (if it’s pinned, it will convert to a floating window, and if it’s floating, it won’t change.)

So… no feedback on this? Is this going to stay the way it is? Because it pretty much makes workspaces unusable for anyone working with multiple screens.

Problem is that there is no distinction between a window for default layout (that should display something pertinent for each workspace and should change with workspace switch) and a floating window (occasionally inspired by work in progress, that should not be sensible to workspace switch).

It would be welcomed to have another type of window.
There are main window type, secondary window type in Window menu.
We could imagine a third type under this menu : floating window that could also be created by using shift click.

The window system is already a mess, there being “New Window” and “New Main Window”. Third option is not a solution. Solution is that workspaces should simply not affect any new windows user has created. If there are workspaces with multi-window setup, then those workspaces should spawn their own, new window with the additional workspace content, instead of overriding windows user has created for their own use.

Calling two types of window a mess, you are a little bit overstating.
This distinction is needed to distinguish main windows with Topbar able to display her own scene, own viewlayer and secondary window for multi-window setups that are following scene, viewlayer and workspace displayed into main window.

But you are probably right about the fact that a solution for arbitrary new window corresponding to a floating editor like User Preferences or Drivers Editor has to be obvious from user perspective.
Yes. Assigning Shift left click to that is perfect solution.
I was just suggesting to give a clear name to that type of windows and add it to Window menu.
That will not go against your proposal. If you don’t use Window menu, you don’t have to care about that.

But distinction between Windows types is still needed ; otherwise, there is a risk to loose one ability by trying to add another missing one.

Yes, still parented under one process. That’s quite unnecessary and I would be very surprised to see people actually using it, given the risk to reward ratio. At that point, it just makes more sense to open another Blender instance.