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

@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?

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?

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.

In T81874#1042863, @bassam kurdali (bassamk) wrote:

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

In T81874#1055809, @bassam kurdali (bassamk) wrote:

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.

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.