In T90843#1210075, @Philipp Oeser (lichtwerk) wrote:

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:

In T90843#1210215, @Peter Fog (tintwotin) wrote:

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.

In T90843#1210251, @Peter Fog (tintwotin) wrote:

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:

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.