Animation: Draw channels backdrop in Timeline #105041
This PR does the following:
- Draw channels backdrop color in Timeline Editor.
- Draw Summary channel backdrop color only when expanded.*
Video demo: timeline_backdrop_when_summary_expanded.mp4
*The reason this change in the same PR is that once the backdrop colors are enabled in the Timeline, the default startup shows a reddish line in the Timleine that can be confusing.
The backdrop color for channels such as Summary and its hierarchy was drawn on all animation editors but the Timeline.
This change simply adds the Timeline editor to the check of when to draw the backdrops.
Drawing the backdrop has many benefits:
- Consistency with other animation editors.
- Easy to see at a glance that we are editing the Summary, while making the user familiar with the color of the Summary row.
- Since the Timeline editor is in the default workspace, many animators end up using it as Dopesheet at first.
Inspired by this RCS proposal.
Can we disable this color when the summary is collapsed?
I'm not sure it's good to add a big red strip at the bottom of the default Blender workspace. Feels like that draws a lot of attention when not animating.
Can we disable this color when the summary is collapsed?
Thanks for the suggestion! It indeed helps to reduce noise when not animating or necessarily looking at the list of channels/keyframes.
Added your suggestion in
a11e56c0ea, updated the PR description and attached a demo video.
I see what you mean @brecht , as this becomes more important when the timeline draws the coloured bars as well. However, instead of just bringing the timeline to the same behaviour as the dopesheet, this PR now also changes the behaviour of the dopesheet itself.
If the channel is collapsed, it doesn't make much sense to show the backdrop color.
To me the 'only colour the background when the item is expanded' isn't that nice. I see that it's a practical solution to Brecht's 'not too much red' remark, but from a data representation it seems counter-intuitive. A summary row is a summary row, regardless of whether it's collapsed or expanded, so why not show it as such?
If the red colour is considered too distracting for the timeline (which makes sense given how many different workspaces contain a timeline editor), we should redesign the timeline. That's a good idea anyway, as its features clash with the dopesheet editor and many animators have been asking for a redesign for a long time already. But let's not make the dopesheet more distracting (turning on/off bg colours) in an attempt to improve the timeline.
To me the timeline as shown in the general workspace is effectively in a compact view mode, showing only the summary line and the channel list collapsed. Personally I see no design problem removing the red color when those two conditions are met.
I don't think practically anyone using the dopesheet is going to be affected since you're just not going to set it up that way, and if you do I guess it's to explicitly create the same kind of compact view.
But I don't feel strongly about solving it one way or another, as long as we avoid the red bar in the general workspace.
I don't think practically anyone using the dopesheet is going to be affected since you're just not going to set it up that way
With this PR, the dopesheet does not draw the background colour for collapsed channels. This I don't agree with. The background colour is an indication of the channel type (overall summary, object summary, etc); it has nothing to do with the collapsed/expanded state, and IMO thus shouldn't be disabled on collapsed channels.
Basically I don't agree with this part of the patch description:
Having the channel backdrop color is useful when there are multiple levels of nesting. If the channel is collapsed, it doesn't make much sense to show the backdrop color.
Ok, I suggested to only do it when the summary channel was collapsed and everything is on a single line. I would not do it for other cases.
only do it when the summary channel was collapsed and everything is on a single line. I would not do it for other cases.
Updated PR to do that, description, and attached a video demo.
@dr.sybren could you please have a look at the demo video ^ to see if this behavior is acceptable? It's a bit inconsistent since it only applies to the summary channel but it's the best of both worlds discussed here (and the summary channel is a special case anyway).
Just to chime in as animator looking at keyframe information all day in Blender I actually find the colors very useful.
Who ever chose these colors new enough about colour theory to choose a sublte hue family to find the right balance.
Is there another alternative?
@AdamEarle the usefulness of these colors is not in doubt. This patch only removes the color when the summary is collapsed and there is a single line of keyframes.
This was discussed in yesterday's module meeting. The conclusions were:
- Having a red colour is bad to begin with, as red typically indicates warnings/errors/bad stuff.
- 'Blinking' the background colour in and out depending on the collapse state is too visually noisy.
- The summary row is important, important enough to have it pinned to the top of the dopesheet/timeline at all times, like a header in a spreadsheet. This could be done in a separate patch.
- Since all the channels have a background colour anyway, the summary row could get no background colour at all and still be uniquely identifyable.
So basically for this patch it could be altered to not draw any background colour for the summary row, regardless of collapse state.
@pablovazquez would you also be interested in working on a patch to pin the summary row to the top?
This is getting a bit out of the scope of this patch. The original idea was to simply bring the Timeline backdrop drawing in line with Dope Sheet, inspired by RCS.
To properly implement the suggestion of "not draw any background colour for the summary row" would require the removal of more code (
acf_summary_color) and the theme setting for summary (do-versions if necessary?).
I'll leave that task to whoever tackles the summary row on top. I agree that's a much nicer solution but I don't think I have the time to do it at the moment.
Pull request closed
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?