Mixing sequencer and preview regions causes logical problems #92584

Open
opened 2021-10-28 23:42:12 +02:00 by Campbell Barton · 25 comments

With the addition of many editing operations to the sequencer preview,
there are an increasing number of logical problems with parts of the
UI that operate on the area, not the region.
Mainly menu items and the tool-system.

Note that this is only a problem with both are enabled at once.

To pick some examples:

  • Delete from a menu (should this delete the selection in the preview or the sequencer?)... same for select-all... and in the future copy/paste.
  • Transform (Move for e.g. is a different operation for the sequencer and preview).
  • Box select from the menu currently can't run in both sequencer and preview regions.

If the code-base is left in it's current state I'm concerned users will run into glitches/bugs (finding the mixed preview/sequencer to be broken).
For the most part these won't be things that can be resolved in isolation, so I think it's worth considering a solution now.


Supporting Mixed Preview/Sequencer

Technical solutions for this are possible but impractical in my opinion, for example the operator_context could support multiple items:

  layout.operator_context = {'INVOKE_REGION_PREVIEW', 'INVOKE_REGION_WIN`}

For the sake of argument we could have 2x menu items for Delete, Select-All... etc.

Other options include introducing an "Active Region" concept or having a header for each region.

This amounts supporting functionality in separate regions that areas already handle.


Proposed Solutions

Note that I don't have a strong opinion on the exact solution,
only that it should not over complicate the current code-base
(unless we wish to support larger changes to Blender's windowing in general).

When mixing preview/sequencer:

  • Remove the preview region interactive behavior.
This would make it view-only, any interactions, menu items, tools etc
would only apply to the sequencer.
  • Remove support for mixing preview/sequencer at once.
We could handle this with versioning (splitting the area).
With the addition of many editing operations to the sequencer preview, there are an increasing number of logical problems with parts of the UI that operate on the area, not the region. Mainly menu items and the tool-system. Note that this is only a problem with both are enabled at once. To pick some examples: - Delete from a menu (should this delete the selection in the preview or the sequencer?)... same for select-all... and in the future copy/paste. - Transform (Move for e.g. is a different operation for the sequencer and preview). - Box select from the menu currently can't run in both sequencer and preview regions. If the code-base is left in it's current state I'm concerned users will run into glitches/bugs (finding the mixed preview/sequencer to be broken). For the most part these won't be things that can be resolved in isolation, so I think it's worth considering a solution now. ---- **Supporting Mixed Preview/Sequencer** Technical solutions for this are possible but impractical in my opinion, for example the operator_context could support multiple items: ``` layout.operator_context = {'INVOKE_REGION_PREVIEW', 'INVOKE_REGION_WIN`} ``` For the sake of argument we could have 2x menu items for Delete, Select-All... etc. Other options include introducing an "Active Region" concept or having a header for each region. This amounts supporting functionality in separate regions that areas already handle. --- **Proposed Solutions** Note that I don't have a strong opinion on the exact solution, only that it should not over complicate the current code-base *(unless we wish to support larger changes to Blender's windowing in general).* When mixing preview/sequencer: * Remove the preview region interactive behavior. ``` This would make it view-only, any interactions, menu items, tools etc would only apply to the sequencer. ``` * Remove support for mixing preview/sequencer at once. ``` We could handle this with versioning (splitting the area). ```
Author
Owner

Added subscribers: @ideasman42, @JulianEisel, @iss

Added subscribers: @ideasman42, @JulianEisel, @iss
Member

Added subscriber: @Blendify

Added subscriber: @Blendify

Added subscriber: @tintwotin

Added subscriber: @tintwotin
[D12513](https://archive.blender.org/developer/D12513)

Added subscriber: @GeorgiaPacific

Added subscriber: @GeorgiaPacific
Author
Owner

@tintwotin can you give some context for this link?

@tintwotin can you give some context for this link?

Agree, that this is a problem. Normally I would default on operation on strips to be done in timeline context unless specified explicitly. Mainly because it feels correct, I haven't thought about this too much.

Some opinions:
I definitely don't think that menu items should be doubled. Also not really excited about removing interactivity suport from preview region. Alternative solution could be having operation context like in 3D view - strip mode/preview mode, but I don't think this would be best way to resolve this (adds too much complexity, IMO unnecessarily).

Removing support for combined view sounds plausible. I think, that no other editor does this? However people are using this mode for various reasons, and removal of this combined view should address these. I am aware of 2 main benefits of combined view: It provides more screen space for elements - UI is more compact. Also side panel can be much taller displaying more of strip properties.

To comment further on removal of combined view:
It introduces also unusable screen area in preview section, which is normally occupied by file browser, unless you edit ultrawide content. or use 4:3 monitor.
I think that more screen space could be resolved by using region overlap. Main problem with using overlap is scrubbing area, I haven't figured out what would be best layout or if it's even possible to do it well.
Issue with side panels may be bit controversial, but this was suggested to me and I didn't disagree in principle, just it needs bit more thought - Move strip properties into properties editor. It already exist in default VSE template and occupies nearly same space used by VSE timeline side panel. Otherwise properties editor is nearly useless in VSE layout.

Here is layout I use for editing:
Untitled.png
You can see that properties editor is very tiny, and to me it would be best if I could merge strip properties into it.

Agree, that this is a problem. Normally I would default on operation on strips to be done in timeline context unless specified explicitly. Mainly because it feels correct, I haven't thought about this too much. Some opinions: I definitely don't think that menu items should be doubled. Also not really excited about removing interactivity suport from preview region. Alternative solution could be having operation context like in 3D view - strip mode/preview mode, but I don't think this would be best way to resolve this (adds too much complexity, IMO unnecessarily). Removing support for combined view sounds plausible. I think, that no other editor does this? However people are using this mode for various reasons, and removal of this combined view should address these. I am aware of 2 main benefits of combined view: It provides more screen space for elements - UI is more compact. Also side panel can be much taller displaying more of strip properties. To comment further on removal of combined view: It introduces also unusable screen area in preview section, which is normally occupied by file browser, unless you edit ultrawide content. or use 4:3 monitor. I think that more screen space could be resolved by using region overlap. Main problem with using overlap is scrubbing area, I haven't figured out what would be best layout or if it's even possible to do it well. Issue with side panels may be bit controversial, but this was suggested to me and I didn't disagree in principle, just it needs bit more thought - Move strip properties into properties editor. It already exist in default VSE template and occupies nearly same space used by VSE timeline side panel. Otherwise properties editor is nearly useless in VSE layout. Here is layout I use for editing: ![Untitled.png](https://archive.blender.org/developer/F11588159/Untitled.png) You can see that properties editor is very tiny, and to me it would be best if I could merge strip properties into it.
Author
Owner

In #92584#1243741, @iss wrote:

Some opinions:
I definitely don't think that menu items should be doubled.

Agree, noted this to highlight that fixes for the current design are inelegant.

In #92584#1243741, @iss wrote:

Also not really excited about removing interactivity suport from preview region. Alternative solution could be having operation context like in 3D view - strip mode/preview mode, but I don't think this would be best way to resolve this (adds too much complexity, IMO unnecessarily).

Removing support for combined view sounds plausible. I think, that no other editor does this?

Right.


Moving strip properties into the properties editor seems like a good solution.

Although this feels late in the developer cycle to be making these kinds of changes.

> In #92584#1243741, @iss wrote: > > Some opinions: > I definitely don't think that menu items should be doubled. Agree, noted this to highlight that fixes for the current design are inelegant. > In #92584#1243741, @iss wrote: > > Also not really excited about removing interactivity suport from preview region. Alternative solution could be having operation context like in 3D view - strip mode/preview mode, but I don't think this would be best way to resolve this (adds too much complexity, IMO unnecessarily). > > Removing support for combined view sounds plausible. I think, that no other editor does this? Right. --- Moving strip properties into the properties editor seems like a good solution. Although this feels late in the developer cycle to be making these kinds of changes.

Question then is what would be left in timeline side panel. There are still proxy settings which are part strip propery and part VSE editor property and tool settings. Cache too with dev extras, so it won't be empty...

Question then is what would be left in timeline side panel. There are still proxy settings which are part strip propery and part VSE editor property and tool settings. Cache too with dev extras, so it won't be empty...
Author
Owner

In #92584#1243748, @iss wrote:
Question then is what would be left in timeline side panel.

Suggest to follow the 3D view:

  • View settings, frame overlay, safe areas, annotations.
  • We could keep the transform / time panel (roughly matching the 3D views transform panel).
  • Tool settings (fairly empty right now).
> In #92584#1243748, @iss wrote: > Question then is what would be left in timeline side panel. Suggest to follow the 3D view: - View settings, frame overlay, safe areas, annotations. - We could keep the transform / time panel (roughly matching the 3D views transform panel). - Tool settings (fairly empty right now).

Added subscriber: @fsiddi

Added subscriber: @fsiddi

In #92584#1243751, @ideasman42 wrote:

In #92584#1243748, @iss wrote:
Question then is what would be left in timeline side panel.

Suggest to follow the 3D view:

  • View settings, frame overlay, safe areas, annotations.
  • We could keep the transform / time panel (roughly matching the 3D views transform panel).
  • Tool settings (fairly empty right now).

Ok makes sense. So I can make patch for this, will tag @fsiddi too I would have him review this change anyway, so unless he disagree with this change I will do what I think is best, then we can tune details.

> In #92584#1243751, @ideasman42 wrote: >> In #92584#1243748, @iss wrote: >> Question then is what would be left in timeline side panel. > > Suggest to follow the 3D view: > > - View settings, frame overlay, safe areas, annotations. > - We could keep the transform / time panel (roughly matching the 3D views transform panel). > - Tool settings (fairly empty right now). Ok makes sense. So I can make patch for this, will tag @fsiddi too I would have him review this change anyway, so unless he disagree with this change I will do what I think is best, then we can tune details.

Added subscriber: @AndyCuccaro

Added subscriber: @AndyCuccaro

I agree with removing the preview/sequencer view and keeping the individual ones. This follows more closely Blender's design.

I suggest to handle moving strip properties from the VSE to the properties editor in a separate conversation.

I agree with removing the preview/sequencer view and keeping the individual ones. This follows more closely Blender's design. I suggest to handle moving strip properties from the VSE to the properties editor in a separate conversation.

In #92584#1250680, @fsiddi wrote:
I agree with removing the preview/sequencer view and keeping the individual ones. This follows more closely Blender's design.

Removing Sequencer & Preview is fixing valuable things with a hammer? The only current problematic thing is that the menu select/copy/del etc. options can't serve both the preview and the sequencer area, if they're called by the same operator, but this can simply be fixed by adding simple macros for the Preview ones(I already did a patch with a solution to this) and in Sequencer & Preview expose the Select Sequencer options in one submenu and Select Image in a different submenu.

Removing the Sequencer & Preview view mode is effectively removing the Video Sequence Editor. And it is removing the options to have a well organized workspace with property sidebar limited to one area(because in S&P the properties are merged into one sidebar). This leaves the users with the option to have maximum sidebar height and maximum preview size like this:
{F11773091,size=full}

Or if the width of the Sequencer timeline should be maximum(which is a major priority in most NLEs), it could be done like this(bc. all properties are in one panel):
{F11773118,size=full}

How can a major change like this be pushed in Bcon3? Did you even ask the community & users about this?

> In #92584#1250680, @fsiddi wrote: > I agree with removing the preview/sequencer view and keeping the individual ones. This follows more closely Blender's design. Removing Sequencer & Preview is fixing valuable things with a hammer? The only current problematic thing is that the menu select/copy/del etc. options can't serve both the preview and the sequencer area, if they're called by the same operator, but this can simply be fixed by adding simple macros for the Preview ones(I already did a patch with a solution to this) and in Sequencer & Preview expose the Select Sequencer options in one submenu and Select Image in a different submenu. Removing the Sequencer & Preview view mode is effectively removing the Video Sequence Editor. And it is removing the options to have a well organized workspace with property sidebar limited to one area(because in S&P the properties are merged into one sidebar). This leaves the users with the option to have maximum sidebar height and maximum preview size like this: {[F11773091](https://archive.blender.org/developer/F11773091/image.png),size=full} Or if the width of the Sequencer timeline should be maximum(which is a major priority in most NLEs), it could be done like this(bc. all properties are in one panel): {[F11773118](https://archive.blender.org/developer/F11773118/image.png),size=full} How can a major change like this be pushed in Bcon3? Did you even ask the community & users about this?

Added subscriber: @muhuk

Added subscriber: @muhuk

I don't use VSE too much. What little usage I have, the pre-configured workspace works just fine, sometimes I bring in Graph Editor but that's probably me not using it properly. Having said that I don't mind if the combined editor is removed.

OTOH I agree with @tintwotin on two points:

  • There should be some sort user input to decisions like this one, even if the dev team ultimately decides to do it. (I guess that's what we are doing here)
  • Removal should be deferred to 3.1.
I don't use VSE too much. What little usage I have, the pre-configured workspace works just fine, sometimes I bring in `Graph Editor` but that's probably me not using it properly. Having said that *I don't mind if the combined editor is removed*. OTOH I agree with @tintwotin on two points: - There should be some sort user input to decisions like this one, even if the dev team ultimately decides to do it. (I guess that's what we are doing here) - Removal should be deferred to `3.1`.

Added subscriber: @Mr_SquarePeg

Added subscriber: @Mr_SquarePeg

Hey - I really think the community should be consulted about this before removal of this tool. My 2 cents.

Hey - I really think the community should be consulted about this before removal of this tool. My 2 cents.
Contributor

Added subscriber: @AndresStephens

Added subscriber: @AndresStephens
Contributor

Removing it is a bandaid solution to the code issues and doesn't address the UX if at all.

Adding conditionals to the operators that would not be relevant to the modes to hide and putting the conditional first to timeline could help avoid feature break - and do it per operator. Keeping it to give user options is a better UX practice.

Think of the users first, then think of the code.

And I agree Tin, this is Bcon3, this is a major feature change, and should be postponed with a better design proposal for 3.1.

Do not remove for the sake of minimization. Work the UI for a still customizable and optimal UX a bit more.

Removing it is a bandaid solution to the code issues and doesn't address the UX if at all. Adding conditionals to the operators that would not be relevant to the modes to hide and putting the conditional first to timeline could help avoid feature break - and do it per operator. Keeping it to give user options is a better UX practice. Think of the users first, then think of the code. And I agree Tin, this is Bcon3, this is a major feature change, and should be postponed with a better design proposal for 3.1. Do not remove for the sake of minimization. Work the UI for a still customizable and optimal UX a bit more.

Removed subscriber: @fsiddi

Removed subscriber: @fsiddi
Member

The question how region specific operations and tools can be accessed in a multi-region context is not a code question, it's core UX design. So is the question if we want to have such split views in Blender.

Personally I'm in favor of using the Properties more for other editors than the 3D View. A dedicated tab for sequencer operations when a VSE is visible could work quite nicely. This in fact makes VSE workspaces more flexible than the current split view solution. Plus you can switch between tabs instead of keeping both a VSE sidebar & a Properties editor open.
(Generally, I think the idea of letting the Properties show only tabs relating to visible editors is worth investigating.)

The question how region specific operations and tools can be accessed in a multi-region context is not a code question, it's core UX design. So is the question if we want to have such split views in Blender. Personally I'm in favor of using the Properties more for other editors than the 3D View. A dedicated tab for sequencer operations when a VSE is visible could work quite nicely. This in fact makes VSE workspaces more flexible than the current split view solution. Plus you can switch between tabs instead of keeping both a VSE sidebar & a Properties editor open. (Generally, I think the idea of letting the Properties show only tabs relating to visible editors is worth investigating.)

In nutshell, the problem here is that the operator in the menu is executed based on the context(position) of the mouse cursor, so when in Sequencer & Preview the operators will always be executed as Preview operators if the menu is located over the preview.

The shortcuts are not a problem since they are executed in the correct contexts(mouse cursor position)

The sidebar is not a problem either. The mixing of Preview and Sequencer options does not result in any functional problems.

So as I see it, it is only a question of adding a context flag to the menu executed operators, so ex. Select > Preview > All will only select in the Preview and Select > All will select in the sequencer as usual. Before 3.0 the sequencer operators would always ex. select in the sequencer. If this was function was brought back, simple macros for the preview functions could be implemented as macros, as in my patch.

So basically I see two ways to potentially solve the context problems in the menus. Either as context flags on the operators in question, so operators executed from the menu in separated contexts or remove context sensitivity from the operators and add the double functions as macro operators, so they can be executed separately.

Moving vse properties into the Project Properties will narrow the needed property areas down to one in the VSE workspaces, but this doesn't solve the context menu problem. So this is a separate and imo unrelated discussion to context problems.

In nutshell, the problem here is that the operator in the menu is executed based on the context(position) of the mouse cursor, so when in Sequencer & Preview the operators will always be executed as Preview operators if the menu is located over the preview. The shortcuts are not a problem since they are executed in the correct contexts(mouse cursor position) The sidebar is not a problem either. The mixing of Preview and Sequencer options does not result in any functional problems. So as I see it, it is only a question of adding a context flag to the menu executed operators, so ex. Select > Preview > All will only select in the Preview and Select > All will select in the sequencer as usual. Before 3.0 the sequencer operators would always ex. select in the sequencer. If this was function was brought back, simple macros for the preview functions could be implemented as macros, as in my patch. So basically I see two ways to potentially solve the context problems in the menus. Either as context flags on the operators in question, so operators executed from the menu in separated contexts or remove context sensitivity from the operators and add the double functions as macro operators, so they can be executed separately. Moving vse properties into the Project Properties will narrow the needed property areas down to one in the VSE workspaces, but this doesn't solve the context menu problem. So this is a separate and imo unrelated discussion to context problems.

Just for the record, I don't think it is suggested here, that combined view should be removed in 3.0. As I said in earlier comment I think, that there are concerns that should be addressed with removal, or at least have a plan to mitigate them. My impression was that there are some issues in 3.0, but question is how to avoid more issues like these in future when we would like more operators to be context sensitive.

In different context I was thinking about having dropdown menu for how selection would work in preview - this is useful if you want to use transform tools on whole scene composition. But it should apply to other operators too, so this could be technically used for combined view too. Not sure if this would be reasonable alternative to just disabling interactivity in 3.0 as in both cases there is not a single place where change has to be done. Also then we wouldn't have to rush removal of combined view if there are impacts on workflow.

Just for the record, I don't think it is suggested here, that combined view should be removed in 3.0. As I said in earlier comment I think, that there are concerns that should be addressed with removal, or at least have a plan to mitigate them. My impression was that there are some issues in 3.0, but question is how to avoid more issues like these in future when we would like more operators to be context sensitive. In different context I was thinking about having dropdown menu for how selection would work in preview - this is useful if you want to use transform tools on whole scene composition. But it should apply to other operators too, so this could be technically used for combined view too. Not sure if this would be reasonable alternative to just disabling interactivity in 3.0 as in both cases there is not a single place where change has to be done. Also then we wouldn't have to rush removal of combined view if there are impacts on workflow.
Richard Antalik added this to the Video Sequencer project 2023-02-09 21:00:44 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No Assignees
11 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#92584
No description provided.