Page MenuHome

VSE: Middle region of a strip with selected edge(s) should not be treated as a selected region open to mouse drag grab
Closed, ArchivedPublic

Description

System Information
Operating system: Linux-5.4.0-81-generic-x86_64-with-glibc2.31 64 Bits
Graphics card: GeForce 9800 GT/PCIe/SSE2 NVIDIA Corporation 3.3.0 NVIDIA 340.108

Blender Version
Broken: version: 3.0.0 Alpha, branch: master, commit date: 2021-08-18 20:22, hash: rBa217e043be2d
Worked: Unsure

Short description of error (EDIT: issue clarifications from discussion below added for clarity)
If a strip has a handle selected, it means its body cannot be in a selected state (an impossible state, given any handle select will functionally deselect the body, even if not shown visually on the strip). Therefore the body of a strip with a handle selected should not be flagged as selected (i.e. grabbable).

We can see it's obvious that handle select != body select, and cannot be (body movement would override handle movement).

Given all this, really a mouse press on a strip just needs to check if the region under the cursor is already truly selected, before activating a grab - and not mistake a selected handle for a selected strip.

Exact steps for others to reproduce the error
See following GIF:

  • Select one or both edges of a strip
  • Press/hold on the middle of the same strip
  • Selection of edge(s) will not clear, it will act as if the edge/edges were grabbed instead of the middle

Event Timeline

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Needs Information from Developers.Aug 23 2021, 10:37 AM

Can confirm the behavior, but this does not look like a bug (it might be an improvement of current behavior though).

@Richard Antalik (ISS), @Peter Fog (tintwotin) : opinions?

Can confirm the behavior, but this does not look like a bug (it might be an improvement of current behavior though).

@Richard Antalik (ISS), @Peter Fog (tintwotin) : opinions?

I guess I see it functionally as a bug... though I was hoping that it's nice and simple to fix :D

Honestly I've encountered it a number of times while editing, and it felt very wrong each time it happened - though I didn't know quite why - so I made a note to look into it. Only when I got around to investigating it in depth the other day did I realize that it contradicted behaviour in other almost identical situations.

I tried for quite a while to solve it with the hotkey flags/options, but I think it's hard-coded behaviour :(

If you mean grab and drag, I think it's a bit difficult, because I know it is annoying to grab and drag the center of the strip, and you intent to move the entire strip and only the handle moves, however there are situations where you would want to grab and drag the center of the strip with the purpose of moving the handles:

If you mean grab and drag, I think it's a bit difficult, because I know it is annoying to grab and drag the center of the strip, and you intent to move the entire strip and only the handle moves, however there are situations where you would want to grab and drag the center of the strip with the purpose of moving the handles:

Thanks Peter, good point. Yes your situation references the same behaviour, and I agree you would want to keep it in that particular case. Not sure how easily the code could differentiate between those contexts?

Generally I much prefer to grab-move, over press-dragging strips. In the situation I mentioned though, it's a nice quick way shove a strip up a channel (well, when the edge isn't selected and it works), and it doesn't seem intuitive when it fails (whereas in your case current behaviour is definitely intuitive!).

I will have tinker with yours a few more related scenarios when I get home, with your food for thought in mind ...

I think part of the problem here is that the user do not notice having handles selected, since the strip is both outlined and have handles selected.

If it was either handles or outline showing what is selected, I think it would be avoided. Actually having both selected is inconsistent with how selection works in the 3d view where you do not have both the object and a vertex selected at the same time.

I think part of the problem here is that the user do not notice having handles selected, since the strip is both outlined and have handles selected.

If it was either handles or outline showing what is selected, I think it would be avoided. Actually having both selected is inconsistent with how selection works in the 3d view where you do not have both the object and a vertex selected at the same time.

I think you've hit the nail on the head there Peter. And the strip and handle(s) can be selected simultaneously only in a visual sense, as there seems to be just 4 states of selection to a strip: left handle selected, right handle selected, both handles selected, and strip body selected. The heavy visual of the border does seem to overpower when strip is in a handle select state. Either your proposed solution of removing the border, or perhaps even decreasing the current 2px border size to 1px, could be potential solutions in these cases.

I guess this would be an improvement request?

Okay I think I've had a small epiphany in my head as to what's actually happening when you drag any SELECTED/HIGHLIGHTED region of a strip: It's literally just a shortcut for [g]rab, using mouse release instead of click to confirm. I mean it's obvious I guess, but I've never really thought about it too closely.

Of course you get things like this happening:


... which can seem strange when viewed out of context, but are perfectly consistent with how it should behave.

However, my reported behaviour is not consistent with this rule. If a strip has a handle selected, it means its body cannot be in a selected state (an impossible state, given any handle select will functionally deselect the body, even if not shown visually on the strip). Therefore the body of a strip with a handle selected should not be flagged as selected (therefore grabbable).

It's obvious that handle select != body select, and cannot (body movement would override handle movement). The body of the strip on the right here does not move, only the handle does, despite both being explicitly selected:

Given all this, really a press on a strip just needs to check if the region under the cursor is already truly selected, before activating a grab - and not mistake a selected handle for a selected strip. That would solve my issue, without breaking any of the useful parts, and actually bring the strip selection aspect into full operational consistency.

NOTE: Eventually adding Peter's suggestion above to better visually differentiate handle selects from strip selects would excellently complement the usability in this area.
David Salvo (slinkeepie) renamed this task from VSE: Mouse press/hold on strip middle only releases selections from other strips, not its own edges to VSE: Middle region of a strip with selected edge(s) should not be treated as a selected region open to mouse drag grab.Aug 23 2021, 5:33 PM
David Salvo (slinkeepie) updated the task description. (Show Details)
Richard Antalik (ISS) closed this task as Archived.Aug 25 2021, 1:30 AM

Given all this, really a press on a strip just needs to check if the region under the cursor is already truly selected, before activating a grab - and not mistake a selected handle for a selected strip. That would solve my issue, without breaking any of the useful parts, and actually bring the strip selection aspect into full operational consistency.

You can't do this, otherwise it wouldn't be possible to move selection which consists of strips and handles.

NOTE: Eventually adding Peter's suggestion above to better visually differentiate handle selects from strip selects would excellently complement the usability in this area.

This sounds like better option.

Having said that, I would consider this to be improvement of existing state and therefore not a bug, so closing this report.