Page MenuHome

Box Select Keyframes doesnt set an active keyframe
Confirmed, NormalPublicDESIGN

Description

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce RTX 2070 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-10-17 21:36, hash: rBf425f40c4e17
Worked: (newest version of Blender that worked as expected)

Short description of error
When no keys are selected in the graph editor and you create a selection y box selecting no keyframe is set as active creating the dreaded issue of blender's having selection without active element to perform actions.

Exact steps for others to reproduce the error
open the graph editor
create several keyframe
deselect them all with a.
select with box select, none is active.

Expected solution

  • When box selecting the keyframe that is closest to the mouse cursor (not the 2d cursor) should become the active one when box selecting, unless there is already an active keyframe in which case the active keyframe should remain.

Test builds for potential fix

These builds not only fix the box/circle/lasso select by ensuring a keyframe is active, but also update the active FCurve so that the selection also contains the active FCurve.

Event Timeline

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Needs Developer to Reproduce.Oct 20 2020, 1:58 PM

Not sure if this goes in line with how blender does things?
This is the same for object seletion, vertex selection, ... with Box (no setting of active).

Your solution (making the closest to the mouse cursor active) is something I need to think about more...

In any case: if this should be handled as a bug report, I'd say it is no bug, if this is something the animation / UI wants to keep as TODO, they would have to decide...

CC @Sybren A. Stüvel (sybren)
CC @Hans Goudey (HooglyBoogly)

Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Bug".Oct 20 2020, 3:25 PM

@Philipp Oeser (lichtwerk) You're right in that other areas of Blender also can have a selection without an active item. For the graph editor, I don't see the advantage of this, though, and @Luciano Muñoz Sessarego (looch) really doesn't like the "selection but nothing active" scenario.

Philipp Oeser (lichtwerk) changed the task status from Needs Developer to Reproduce to Confirmed.Oct 20 2020, 3:29 PM

@Philipp Oeser (lichtwerk) You're right in that other areas of Blender also can have a selection without an active item. For the graph editor, I don't see the advantage of this, though

To be totally honest, it is not really an advantage in other areas either :) [at least not in every scenario]

Hans Goudey (HooglyBoogly) added a project: Restricted Project.

@Luciano Muñoz Sessarego (looch) The box, circle, and lasso select all use the same function to perform the selection changes. For box-selecting, it just gets the rectangle coordinates of the box (so top-left and bottom-right corners), without any information about the mouse location.

What I think is still doable for 2.91 is a simpler approach, where the right-most keyframe becomes the active one. Would that be sufficient for now?

Sybren A. Stüvel (sybren) changed the task status from Confirmed to Needs Information from User.Oct 26 2020, 12:04 PM

Hey !,

Yeah I think that's good compromise and predictable enough to be useful i'd say!.

Let's do it.

There is a bit of counter-intuitive behaviour still, but that's regarding the active FCurve, and how it interacts with the active keyframe. There are two aspect to this:

Interaction between active keyframe and active FCurve
  • Every FCurve has an active keyframe.
  • What is shown as the active keyframe in the graph editor is actually the active keyframe of the active FCurve.
  • Box select does not change what is the active FCurve.

Because of that last point, things remain a bit iffy. After a box-select you will still end up without an active keyframe when keyframes of the active FCurve weren't part of the selection. We can revisit this as well, of course, and change the active curve on box/circle/lasso select, but that's beyond the scope of this task. Not a bad idea to redesign this together with the UI module, though.

Remembering the last active keyframe

Another thing that interferes is the following:

  • Every FCurve can have an active keyframe.
  • That keyframe can only be active when it is selected as well.
  • Even when deselecting the keyframe, the FCurve remembers which one was active. This can be nice, because that means that after Alt+A to deselect everything and A to select everything, what was once the active keyframe remains the active keyframe.

Because of this, the active keyframe will not always be the right-most one. If one of the selected keyframes just happens to previously be the active keyframe, it stays the active keyframe.

Conclusion

