Workspaces: Integrating Interaction Modes - Proposals #53389

New Issue

Julian Eisel · 2017-11-24T21:45:50+01:00

Julian Eisel commented

2017-11-24 21:45:50 +01:00

Workspaces: Integrating Interaction Modes - Proposals

In this task we can discuss possible solutions for integrating interaction modes with workspaces nicely. Thereby the requirements of #53388 should be met.

Proposal 1: Mode only stored in the workspace

Conceptually, it makes sense to have the interaction mode in the workspace. That way it becomes a workspace-global setting that only changes when users do so themselves or by changing the workspace.
It meets requirements #1 and 3 (see #53388). For requirements #4 and 5, the workflows would have to be redesigned and rewritten. However doing so may be quite challenging.

Active object would probably have to be stored in the workspace, so that switching workspace may not lead to having an object in a mode it doesn't support (requirement #2).
Requirement #6 is more of technical nature and doesn't matter for this proposal.

By placing the mode selector in the top-bar like planned (see #50845), requirements #7 and 8 are addressed too.

Proposal 2: Keep mode per object, workspace can change it

We keep the mode stored in the object, but allow the workspace to change it. It means we keep old workflows intact, while still making the mode a per-workspace option (requirements #1, 3, 4 and 5 are meet).

Issue is, with the mode stored per object, activating a different object may cause the interaction mode to change. Hence, the mode would have to be synced with the workspace. However, for this proposal, just like for proposal 1, we'd need to store an active object per workspace to meet requirement #2. So we had to sync the active object with the workspace anyway.

For requirements #6, 7 and 8, the same as in the first proposal applies.

Conclusion

Both proposals would suggest to store an active object per workspace. Moving the mode completely to the workspace may make more sense long-term, but the second one seems far more feasible. The syncing of the workspace mode and the object mode basically comes for free due to the active object per workspace. We could even avoid storing the mode in the workspace completely (its active object stores it indirectly).
A user visible difference is that in the first proposal, the mode would never change except if users explicitly do so or change the workspace. That's different from how Blender behaves now (pre 2.8).

# Workspaces: Integrating Interaction Modes - Proposals In this task we can discuss possible solutions for integrating interaction modes with workspaces nicely. Thereby the requirements of #53388 should be met. ## Proposal 1: Mode only stored in the workspace Conceptually, it makes sense to have the interaction mode in the workspace. That way it becomes a workspace-global setting that only changes when users do so themselves or by changing the workspace. It meets requirements #1 and 3 (see #53388). For requirements #4 and 5, the workflows would have to be redesigned and rewritten. However doing so may be quite challenging. Active object would probably have to be stored in the workspace, so that switching workspace may not lead to having an object in a mode it doesn't support (requirement #2). Requirement #6 is more of technical nature and doesn't matter for this proposal. By placing the mode selector in the top-bar like planned (see #50845), requirements #7 and 8 are addressed too. ## Proposal 2: Keep mode per object, workspace can change it We keep the mode stored in the object, but allow the workspace to change it. It means we keep old workflows intact, while still making the mode a per-workspace option (requirements #1, 3, 4 and 5 are meet). Issue is, with the mode stored per object, activating a different object may cause the interaction mode to change. Hence, the mode would have to be synced with the workspace. However, for this proposal, just like for proposal 1, we'd need to store an active object per workspace to meet requirement #2. So we had to sync the active object with the workspace anyway. For requirements #6, 7 and 8, the same as in the first proposal applies. ---- ## Conclusion Both proposals would suggest to store an active object per workspace. Moving the mode completely to the workspace may make more sense long-term, but the second one seems far more feasible. The syncing of the workspace mode and the object mode basically comes for free due to the active object per workspace. We could even avoid storing the mode in the workspace completely (its active object stores it indirectly). A user visible difference is that in the first proposal, the mode would never change except if users explicitly do so or change the workspace. That's different from how Blender behaves now (pre 2.8).

Julian Eisel commented

2017-11-24 21:45:50 +01:00

Changed status to: 'Open'

Julian Eisel commented

2017-11-24 21:45:50 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2017-11-24 21:54:48 +01:00

Added subscriber: @Sergey

Julian Eisel commented

2017-11-24 21:54:48 +01:00

@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.)

@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.)

Dalai Felinto commented

2017-11-27 12:01:59 +01:00

Added subscriber: @dfelinto

Dalai Felinto commented

2017-11-27 12:01:59 +01:00

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).

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).

Dalai Felinto commented

2017-11-27 12:52:02 +01:00

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.

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?

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.

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.

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.

Julian Eisel commented

2017-11-30 16:39:59 +01:00

In #53389#472398, @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 #53389#472409, @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).

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.

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).

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.

> In #53389#472398, @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 #53389#472409, @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.

Julian Eisel commented

2017-12-07 19:40:06 +01:00

On further discussion with @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 {key Tab} (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).

On further discussion with @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 {key Tab} (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).

Danrae Pray commented

2017-12-09 16:37:30 +01:00

Added subscriber: @spockTheGray-4

Julian Eisel commented

2017-12-15 17:00:58 +01:00

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).

Submitted experimental version of my previous comment, [D2965](https://archive.blender.org/developer/D2965). This is just for testing the idea really. It is the most feasible solution I can see (design and implementation wise).

Campbell Barton commented

2018-02-23 04:14:16 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2018-02-23 04:14:16 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2018-02-23 04:14:16 +01:00

Campbell Barton self-assigned this 2018-02-23 04:14:16 +01:00

Campbell Barton commented

2018-02-23 04:14:16 +01:00

Closing since workspaces now store the object mode. 345c6298e9

Closing since workspaces now store the object mode. 345c6298e9

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Workspaces: Integrating Interaction Modes - Proposals #53389

Workspaces: Integrating Interaction Modes - Proposals

Proposal 1: Mode only stored in the workspace

Proposal 2: Keep mode per object, workspace can change it

Conclusion