Page MenuHome

Redesign Graph editor Header and Menus to 2.80 Blender UI standards
Needs Information from Developers, NormalPublicDESIGN


The current graph editor menus have slowly evolved and not been evaluated carefully. As a result, the header menus are a bit of a mess:

Here some options are really hard to parse and arranged oddly (for intance, Show Handles and Show "Only Selected Keyframe Handles" are related, but seperated from each other, and it is really hard to parse what they do, some options like "AutoMerge Keyframes" don't belong at all in View.
This design task is to work towards making the header area in the graph editor match blender design, so that options are found in an expected place, similar to e.g. the 3D View header which has received more attention:

  1. Reorganize the header so that similar items are in similar places, e.g. pivot and snapping options should be centered
  2. Add an overlay menu and organize some of the clutter in the view menu so it makes more sense, and fits a (Blender) users expectations of where things should be
  3. Reorganize all the menus if needed, and move items that don't belong (e.g. the aforementioned AutoMerge Keyframes) to a logical place
  4. Potentially upgrade the editor to use the tool system and have two lines in the header for options, etc.

Event Timeline

Current Appearance:

  1. Snapping options and Proportional editing are right justified, whereas they are centered in the 3D View
  2. There is no overlays drop down
  3. The view menu is confusing, and almost requires careful reading with every use. Some options don't really belong there.

Mockup 1

  1. Centered Pivot, snapping and proportional editing header buttons, matching 3D View and other editors
  2. Added Overlays menu to the right
  3. Moved Markers and 2D Cursor from View to the overlays
  4. Moved Curve extrapolation from View to the overlays
  5. Moved "Only selected Curves Keyframes" from View to overlays and renamed slightly
  6. Removed "Show Handles" and "Only Selected Keyframes Handles" And replaced it in overlays with an Enum Menu that has "None, All, Selected" options.
  7. Removed "Automerge Keyframes" - there are several places where it could go, and the View menu isn't one of them. (It could go in the Key menu, in the "Options" button if graph editor goes to a tools system, or the sidebar, or some/all of the above)

Mockup 2

Based on suggestions from Hans Goudey, replaced "Only Selected Curves Keyframes" with an enum - the boolean is a bit confusing as turning it ON turns OFF keyframes on unselected curves. The enum currently has "All" and "Selected" as options, it could be "Selected Curves" if that is too cryptic.

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Needs Information from Developers.Jun 24 2021, 1:28 PM

Think there is not much to be done from the triaging side of things, will let the devs decide to set status to confirmed.

One suggestion I would make, regardless of where they end up in the UI, is to make Only Selected Curve Keyframes (and perhaps also Handles) default to ON, because this is *extremely* confusing to new users and the first thing I have to tell people to enable if they're doing animation and working in the graph editor. For most animators, you pretty much never want to select ALL curves. If you wanted to manipulate more than one curve at once you would manually select multiple curves. Normally you focus on one curve at a time. The default behaviour should be only selected.


This RCS entry is about how locked curves should NOT be selectable, but it stems from the same problem of users accidentally selecting curves and keys they don't want with default settings.

I kinda agree here. The problem (too many handles) is less likely to occur with simple animations/new users, and not worth the confusion. More advanced animators should have an easier time/tendency to customize to their liking / task at hand.