Box Select Keyframes doesnt set an active keyframe #81874

New Issue

Luciano Muñoz Sessarego · 2020-10-20T01:15:55+02:00

2020-10-20 01:15:55 +02:00

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: f425f40c4e
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.

Windows.
Linux

**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: `f425f40c4e` 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. - [Windows](https://builder.blender.org/download/temp-#81874-box-select-active-keyframe/temp-#81874-box-select-active-keyframe-blender-2.91.0-87d654535c71-windows64.zip). - [Linux](https://builder.blender.org/download/temp-#81874-box-select-active-keyframe/temp-#81874-box-select-active-keyframe-blender-2.91.0-87d654535c71-linux64.tar.xz)

Luciano Muñoz Sessarego commented

2020-10-20 01:15:55 +02:00

Added subscriber: @LucianoMunoz

Philipp Oeser commented

2020-10-20 13:58:17 +02:00

Added subscribers: @HooglyBoogly, @dr.sybren, @lichtwerk

Philipp Oeser commented

2020-10-20 13:58:17 +02:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Philipp Oeser commented

2020-10-20 13:58:17 +02:00

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 @dr.sybren
CC @HooglyBoogly

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 @dr.sybren CC @HooglyBoogly

Sybren A. Stüvel commented

2020-10-20 15:25:10 +02:00

@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 @LucianoMunoz really doesn't like the "selection but nothing active" scenario.

Philipp Oeser commented

2020-10-20 15:29:53 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Philipp Oeser commented

2020-10-20 15:29:53 +02:00

In #81874#1037862, @dr.sybren wrote:
@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]

> In #81874#1037862, @dr.sybren wrote: > @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]

Sybren A. Stüvel self-assigned this 2020-10-26 11:29:47 +01:00

Sybren A. Stüvel commented

2020-10-26 12:03:52 +01:00

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

@LucianoMunoz 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 commented

2020-10-26 12:04:05 +01:00

Changed status from 'Confirmed' to: 'Needs User Info'

Luciano Muñoz Sessarego commented

2020-10-26 12:09:52 +01:00

Hey !,

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

Let's do it.

Hey !, Yeah I think that's good compromise and predictable enough to be useful i'd say!. Let's do it.

Sybren A. Stüvel commented

2020-10-26 14:42:04 +01:00

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 {key Alt A} to deselect everything and {key 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.

@LucianoMunoz You okay with this?

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 {key Alt A} to deselect everything and {key 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. @LucianoMunoz You okay with this?

Sybren A. Stüvel changed title from ~~Box Select Keyframes doesnt set an active keyframe.~~ to Box Select Keyframes doesnt set an active keyframe

2020-10-26 17:32:04 +01:00

Sybren A. Stüvel commented

2020-10-26 17:32:48 +01:00

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

To test the behaviour, I've made a [Windows test build](https://builder.blender.org/download/temp-#81874-box-select-active-keyframe/temp-#81874-box-select-active-keyframe-blender-2.91.0-87d654535c71-windows64.zip). This one also updates what is the active FCurve.

bassam kurdali commented

2020-10-27 16:16:13 +01:00

Added subscriber: @BassamKurdali

bassam kurdali commented

2020-10-27 16:16:13 +01:00

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

Sybren A. Stüvel commented

2020-10-29 11:54:20 +01:00

In #81874#1042863, @BassamKurdali 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.

> In #81874#1042863, @BassamKurdali 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.

Campbell Barton commented

2020-10-29 12:05:25 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2020-10-29 12:05:25 +01:00

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

This seems more a design task.

The issue of active without selection is separate from box-select setting active. This seems more a design task.

Sybren A. Stüvel commented

2020-10-29 12:11:58 +01:00

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.

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.

bassam kurdali commented

2020-11-16 20:50:12 +01:00

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

Luciano Muñoz Sessarego commented

2020-11-16 20:52:53 +01:00

In #81874#1055809, @BassamKurdali 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 :).

> In #81874#1055809, @BassamKurdali 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 :).

Sybren A. Stüvel commented

2020-11-16 22:36:36 +01:00

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 commented

2020-11-16 23:41:44 +01:00

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 (#82359).

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

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 (#82359). As mentioned in the other design task: if behavior here is changed, we should consider other areas of Blender.

Campbell Barton commented

2020-11-16 23:45:21 +01:00

Changed status from 'Needs User Info' to: 'Confirmed'

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Box Select Keyframes doesnt set an active keyframe #81874