@Sergey Sharybin (sergey) I heard you're quite against the idea of syncing the workspace mode with the object mode. Mind explaining why exactly? :)

Note that strictly speaking, with the active object per workspace, there wouldn't be any syncing. Instead of a workspace.mode we'd access workspace.active_base.mode or similar.

(I'm also not a big fan of storing an/the active object in the workspace, but seems it's a necessary evil.)

Why not just toggle to object mode when the active object and workspace mode are not compatible?

Even storing the active object in workspace won't solve the issue of being in pose mode, and users changing active object from the outliner (e.g., from an armature to a mesh).

Let me share some feedback. Basically I think this proposal is mixing feasibility, implementation and design. You are hinting at something being not feasible yet using implementation workload as the suggestion to lead to different design.

1. Feasibility

You say that proposal 1 is quite challenging, but it's not conclusive regarding whether it's doable. Is there anything prohibitive about this?

2. Design

Proposal 1 and 2 deliver a very different results to the end user. I would like to see the reasoning behind picking the 2 over the 1. Not from a technical implementation point of view, but from the design itself.

3. Implementation

I personally don't mind if an intermediary implementation (leaving modes in objects) is done first, delivering the same final design but in a hackier way. Then eventually replaced with a more robust code. That said, if syncing is an issue even for the hackier solution I don't see the point for it at all.

In T53389#472398, @Dalai Felinto (dfelinto) wrote:

Why not just toggle to object mode when the active object and workspace mode are not compatible?

While this is technically an option, it's probably not a useful behavior for users.
I guess in most cases they would simply end up in object mode when switching workspaces. Say a user has a workspace for animation, each time she'd switch to it (from a non pose mode workspace) she had to select an armature first, then change the workspace. Or change the workspace (Blender switches to object mode), then select the armature, then manually enter pose mode.
It would only work in few cases.

Even storing the active object in workspace won't solve the issue of being in pose mode, and users changing active object from the outliner (e.g., from an armature to a mesh).

With the per object mode I don't see this being an issue. Obviously we had to change the active object then, just like it's done now with view-layers.
With the mode stored directly in the workspace, we'd probably need a fallback solution again (like fallback to object mode).

In T53389#472409, @Dalai Felinto (dfelinto) wrote:

Let me share some feedback. Basically I think this proposal is mixing feasibility, implementation and design.

Yes and that is because there is quite some overlap. I give two possible implementations that result in slightly different designs for the user. But the feasibility differs quite a bit, although it still depends on the exact design we choose (proposals show different approaches really, for the final design some details would still have to be figured out)

You are hinting at something being not feasible yet using implementation workload as the suggestion to lead to different design.

Not quite sure what you mean with that. Implementation wise there probably is some overlap. Changes that would have to be made for both to work nicely (e.g. active object per workspace).

1. Feasibility

You say that proposal 1 is quite challenging, but it's not conclusive regarding whether it's doable. Is there anything prohibitive about this?

Of course it's doable, everything is somehow ;) But for proposal 1 we need to redesign some workflows from scratch, and then they need to be implemented. How feasible it's on the technical level depends a lot on the final design. However what I'm most worried about is that this design would take a while to develop given our current design process issues.

2. Design

Proposal 1 and 2 deliver a very different results to the end user. I would like to see the reasoning behind picking the 2 over the 1. Not from a technical implementation point of view, but from the design itself.

The only difference for the user should be that the active mode can change with the active object. This keeps the workflows from pre 2.8 intact. For everything else, both proposals should behave mostly the same way, the exception being when changing the active object without manually changing the mode (by activating object in outliner). In proposal 2, that would work fine (mode changes with it), in proposal 1 the fallback solution would kick in (like fallback to object mode).

3. Implementation

I personally don't mind if an intermediary implementation (leaving modes in objects) is done first, delivering the same final design but in a hackier way. Then eventually replaced with a more robust code. That said, if syncing is an issue even for the hackier solution I don't see the point for it at all.

I don't think there is much of a hack involved really. The thing is, if we store an active object in the workspace, we can always access the active mode through workspace->base_active->mode. All we had to do is making sure is the active object is set and accessed via the workspace. Currently it's set via the view-layer, we just had to change that code.

On further discussion with @Dalai Felinto (dfelinto), he proposed doing things a bit differently:

• Workspace stores a mode and tries to keep it active.
• Object mode is used as fallback (e.g. when activating an object that doesn't support the workspace mode)
• Pressing ⇥ (tab) would toggle between the workspace mode and object mode, as opposed to toggling edit mode.

Or in other words, the workspace mode would be like a primary mode, with the object mode as secondary one for backup.

Actually with this proposal we can keep the mode stored in the object to start with, and get the currently active mode via workspace->view_layer->basact->mode. This wouldn't break the mentioned workflows (requirement #4 & 5) and be trivial to implement (afaics).

If we still decide to move the mode out of the object, we have to rethink the really clumsy weight painting and bone parenting workflows (requirement #4 & 5).

Submitted experimental version of my previous comment, D2965. This is just for testing the idea really. It is the most feasible solution I can see (design and implementation wise).