Page MenuHome

Synchronizing editors between workspaces
Needs Triage, NormalPublicDESIGN

Authored By
Michael Soluyanov (crantisz)
May 16 2020, 8:34 PM
"Love" token, awarded by hitrpr."Yellow Medal" token, awarded by 1D_Inc."Like" token, awarded by TheCharacterhero."Like" token, awarded by BulatKR."Like" token, awarded by Nikita."Love" token, awarded by stanpy."Like" token, awarded by dez.


Here is a design discussion about synchronizing editors between workspaces.

Basically, synchronizing editors try to keep content in editors with same type when you switch between workspaces.

Working prototype and previous discussion is here

Problems, that we need to discourse:
  1. How to enable synchronizing?
  2. If workspaces have more than one editor with same type, how to determine which area in one workspace corresponds to the area in another workspace?
  3. What settings we heed to synchronize - view position / window scroll / settings / open-close state in Outliner
  4. If I change editor type in area, that have marked as synchronized, what should Blender do? Change editor type in all synchronized areas, or disable synchronizing for current area? - my current answer is "disable"
  5. If Blender changes editor type in area by image editor, while rendering, or file browser, what should it do? Change editor types in all synchronized areas, or disable synchronizing for current area? - my current answer is "change editor types"
  6. Should Blender allow creating new synchronizing links, instead using existing ones (For example, synchronizing areas in workspaces W1 <=> W2 and W3 <=> W4, instead W1 <=> W2 <=> W3 <=> W4 )

Add a Synchronize property for areas. When two areas in different workspaces are marked as Synchronize, they get same Sinc ID, and Blender will synchronize areas by this ID.

What settings we heed to synchronize

I noted, that synchronization of view position approved by all, but not all wants synchronization of other settings. So there is a suggestion to divide synchronization into several parts: view position, window scroll and settings, open-close state.

Possible solutions how to do this:

  1. Add different menu items:
    • for viewport: Sinc View, Sinc Settings
    • for outliner: Sinc Scroll, Sinc State
    • for 2d editors: Sinc scroll, Sinc Settings

      I am not a fan of this because it is not clear. That will happen then one area will mark as Sinc View, other Sinc Settings?
  1. Add settings in User Preferences:
    • View and Scroll Possition
    • Area Settings
  1. Add only synchronizing view position / window scroll / open-close state in Outliner only and add an operator "Copy Overlay (Shading, Gizmo) Settings to all Viewports (Editors)". By the way, it will be nice to have this operator and without this synchronization task
  1. Synchronize all settings, but add more settings to workspace. For example, assign Shading Mode to the workspace (where now Object Mode selector is located). Or maybe, Minimum Shading level. It will be useful for Shading workspace. When you tap to Shading workspace from Solid mode, you switch to "Material Preview", but if you already have Rendered mode, it will be nice to keep it and do not downgrade it to "Material Preview"

The new menu View - Area - Sinc, made like a property with checkbox. If it checked, area is synchronized.
I suggest some different variations, how menu can be looks like, depends on current situation:

I created this design because @Julian Eisel (Severin) suggest this. This is my first task, if I did something wrong, notify me.

Event Timeline

Debuk (Debuk) added a comment.EditedMay 21 2020, 1:10 PM

If workspaces have more than one editor with same type, how to determine which area in one workspace corresponds to the area in another workspace?

This is heavily dependent on if the goal is to support different synchronziation groups/ids for the same editor types or if there is just one sync ID them. (eg have for all 3dviews just one id possible)

If there is just one sync id per areatype, then syncing could be handled like subscribing to its defined id. So more views in a viewport could subsribe to being in sync with that or not and every area could opt out of individual properties associated with this sync id, like pos, shading,...

This comes with limitations in possibilities but would be easier to handle, so my question left open is this, more sync ids per areatype or is that beyond scope ?

In the last implementation, the sinc IDs in no way depend on the type of editor. It allows keeping areas synchronized, even they temporary replaced by image editor during rendering. And, of-course, it allows synchronizing more than one editor with same type

Changing the 3D view is the most disorienting in my opinion.

I think this design proposal could be reworked in favour of simplicity. Two main things come to mind:

  • The sync toggle should probably be a global property that spans across workspaces. The idea would be to activate a Global Sync that stays true for all 3D Views until it's turned off.
  • Everything should be in plain sight. With a single glance the user should be able to tell if the current viewport is synchronized, and if global sync is active at all.

I don't the Global Sync should carry anything other than view_location, view_rotation, view_distance and view_perspective. Perhaps, lens, clip_start and clip_end as well.
Anything more than that would defy the purpose of having multiple workspaces, which tend to have different view/shader settings specifically because they're designed to be different "environments". The true inconvenience that stems from the current situation, IMHO, is the need to readjust the view when working on a certain part of the scene while hopping between different stages (Modeling, Sculpting, Unwrapping, Shading...).

The global syncing should be fast to toggle on and off. Hiding the option into a context menu is inadequate. It both hides the current Sync state from the user, and "opting in" for each viewport is a lengthy and inconvenient process. Instead, I think it would be easier to have a global setting from which a viewport can "opt out" of, entering in a temporary "Free view" state. Here's a working mock-up I made in python:

There are still some problems that need to be addressed, such as handling a workspace with many 3D Views. Offhand, it would seem logical to me to designate one of them as the main one from which you'd copy the view settings. After all, multiple 3D Views in workspace are almost always used to check the scene from different angles, perhaps with different settings. The user would be in charge of selecting which view would be the main one, perhaps from the same popover menu that would dynamically accomodate the settings.

Finally, I wouldn't cram too many features into this proposal. Storing and linking multiple sets of views, for example, is something that is not only potentially confusing, but kinda goes out of the main proposal's scope. Not to mention, there are bundled add-ons that enable this functionality. Keeping it simple and manageable is a good first step to actually have something that embraces Blender's design philosophy.