Page MenuHome

Graph Editor: Reevaluate Key and Handle Selection Behavior
Open, NormalPublic


Graph Editor: Reevaluate Key and Handle Selection Behavior

Disclaimer: While not a big change on the grand scheme of things, every little tweak to the Graph Editor selection behavior breaks muscle memory for animators - who typically rely on highly trained muscle memory. So we don't take these "tweaks" lightly.

We've just streamlined selection behavior across 2D editors for click and drag actions on items (nodes, VSE strips, Dopesheet keyframes, etc.).

As relevant to this topic, the following actions should work well together:

  • Click+drag on an item to select and move it in one go.
  • With multiple items selected, click+drag on one moves all (previously only moved the clicked on item). We'll refer to this as drag-all-selected.

This is incompatible with the current Graph Editor selection behavior:

  • You'd want to be able to click a key to unhide the curve-handles, and then just click+drag a single handle.

    Issue is that currently, clicking a key to unhide the curve-handles also selects the handles. With drag-all-selected, dragging a handle would move both handles and the key.
    Note that this capture already includes tweaks to allow deselecting keys without that hiding the handles.

Besides this issues, we could solve further problems:

  • With default settings, it's not possible to select multiple handles, without the keys. To do that you have to either:
    • change the keymap so Box Select has the option Include Handles enabled and use that, or
    • disable ViewOnly Selected Keyframes Handles.
  • When moving multiple items (e.g. through G), left and right handles are moved together. Usually you'd want only one side to move (or one side + the neighbour handle on the curve if selected).

There's intentionally no proposal in this description yet.



Event Timeline

I think this bug is relevant to the mentioned issues, so I'll just post it here:

This issue is a little bit complicated in a way. I have surveyed what several other apps do here, and they solve this issue in various different ways.

Some apps solve it by making it so that if you select a keyframe in the Graph Editor, the handles are not also selected. And if you want to transform one or more handles, you must explicitly select them.

Other apps make it so that if you drag on a handle, only selected handles of that type (left or right) are transformed.

So my proposal would be:

  • We fix the issue with transforming the key only, so the handles move properly as children.
  • If you tweak-drag on a handle when both handles are selected, transform the handle you drag on, and also all other selected handles of that type (left or right).

Then Blender doesn't have to change too much and we don't have to compromise anything for users of the hotkeys
but it would be possible to use tweak-dragging in a reasonable way also.

I've done some experimental changes in a new branch, temp-graph-select-changes. Namely:

  • Handles now always move with the key, regardless if they are selected or not
  • Selecting the key doesn't select the handles anymore, their selection is separate.
  • Selection and dragging is consistent with Node Editor, VSE, Dopesheet, etc now, in that the same logic is applied to support drag-all-selected and selecting vs. dragging.

William and I agree that this can work well, but that dragging a handle should still only move handles on the side you clicked on. E.g. clicking a right handle only moves selected right handles, not left ones or keys.

We need to figure out how to do this. We usually don't tell the transform operator what was clicked on, it just operates on the selection. Note that we may not want to limit this behavior to click+dragging only, users may want this for G/R/S transform too.

Multiple ideas:

  • Add support for active handles/keys. Transform would use this to figure out if it should transform only one side (and which).
  • Let transform always use the handle side closest to the mouse press.
  • Let transform always use the handle side closest to the cursor (even for G/R/S).
  • When clicking on a selected handle, deselect all keys and all handles on the other side.

@Julian Eisel (Severin)

So, ideally I think this is how it should work:

  • We should try and leave G/R/S modal operator workflow as untouched as possible
  • Tweak-dragging any handle can never affect any keyframe location, only handles
  • When only handles only on one side is selected, that's the side that should be affected by tweak actions
  • When both handles are selected, tweaking a handle should only affect handles on that side (left vs right)

Does that make sense?

The logic could be a little bit difficult, because ideally it would be best if we can both tweak to affect specifically selected handles:

But also that we deal with the more common case where both handles are selected:

If that's too complex to support both, I think we should start by simply always making tweaking affect all the selected handles on the same side as the one you drag on, ie example #2 above. IMO this is much more common.