In conclusion, I think that the simple approach (on each affected FCurve the right-most selected keyframe becomes active, don't change any other behaviour) is the right way to go for this. It'll likely do a reasonable thing, and it will result in an active keyframe more often than not.

@Luciano Muñoz Sessarego (looch) You okay with this?

Sybren A. Stüvel (sybren) renamed this task from Box Select Keyframes doesnt set an active keyframe. to Box Select Keyframes doesnt set an active keyframe.EditedOct 26 2020, 5:32 PM

To test the behaviour, I've made a Windows test build. This one also updates what is the active FCurve.

I don't know if Blender's general (something can be active but not selected) is strictly useful - though it would be nice from a Blender perspective if behavior in the graph editor is as close as reasonable to the rest of the program - maybe a general UX task about selections could also be created?

WRT Sybren's solution, it seems nice enough - I wonder how handy it would be to remember the last active keyframe on box select, I can imagine some scenarios:

[obviously good]: box select around an active-selected keyframe does not change active, fits with rest of blender and is most likely what the user wants.

[how often does this happen?]: user selects, then deselects a keyframe (making it active and unselected) and then immediately box selects, it makes sense here to the user why that keyframe is active, as they still remember their previous action.

[OK behavior if it is consistent]: user box selects some keyframes, rightmost keyframe is set active - so long as this happens everytime, with the above exception, user easily forms a mental model of what box select does.

[confusing]: sometime in the past, the user selected a keyframe, deselected it and moved on, and hours later, box selects some keyframes that happen to contain it - now a non rightmost keyframe is active. User is potentially confused about what box select does, as they do not remember their previous selection.

I don't know if Blender's general (something can be active but not selected) is strictly useful - though it would be nice from a Blender perspective if behavior in the graph editor is as close as reasonable to the rest of the program - maybe a general UX task about selections could also be created?

Personally I'm fine with having "our" behaviour in the graph editor as a bit of an experiment, to see how works for people. Discussing a UX change is much easier when you already have some experience with the proposed change. Maybe it's a good idea to create this UX task soon, though, so that we don't forget. This experiment could just be mentioned in that task.

[confusing]: sometime in the past, the user selected a keyframe, deselected it and moved on, and hours later, box selects some keyframes that happen to contain it - now a non rightmost keyframe is active. User is potentially confused about what box select does, as they do not remember their previous selection.

Yes, this is what I'm afraid of as well. Unfortunately (apart from tracking time and making an FCurve forget its active keyframe after an hour of being deselected) I don't see a proper solution that resolves this and keeps the "deselect everything, select everything, active keyframe is maintained" scenario working.

What I'm also a bit afraid of is the change of active FCurve I implemented in the above-built branch for testing. For circle-select it is predictable, because it just follows along with the selection circle. For box-select it is not, though, because it depends on the internal ordering of the animation channels -- it's not depending on closest-to-mouse or anything like that.

The issue of active without selection is separate from box-select setting active.

This seems more a design task.

It was part of what we agreed on (unfortunately this wasn't written down explicitly in the design task), that for the active keyframe there would always be a connection between "active" and "selected" keyframes:

  • If one or more keyframes are selected, one of them should be active.
  • The active keyframe should always be selected as well, so no "it's active but not selected" state should be allowed.

I've played with the patch and I feel it could be improved a bit more

It seems that the new 'active' keyframe is always somewhere to the right of the box, is it possible to make the active be the one closest to the mouse when it was released / box corner at the end of the box-select? that would give it a bit of consistency with active = last selected

I've played with the patch and I feel it could be improved a bit more

It seems that the new 'active' keyframe is always somewhere to the right of the box, is it possible to make the active be the one closest to the mouse when it was released / box corner at the end of the box-select? that would give it a bit of consistency with active = last selected

That would definitely be ideal :).

That's much harder to do, and not possible before tomorrow (which is the last day before the release). We may want to postpone this patch and do it properly.

Campbell Barton (campbellbarton) changed the subtype of this task from "Bug" to "Design".Nov 16 2020, 11:39 PM

This is working as originally intended, marking as design. Although not sure this is worth keeping open since there is an existing design task about this (T82359).

As mentioned in the other design task: if behavior here is changed, we should consider other areas of Blender.

Campbell Barton (campbellbarton) changed the task status from Needs Information from User to Confirmed.Nov 16 2020, 11:45 PM