Graph Editor: (Auto-)Focusing Channels #43933

New Issue

Julian Eisel · 2015-03-08T22:21:01+01:00

Julian Eisel commented

2015-03-08 22:21:01 +01:00

Graph Editor: (Auto-)Focusing Channels

There were requests about having an option to automatically focus the graph editor view on channel selection. That basically means two things would happen when a channel is selected:

Align the view to the curve of the selected channel
Hide all other channels

Now the question is how should that work and look UI-wise? Decision was already made to split the two actions into two different options/functions. Still unclear is how the user should activate them. E.g.: Using checkboxes (which gives a modal behaviour), using shortcuts, using buttons, ...

In D1128, a first implementation was done, using a single checkbox to enable both options:

(Previous discussions about this can be found in D1128)

# Graph Editor: (Auto-)Focusing Channels There were requests about having an option to automatically focus the graph editor view on channel selection. That basically means two things would happen when a channel is selected: * Align the view to the curve of the selected channel * Hide all other channels Now the question is how should that work and look UI-wise? Decision was already made to split the two actions into two different options/functions. Still unclear is how the user should activate them. E.g.: Using checkboxes (which gives a modal behaviour), using shortcuts, using buttons, ... In [D1128](https://archive.blender.org/developer/D1128), a first implementation was done, using a single checkbox to enable both options: ![0001-0133.gif](https://archive.blender.org/developer/F148044/0001-0133.gif) (Previous discussions about this can be found in [D1128](https://archive.blender.org/developer/D1128))

Julian Eisel commented

2015-03-08 22:21:01 +01:00

Changed status to: 'Open'

Julian Eisel self-assigned this 2015-03-08 22:21:01 +01:00

Julian Eisel commented

2015-03-08 22:21:01 +01:00

Added subscribers: @cessen, @BassamKurdali, @fahr, @TodorImreorov

Todor Imreorov commented

2015-03-09 09:37:38 +01:00

First-time contributor

well so far we have two ex Maya, now blender animators (me and Fahr) trying to convince two Blender developer/animators (Cessen and bassamk) that if the feature is not implemented as a workflow mode, it will loose a lot of it's convenience and usability.
It seems like the argument is mostly on the "hide unselected channels" part of the feature and how that is being triggered.

Their stance on the subject is that:

It is cluttering the view menu - it is already cluttered enough already!
It's not their preferred way of working , but they see some merit in it.
it might confuse some users who enable it by mistake- as it changes the show/hide behavior of the software- merging selection of channels with their visibility toggle switch.
- a proposal was made to make this work by holding a modifier key each time when clicking on the view icon rather than the channel name to trigger the hiding of other channel curves and the focusing on the selected ones.

Our stance is:

The view menu should be cleaned up anyway with nested menus. This should not be a reason to complicate its design so much.
We are confused as to why there is so much opposition, since it does not nullify their preferred workflow at all. It is optional.
We firmly believe that this is not a problem, since it is already done that way in other software and is even a preferred way of work to many animators who are converting to blender. Since it is not going to be the default behavior, the user will need to toggle it on and it's name is self explanatory and clear enough to communicate to the user what is being enabled.
- Both me and Fahr strongly oppose that proposal to changes in the design since it makes our proffered way of working very inconvenient as compared with how it is done in other software and was originally done in the initial patch.
  - It enforces the need to hold a modifier key each time, which gets even more convoluted when you want to apply the behavior on multiple channels- holding multiple modifier keys to do it.
  - To add to this, the proposal to click on the "view" icon rather than the channel itself also reduces the clicking pixel space.

In the last discussion at least it seems that we came to the conclusion that:

it should be split into two features to allow more flexibility

All in all it is best to read all the comments at the initial implementation here: https://developer.blender.org/D1128

well so far we have two ex Maya, now blender animators (me and Fahr) trying to convince two Blender developer/animators (Cessen and bassamk) that if the feature is not implemented as a workflow mode, it will loose a lot of it's convenience and usability. It seems like the argument is mostly on the "hide unselected channels" part of the feature and how that is being triggered. Their stance on the subject is that: - It is cluttering the view menu - it is already cluttered enough already! - It's not their preferred way of working , but they see some merit in it. - it might confuse some users who enable it by mistake- as it changes the show/hide behavior of the software- merging selection of channels with their visibility toggle switch. - a proposal was made to make this work by holding a modifier key each time when clicking on the view icon rather than the channel name to trigger the hiding of other channel curves and the focusing on the selected ones. Our stance is: - The view menu should be cleaned up anyway with nested menus. This should not be a reason to complicate its design so much. - We are confused as to why there is so much opposition, since it does not nullify their preferred workflow at all. It is optional. - We firmly believe that this is not a problem, since it is already done that way in other software and is even a preferred way of work to many animators who are converting to blender. Since it is not going to be the default behavior, the user will need to toggle it on and it's name is self explanatory and clear enough to communicate to the user what is being enabled. - Both me and Fahr strongly oppose that proposal to changes in the design since it makes our proffered way of working very inconvenient as compared with how it is done in other software and was originally done in the initial patch. - It enforces the need to hold a modifier key each time, which gets even more convoluted when you want to apply the behavior on multiple channels- holding multiple modifier keys to do it. - To add to this, the proposal to click on the "view" icon rather than the channel itself also reduces the clicking pixel space. In the last discussion at least it seems that we came to the conclusion that: - it should be split into two features to allow more flexibility All in all it is best to read all the comments at the initial implementation here: https://developer.blender.org/D1128

Chad Gleason commented

2015-03-09 20:14:18 +01:00

First-time contributor

Keep in mind that this is an alternate way of working with curves in the graph editor. A separate mode, if you will. There are many other ways to work with curves in other graph editors I've seen. I've seen a mode where all the channels you select get stacked on top of each other in the editor so you can compare them side-by-side or vertaically stacked without any overlap. If such a feature wants to be implemented into the graph editor someday, what makes more sense? Another hotkey combination or another toggle switch to a different mode in the menu?
The view menu can easily be de-cluttered with a little consolidation. We can have various channel "modes" be in their own nested directory inside the view menu.
Being able to switch between these modes makes Blender's graph editor more flexible and better for dealing with common and uncommon challenges in working with and managing curves. There doesn't have to be a "one-size-fits-all" method of working with curves, since not all challenges are the same.
Having selectable modes that the user can choose from also allows for further expansion down the road, as we now have a nested directory that has room for more modes if someone feels it would be helpful.

The graph editor ALREADY DOES THIS by the way. It has many toggle options for different behaviors (like making unselected curves hide their keyframes) and they are very welcome options. Not once have I wished to not have these features because it makes the menu look cluttered.

Keep in mind that this is an alternate way of working with curves in the graph editor. A separate mode, if you will. There are many other ways to work with curves in other graph editors I've seen. I've seen a mode where all the channels you select get stacked on top of each other in the editor so you can compare them side-by-side or vertaically stacked without any overlap. If such a feature wants to be implemented into the graph editor someday, what makes more sense? Another hotkey combination or another toggle switch to a different mode in the menu? The view menu can easily be de-cluttered with a little consolidation. We can have various channel "modes" be in their own nested directory inside the view menu. Being able to switch between these modes makes Blender's graph editor more flexible and better for dealing with common and uncommon challenges in working with and managing curves. There doesn't have to be a "one-size-fits-all" method of working with curves, since not all challenges are the same. Having selectable modes that the user can choose from also allows for further expansion down the road, as we now have a nested directory that has room for more modes if someone feels it would be helpful. The graph editor ALREADY DOES THIS by the way. It has many toggle options for different behaviors (like making unselected curves hide their keyframes) and they are very welcome options. Not once have I wished to not have these features because it makes the menu look cluttered.

Todor Imreorov commented

2015-03-09 20:32:46 +01:00

First-time contributor

why not have it both ways ? :)

As two modes that can be toggled on off and as a modifier key you can hold to get the functionality in an alternative way. The ideas dont seem to clash with each other.

why not have it both ways ? :) As two modes that can be toggled on off and as a modifier key you can hold to get the functionality in an alternative way. The ideas dont seem to clash with each other.

koil commented

2015-03-11 08:51:44 +01:00

First-time contributor

Added subscriber: @koilz

koil commented

2015-03-11 08:51:44 +01:00

First-time contributor

Based on the ideas ive added some proposals, which could be implemented.
Its up to individual developers to add consent to implement the proposals, or give feedback if the proposals are not ready for implementation.

Proposal 1

Add 2 options to the graph editor View Menu.
1: Auto Focus Channels (Automatically focus to the selected channel fcurve(s) when selected).
2: Auto Hide Channels (Automatically hide unselected channel fcurves when channels are selected).

Add 2 mouse and keyboard features to the graph editor channels region.
1: If Auto Focus Channels enabled, LMB a channel name to automatically focus to the active or selected channel fcurve(s) when selected.
2: If Auto Hide Channels enabled, LMB a channel name to automatically hide unselected channel fcurves.

Proposal 2

Add 1 option to the graph editor View Menu.
1: Auto Hide Channels (Automatically hide unselected channel fcurves when channels are selected).

Add 2 mouse and keyboard features to the graph editor channels region.
1: Ctrl+LMB a channel name to automatically focus to the active or selected channel fcurve(s) when selected.
2: If Auto Hide Channels enabled, Ctrl+LMB a channel name to automatically hide unselected channel fcurves.

Proposal 3

Add 2 mouse and keyboard features to the graph editor channels region.
1: Ctrl+LMB a channel name to automatically focus to the active or selected channel fcurve(s) when selected.
2: Ctrl+LMB one of the channel eye icons to automatically hide unselected channel fcurves, this wouldnt change the state of the eye icon pressed, picture for clarity.

Based on the ideas ive added some proposals, which could be implemented. Its up to individual developers to add consent to implement the proposals, or give feedback if the proposals are not ready for implementation. **Proposal 1** Add 2 options to the graph editor View Menu. 1: Auto Focus Channels (Automatically focus to the selected channel fcurve(s) when selected). 2: Auto Hide Channels (Automatically hide unselected channel fcurves when channels are selected). Add 2 mouse and keyboard features to the graph editor channels region. 1: If Auto Focus Channels enabled, LMB a channel name to automatically focus to the active or selected channel fcurve(s) when selected. 2: If Auto Hide Channels enabled, LMB a channel name to automatically hide unselected channel fcurves. **Proposal 2** Add 1 option to the graph editor View Menu. 1: Auto Hide Channels (Automatically hide unselected channel fcurves when channels are selected). Add 2 mouse and keyboard features to the graph editor channels region. 1: Ctrl+LMB a channel name to automatically focus to the active or selected channel fcurve(s) when selected. 2: If Auto Hide Channels enabled, Ctrl+LMB a channel name to automatically hide unselected channel fcurves. **Proposal 3** Add 2 mouse and keyboard features to the graph editor channels region. 1: Ctrl+LMB a channel name to automatically focus to the active or selected channel fcurve(s) when selected. 2: Ctrl+LMB one of the channel eye icons to automatically hide unselected channel fcurves, this wouldnt change the state of the eye icon pressed, picture for clarity. ![hide_unselected.png](https://archive.blender.org/developer/F149749/hide_unselected.png)

Todor Imreorov commented

2015-03-11 11:17:05 +01:00

First-time contributor

Proposal 1 sounds great to me. Fweeb at blenderartist had a great way of suggesting having it that way:

FWEEB: ... Perhaps the best solution is akin to what we have for snapping in the 3D View. That is, I know some modelers who have snapping enabled at all times. I personally can't stand to work that way, preferring to hold a modifier key only when I want to snap. There is the problem that this does introduce another mode that needs to be managed in the Graph Editor, though.

To me (and Fahr) it is important to have the option of these to be automatic. Meaning view options that change the graph editor's behavior - not having to hold a key at all.
But it would also be great to have the alternative way of triggering these features when these auto behaviors are not enabled- and that is of course as Cessen and Bassamk suggested and also Koliz in Proposal 1

For proposal 3, when not having the auto behaviors available, I see that it is somewhat inconvenient, not only because one needs to hold the CTRL key, but also the need to do it twice (once on the channels name and again on their view toggles)

Proposal 1 sounds great to me. Fweeb at blenderartist had a great way of suggesting having it that way: >FWEEB: ... Perhaps the best solution is akin to what we have for snapping in the 3D View. That is, I know some modelers who have snapping enabled at all times. I personally can't stand to work that way, preferring to hold a modifier key only when I want to snap. There is the problem that this does introduce another mode that needs to be managed in the Graph Editor, though. To me (and Fahr) it is important to have the option of these to be automatic. Meaning view options that change the graph editor's behavior - not having to hold a key at all. But it would also be great to have the alternative way of triggering these features when these auto behaviors are not enabled- and that is of course as Cessen and Bassamk suggested and also Koliz in Proposal 1 For proposal 3, when not having the auto behaviors available, I see that it is somewhat inconvenient, not only because one needs to hold the CTRL key, but also the need to do it twice (once on the channels name and again on their view toggles)

Bogdan Nedkov commented

2015-03-11 15:57:49 +01:00

First-time contributor

Added subscriber: @bned

Bogdan Nedkov commented

2015-03-11 15:57:49 +01:00

First-time contributor

Hello,

I just read the whole discussion and imho this feature would add a nice workflow boost to a lot of people. It saves a lot of key presses, eliminates constant zooming to find what you need and at the end of the day - a lot of time.The way I see it this feature does not hinder any existing functionality and it is giving a useful alternative workflow with a minimum amount of changes.

For me the argument that any menu in blender is too cluttered is not a valid one, especially when it comes to useful functionality. The menus are there to hold such features and not to look pretty. Plus the features in menus should not be chosen on the principle first come first serve.

Adding multiple modifier keys imo is really bad habit in blender and it leads to things like - Ctrl+Alt+Shift+C to simply change the location of the origin - a relatively often used task. I have a feeling that if there were more modifier keys on the keyboard blender would have used them all and forced the user to press 12 keys at the same time.

I hope the patch that Severin already made would be iterated upon and get into trunk asap.

Good luck to everybody involved

Hello, I just read the whole discussion and imho this feature would add a nice workflow boost to a lot of people. It saves a lot of key presses, eliminates constant zooming to find what you need and at the end of the day - a lot of time.The way I see it this feature does not hinder any existing functionality and it is giving a useful alternative workflow with a minimum amount of changes. For me the argument that any menu in blender is too cluttered is **not** a valid one, especially when it comes to useful functionality. The menus are there to hold such features and **not** to look pretty. Plus the features in menus should not be chosen on the principle first come first serve. Adding multiple modifier keys imo is really bad habit in blender and it leads to things like - Ctrl+Alt+Shift+C to simply change the location of the origin - a relatively often used task. I have a feeling that if there were more modifier keys on the keyboard blender would have used them all and forced the user to press 12 keys at the same time. I hope the patch that Severin already made would be iterated upon and get into trunk asap. Good luck to everybody involved

koil commented

2015-03-12 01:41:55 +01:00

First-time contributor

D1128 #20107
From this comment, bassamk wanted the options to be more visible, easier to switch.

D1128 #20223
From this comment Severin proposed adding the options to the View Properties panel of the properties region.

Another way could be to add two icon options to the header region, something like this picture.

[D1128](https://archive.blender.org/developer/D1128)#20107 From this comment, bassamk wanted the options to be more visible, easier to switch. [D1128](https://archive.blender.org/developer/D1128)#20223 From this comment Severin proposed adding the options to the View Properties panel of the properties region. Another way could be to add two icon options to the header region, something like this picture. ![anim_options.png](https://archive.blender.org/developer/F149973/anim_options.png)

Todor Imreorov commented

2015-03-12 02:02:27 +01:00

First-time contributor

In #43933#294974, @koilz wrote:
D1128 #20107
From this comment, bassamk wanted the options to be more visible, easier to switch.

D1128 #20223
From this comment Severin proposed adding the options to the View Properties panel of the properties region.

Another way could be to add two icon options to the header region, something like this picture.

This is a very nice mockup. :)
I am OK with that. For as long as the functionality works automatically as an operation mode that can be kept switched on/off, it doesn't matter that much where those switches are - be it two visible button toggles or two new entries in the view menu.

I actually like the buttons more. Just hope that they don't meet opposition from blender devs who might claim that the graph editor bar is already cluttered.

> In #43933#294974, @koilz wrote: > [D1128](https://archive.blender.org/developer/D1128)#20107 > From this comment, bassamk wanted the options to be more visible, easier to switch. > > [D1128](https://archive.blender.org/developer/D1128)#20223 > From this comment Severin proposed adding the options to the View Properties panel of the properties region. > > Another way could be to add two icon options to the header region, something like this picture. > > ![anim_options.png](https://archive.blender.org/developer/F149973/anim_options.png) This is a very nice mockup. :) I am OK with that. For as long as the functionality works automatically as an operation mode that can be kept switched on/off, it doesn't matter that much where those switches are - be it two visible button toggles or two new entries in the view menu. I actually like the buttons more. Just hope that they don't meet opposition from blender devs who might claim that the graph editor bar is already cluttered.

koil commented

2015-03-12 18:58:08 +01:00

First-time contributor

Im just a blender user by the way, I would be happy with any of the proposals.

Some notes.

On the other task, some of the developers didnt like the feature to be on LMB for the channel name without an option to switch it off, or a modifier key, or by pressing some other widget.

I think where to add the options can apply to any proposal with options, probably be best to ask the developers.

..

Another proposal could be to add 1 option for both features to work on LMB, Auto Focus and Hide, so proposal 4.

Proposal 4

Add 1 option to the graph editor.
1: Auto Focus and Hide (LMB a channel name to automatically focus to the selected channel fcurve(s), and hide the unselectd channel furve(s)).

..

Proposal 1, 2, and 4, can do the two features at the same time.
Proposal 2 does require a modifier key, Ctrl+LMB or double click for example, this is because Auto Focus has no option.

I can see why people like this feature, it makes curve editing more direct, quicker to zoom to and edit the desired curve, without other curves being in the way.

Im just a blender user by the way, I would be happy with any of the proposals. Some notes. On the other task, some of the developers didnt like the feature to be on LMB for the channel name without an option to switch it off, or a modifier key, or by pressing some other widget. I think where to add the options can apply to any proposal with options, probably be best to ask the developers. .. Another proposal could be to add 1 option for both features to work on LMB, Auto Focus and Hide, so proposal 4. **Proposal 4** Add 1 option to the graph editor. 1: Auto Focus and Hide (LMB a channel name to automatically focus to the selected channel fcurve(s), and hide the unselectd channel furve(s)). .. Proposal 1, 2, and 4, can do the two features at the same time. Proposal 2 does require a modifier key, Ctrl+LMB or double click for example, this is because Auto Focus has no option. I can see why people like this feature, it makes curve editing more direct, quicker to zoom to and edit the desired curve, without other curves being in the way.

koil commented

2015-03-13 17:48:49 +01:00

First-time contributor

Ive added two more proposal without options which can do both features at the same time.

Seems we cant really continue without feedback from cessen and bassamk.

@cessen @BassamKurdali
Could we have some feedback on the proposals and ideas please.
If there are any other ideas or proposals, they would be nice to read also.
If we can agree on a proposal, hopefully developers can implement one of them.

..

This is a list of the proposals.

Proposal 1

Add 2 options to the graph editor.
1: Auto Focus Channels, LMB or Shift+LMB the channel names to automatically focus to the selected channel fcurves when selected.
2: Auto Hide Channels, LMB or Shift+LMB the channel names to automatically hide unselected channel fcurves when selected.

Proposal 2

Add 1 mouse and keyboard features to the graph editor channels region.
1: Ctrl+LMB the channel names to automatically focus to the selected channel fcurves.

Add 1 option to the graph editor.
1: Auto Hide Channels, Ctrl+LMB the channel names to automatically hide unselected channel fcurves.

Proposal 3

Add 2 mouse and keyboard features to the graph editor channels region.
1: Ctrl+LMB the channel names to automatically focus to the selected channel fcurves.
2: Ctrl+LMB the channel eye icons to automatically hide unselected channel fcurves, this wouldnt change the state of the eye icon pressed.

Proposal 4

Add 1 option to the graph editor.
1: Auto Focus and Hide, LMB or Shift+LMB the channel names to automatically focus to the selected channel fcurves, and hide the unselectd channel furves, when the channels are selected.

Proposal 5

Add 1 mouse and keyboard feature to the graph editor channels region.
2: Auto Focus and Hide, Ctrl+LMB the channel names to automatically focus to the selected channel fcurves, and hide unselected channel fcurves.

Proposal 6

Add 2 mouse and keyboard feature to the graph editor channels region.
1: Auto Focus Channels, Ctrl+LMB the channel names to automatically focus to the selected channel fcurves.
2: Auto Focus and Hide, Ctrl+Shift+LMB the channel names to automatically focus to the selected channel fcurves, and hide unselected channel fcurves.

Ive added two more proposal without options which can do both features at the same time. Seems we cant really continue without feedback from cessen and bassamk. @cessen @BassamKurdali Could we have some feedback on the proposals and ideas please. If there are any other ideas or proposals, they would be nice to read also. If we can agree on a proposal, hopefully developers can implement one of them. .. This is a list of the proposals. **Proposal 1** Add 2 options to the graph editor. 1: Auto Focus Channels, LMB or Shift+LMB the channel names to automatically focus to the selected channel fcurves when selected. 2: Auto Hide Channels, LMB or Shift+LMB the channel names to automatically hide unselected channel fcurves when selected. **Proposal 2** Add 1 mouse and keyboard features to the graph editor channels region. 1: Ctrl+LMB the channel names to automatically focus to the selected channel fcurves. Add 1 option to the graph editor. 1: Auto Hide Channels, Ctrl+LMB the channel names to automatically hide unselected channel fcurves. **Proposal 3** Add 2 mouse and keyboard features to the graph editor channels region. 1: Ctrl+LMB the channel names to automatically focus to the selected channel fcurves. 2: Ctrl+LMB the channel eye icons to automatically hide unselected channel fcurves, this wouldnt change the state of the eye icon pressed. **Proposal 4** Add 1 option to the graph editor. 1: Auto Focus and Hide, LMB or Shift+LMB the channel names to automatically focus to the selected channel fcurves, and hide the unselectd channel furves, when the channels are selected. **Proposal 5** Add 1 mouse and keyboard feature to the graph editor channels region. 2: Auto Focus and Hide, Ctrl+LMB the channel names to automatically focus to the selected channel fcurves, and hide unselected channel fcurves. **Proposal 6** Add 2 mouse and keyboard feature to the graph editor channels region. 1: Auto Focus Channels, Ctrl+LMB the channel names to automatically focus to the selected channel fcurves. 2: Auto Focus and Hide, Ctrl+Shift+LMB the channel names to automatically focus to the selected channel fcurves, and hide unselected channel fcurves.

Nathan Vegdahl commented

2015-03-15 17:55:04 +01:00

Sorry for taking so long to get back to this. I was in the middle of moving, so was quite busy...

My latest proposal from the other thread seems to be missing: identical behavior to the original patch, except you click on the visibility toggle (eye icon) instead of on the channel name. I think I was perhaps unclear in my description last time, and people thought I was re-proposing my first proposal.

The benefit of this approach is it keeps visibility-related functionality on the visibility toggle instead of tying it to selection, and it still gives the single-click (no modifier key) access that people coming from Maya seem to want.

Are there any objections to this proposal? I feel like this is a reasonable compromise: it doesn't muddle the distinction between visibility and selection (my primary objection to the original proposed behavior), but you still have the desired single-click workflow from Maya et al. (seemingly the primary expressed concern of the people who want this).

Sorry for taking so long to get back to this. I was in the middle of moving, so was quite busy... My latest proposal from the other thread seems to be missing: identical behavior to the original patch, except you click on the visibility toggle (eye icon) instead of on the channel name. I think I was perhaps unclear in my description last time, and people thought I was re-proposing my first proposal. The benefit of this approach is it keeps visibility-related functionality on the visibility toggle instead of tying it to selection, and it still gives the single-click (no modifier key) access that people coming from Maya seem to want. Are there any objections to this proposal? I feel like this is a reasonable compromise: it doesn't muddle the distinction between visibility and selection (my primary objection to the original proposed behavior), but you still have the desired single-click workflow from Maya et al. (seemingly the primary expressed concern of the people who want this).

Todor Imreorov commented

2015-03-15 18:47:32 +01:00

First-time contributor

I am ok to have it - as Cessen suggested above - it seems more consistent that way too.

Would it be ok if we also split it into two (features) toggles (switched on/off in the view menu)?

Auto-Focus curves of selected channels
Auto-Hide unselected channels

That way it would be more flexible for users.
Should these be renamed to something else or this is ok?
Fahr> this seems like a good middle ground. What do you think?

I am ok to have it - as Cessen suggested above - it seems more consistent that way too. Would it be ok if we also split it into two (features) toggles (switched on/off in the view menu)? - Auto-Focus curves of selected channels - Auto-Hide unselected channels That way it would be more flexible for users. Should these be renamed to something else or this is ok? Fahr> this seems like a good middle ground. What do you think?

Nathan Vegdahl commented

2015-03-15 22:14:34 +01:00

Yeah, I think splitting it into two options is fine. As I said before, I think the graph editor is due for a spring cleaning, so we can re-examine things then, with better knowledge of what options people actually use, and how people are generally working.

But just to make sure we're on the same page: you're still using the terms "selected" and "unselected". The intent of my proposal is for it to not influence selection, just visibility. So it's rather "visible" and "not visible". It specifically only changing the behavior of what happens when you click on the eye icon.

Yeah, I think splitting it into two options is fine. As I said before, I think the graph editor is due for a spring cleaning, so we can re-examine things then, with better knowledge of what options people actually use, and how people are generally working. But just to make sure we're on the same page: you're still using the terms "selected" and "unselected". The intent of my proposal is for it to not influence selection, just visibility. So it's rather "visible" and "not visible". It specifically only changing the behavior of what happens when you click on the eye icon.

Todor Imreorov commented

2015-03-15 22:48:05 +01:00

First-time contributor

Yes, without actually selecting the channels.

But the end result is the same as the initial patch , as you said - just instead of actually selecting the channel names, the user is selecting their visibility toggles.
So in doing so, with these two enabled, the curves of these channel visibility toggles are displayed and auto-focused automatically. All the curves of other channels get auto-hidden.

So it is indeed a visibility feature that has little to do with actual channel selection, but more with curves visibility.

In this case they need to be renamed to something that makes more sense:

Auto-focus visible curves
Solo channel visibility mode

We need a test build to test the functionality and evaluate if it works well. In the initial patch I had a few notes on things like the way channel containers should also affect their children.

Yes, without actually selecting the channels. But the end result is the same as the initial patch , as you said - just instead of actually selecting the channel names, the user is selecting their visibility toggles. So in doing so, with these two enabled, the curves of these channel visibility toggles are displayed and auto-focused automatically. All the curves of other channels get auto-hidden. So it is indeed a visibility feature that has little to do with actual channel selection, but more with curves visibility. In this case they need to be renamed to something that makes more sense: - Auto-focus visible curves - Solo channel visibility mode We need a test build to test the functionality and evaluate if it works well. In the initial patch I had a few notes on things like the way channel containers should also affect their children.

Todor Imreorov commented

2015-03-15 22:52:26 +01:00

First-time contributor

Also we need to consider what to do when you want to skip selection in this solo visibility mode.

For example you would be able to click drag on channel A,B and C. But what happens when you want channel A and C. We need to have a modifier key that lets us do a shift-click multiple selection behavior on visibility toggles.

Also we need to consider what to do when you want to skip selection in this solo visibility mode. For example you would be able to click drag on channel A,B and C. But what happens when you want channel A and C. We need to have a modifier key that lets us do a shift-click multiple selection behavior on visibility toggles.

koil commented

2015-03-16 16:27:56 +01:00

First-time contributor

Im ok with this proposal but I do see a problem/limitation.

If you make the features based on visibility, i.e. Auto Focus to Visible FCurves, the user can only focus to the set of visible curves.
If more than one curve is visible, there is no way to auto focus to one of the visible curves.

Im not sure if I fully understand the proposal.

Im ok with this proposal but I do see a problem/limitation. If you make the features based on visibility, i.e. Auto Focus to Visible FCurves, the user can only focus to the set of visible curves. If more than one curve is visible, there is no way to auto focus to one of the visible curves. Im not sure if I fully understand the proposal.

koil commented

2015-03-18 16:13:07 +01:00

First-time contributor

Ive added a proposal based on ideas above.

From what I gather cessen wanted the same functionality as the original patch, but using the channel visibility options (eye icons).
To make this possible, the way the channel visibility options are set/cleared is changed from toggle on/off to select/selectmore.

Proposal 7

Add 1 option to the graph editor.
1: Auto Focus to Visible FCurves, change the way the channel eye icons are set/cleared, from toggle on/off to select/shift+selectmore, when the channel eye icons are selected (LMB, Shift+LMB) the graph editor will focus to the visible fcurves.

Ive added a proposal based on ideas above. From what I gather cessen wanted the same functionality as the original patch, but using the channel visibility options (eye icons). To make this possible, the way the channel visibility options are set/cleared is changed from toggle on/off to select/selectmore. **Proposal 7** Add 1 option to the graph editor. 1: Auto Focus to Visible FCurves, change the way the channel eye icons are set/cleared, from toggle on/off to select/shift+selectmore, when the channel eye icons are selected (LMB, Shift+LMB) the graph editor will focus to the visible fcurves.

Nathan Vegdahl commented

2015-03-19 17:38:09 +01:00

@koliz:

If you make the features based on visibility, i.e. Auto Focus to Visible FCurves, the user can only focus to the set of visible curves.
If more than one curve is visible, there is no way to auto focus to one of the visible curves.

Unless I'm misunderstanding what you're getting at, I think that's actually even more of a problem with the original patch's behavior. One of the benefits of dissociating the auto-solo/auto-focus behavior from selection is that it leaves us open to be able to select channels and hit a hotkey to focus them, without altering visibility. You can't do that when selection affects visibility, as in the patch.

1: Auto Focus to Visible FCurves, change the way the channel eye icons are set/cleared, from toggle on/off to select/shift+selectmore, when the channel eye icons are selected (LMB, Shift+LMB) the graph editor will focus to the visible fcurves.

This is basically what I intended with my latest proposal: when this mode is enabled, the visibility toggles get selection-like behavior, exactly as you describe. So yes, I think we're on the same page now! :-)

@koliz: > If you make the features based on visibility, i.e. Auto Focus to Visible FCurves, the user can only focus to the set of visible curves. > If more than one curve is visible, there is no way to auto focus to one of the visible curves. Unless I'm misunderstanding what you're getting at, I think that's actually even more of a problem with the original patch's behavior. One of the benefits of dissociating the auto-solo/auto-focus behavior from selection is that it leaves us open to be able to select channels and hit a hotkey to focus them, without altering visibility. You can't do that when selection affects visibility, as in the patch. > 1: Auto Focus to Visible FCurves, change the way the channel eye icons are set/cleared, from toggle on/off to select/shift+selectmore, when the channel eye icons are selected (LMB, Shift+LMB) the graph editor will focus to the visible fcurves. This is basically what I intended with my latest proposal: when this mode is enabled, the visibility toggles get selection-like behavior, exactly as you describe. So yes, I think we're on the same page now! :-)

koil commented

2015-03-19 19:01:05 +01:00

First-time contributor

I understand, that makes more sense.
Its good to know the main logic of the proposal is correct, I guess it could be improved sometime.

Thanks for posting.

I understand, that makes more sense. Its good to know the main logic of the proposal is correct, I guess it could be improved sometime. Thanks for posting.

Todor Imreorov commented

2015-03-20 10:48:11 +01:00

First-time contributor

I think we've come to a agreement for a design. What's left now is to test it out in another patch+test build.

That is unless someone else sees an issue with it. I was at first concerned that having the view toggles instead of channels would add a limitation, but Cessen's last post convinced me it will be alright:

when this mode is enabled, the visibility toggles get selection-like behavior, exactly as you describe. So yes, I think we're on the same page now! :-)

Cant wait to try out a build with the new design proposal! :)

I think we've come to a agreement for a design. What's left now is to test it out in another patch+test build. That is unless someone else sees an issue with it. I was at first concerned that having the view toggles instead of channels would add a limitation, but Cessen's last post convinced me it will be alright: >when this mode is enabled, the visibility toggles get selection-like behavior, exactly as you describe. So yes, I think we're on the same page now! :-) Cant wait to try out a build with the new design proposal! :)

koil commented

2015-03-22 23:36:22 +01:00

First-time contributor

Heres my views on the proposals.

Proposal 1
Seems ok, use options to change what happens when pressing LMB on the channel names.

Proposal 2
Problem: Options to enable features on Ctrl+LMB, seems odd.

Proposal 3
Problem: Features dont work at the same time.

Proposal 4
Problem: Cant focus to one visible curve without hiding others.

Proposal 5
Problem: Cant focus to one visible curve without hiding others.

Proposal 6
Seems ok, use Ctrl+LMB to focus to selected, use Ctrl+Shift+LMB to focus to selected and hide unselected, no options required.

Proposal 7
Seems ok, requires a way to focus to one visible curve without hiding others.
Cessen proposed to add a normal operator with a hotkey, F Key for example, to focus to selected curves.

Heres my views on the proposals. **Proposal 1** Seems ok, use options to change what happens when pressing LMB on the channel names. **Proposal 2** Problem: Options to enable features on Ctrl+LMB, seems odd. **Proposal 3** Problem: Features dont work at the same time. **Proposal 4** Problem: Cant focus to one visible curve without hiding others. **Proposal 5** Problem: Cant focus to one visible curve without hiding others. **Proposal 6** Seems ok, use Ctrl+LMB to focus to selected, use Ctrl+Shift+LMB to focus to selected and hide unselected, no options required. **Proposal 7** Seems ok, requires a way to focus to one visible curve without hiding others. Cessen proposed to add a normal operator with a hotkey, F Key for example, to focus to selected curves.

Chad Gleason commented

2015-03-23 16:01:21 +01:00

First-time contributor

I'm ok with Cessen's proposal it as long as the goals are achieved, doesn't have to use modifier keys or increase the number of clicks and it allows development on the feature to continue.

Todor Imreorov commented

2015-03-24 17:20:38 +01:00

First-time contributor

if it poses any serious complications to implement as two separate toggle features, I propose to have these two as a single feature - the way it was in the original patch. They seem to work well hand in hand and I would personally love to have them both on all the time.

Speaking of which, a user at BA suggested that the auto-focus toggle state is saved in the blend file, so as not to have to re-enable it every time we reopen the file.

I like the idea of toggling the focus option, personally I would have focus turned on at all times, as long as the tic is saved with the file I'm very happy with the concept

We really want this feature to get in and hope that it's development will continue asap :)

if it poses any serious complications to implement as two separate toggle features, I propose to have these two as a single feature - the way it was in the original patch. They seem to work well hand in hand and I would personally love to have them both on all the time. Speaking of which, a user at BA suggested that the auto-focus toggle state is saved in the blend file, so as not to have to re-enable it every time we reopen the file. >I like the idea of toggling the focus option, personally I would have focus turned on at all times, as long as the tic is saved with the file I'm very happy with the concept We really want this feature to get in and hope that it's development will continue asap :)

Todor Imreorov commented

2015-07-18 17:41:56 +02:00

First-time contributor

I brought this up again at blender artist:
http://blenderartists.org/forum/showthread.php?376288-Unnecessary-workflow-slowdowns-and-how-they-could-be-improved/page2

After thinking about it some more, I think clicking on the eyeballs is better than nothing, but it is still less good than having the auto-hide curves action be triggered by just selecting channels.

Why?
You are making the animator do two steps in order to get both features.

Click on all the eyeball icons of curves to hide all curves that werent clicked
selecting all the channels to get them normalized.

Imagine doing this for 10 channels. 2 steps on 10 channels = 20 clicks.

In maya this is done in one step when these toggles are on and is a default behavior.

1 step for 10 channels = 10 clicks

I brought this up again at blender artist: http://blenderartists.org/forum/showthread.php?376288-Unnecessary-workflow-slowdowns-and-how-they-could-be-improved/page2 After thinking about it some more, I think clicking on the eyeballs is better than nothing, but it is still less good than having the auto-hide curves action be triggered by just selecting channels. Why? You are making the animator do two steps in order to get both features. 1. Click on all the eyeball icons of curves to hide all curves that werent clicked 2. selecting all the channels to get them normalized. Imagine doing this for 10 channels. 2 steps on 10 channels = 20 clicks. In maya this is done in one step when these toggles are on and is a default behavior. 1 step for 10 channels = 10 clicks

Todor Imreorov commented

2015-07-18 17:43:20 +02:00

First-time contributor

what is more important - fast workflow or design consistency?

Perhaps have both actions be triggered by clicking on the eyeball icons?

what is more important - fast workflow or design consistency? Perhaps have both actions be triggered by clicking on the eyeball icons?

Nathan Vegdahl commented

2015-07-20 05:55:54 +02:00

@TodorImreorov

You are making the animator do two steps in order to get both features.

Click on all the eyeball icons of curves to hide all curves that werent clicked

selecting all the channels to get them normalized.

I think that's not how the agreed proposal works. The idea is that you can tie both visibility and auto-focus to the eye icon, so you click it once and you get both behaviors. And then you still have selection as an orthogonal thing you can do.

Unless you meant something else by "normalized"?

@TodorImreorov > You are making the animator do two steps in order to get both features. > 1. Click on all the eyeball icons of curves to hide all curves that werent clicked > 2. selecting all the channels to get them normalized. I think that's not how the agreed proposal works. The idea is that you can tie both visibility _and_ auto-focus to the eye icon, so you click it once and you get both behaviors. And then you still have selection as an orthogonal thing you can do. Unless you meant something else by "normalized"?

Todor Imreorov commented

2015-07-20 08:41:08 +02:00

First-time contributor

Ah I see, sorry I misunderstood it.

Having both be optionally triggered by the eyeball icons sounds like it would work just fine. :)

It would be great to have a good test of this design before it goes to trunk.

Ah I see, sorry I misunderstood it. Having both be optionally triggered by the eyeball icons sounds like it would work just fine. :) It would be great to have a good test of this design before it goes to trunk.

Todor Imreorov commented

2015-07-20 12:35:31 +02:00

First-time contributor

Do you guys think the toggles should be in the menu, or should they be in the form of buttons?

In case they are buttons, I think it would be more intuitive to find them above the channels list, rather than the bottom panel.
Actually it would make more sense for other buttons to be there too. Here I made a mockup a while ago:

With the new buttons I guess it might look like this:

wiki entry here
http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Better_gui_for_animators#Graph_editor-_Better_Layout.21

I guess this should be for another design task- for the UI team. Right now all we want is the actual functionality :)

Do you guys think the toggles should be in the menu, or should they be in the form of buttons? >![anim_options.png](https://archive.blender.org/developer/F149973/anim_options.png) In case they are buttons, I think it would be more intuitive to find them above the channels list, rather than the bottom panel. Actually it would make more sense for other buttons to be there too. Here I made a mockup a while ago: ![dopeSheet.png](https://archive.blender.org/developer/F210067/dopeSheet.png) With the new buttons I guess it might look like this: ![graphEditorMockup.png](https://archive.blender.org/developer/F210073/graphEditorMockup.png) wiki entry here http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Better_gui_for_animators#Graph_editor-_Better_Layout.21 I guess this should be for another design task- for the UI team. Right now all we want is the actual functionality :)

bassam kurdali commented

2015-07-22 01:03:12 +02:00

Looks neat, I think the second varient where channel buttons are above the channels is more obvious; splitting channel specific settings there is much better than everything in the header.

Anderson Omori commented

2015-09-01 22:44:51 +02:00

First-time contributor

Added subscriber: @AndersonOmori

Todor Imreorov commented

2016-01-02 17:55:15 +01:00

First-time contributor

Any progress on this? I hope it's not abandoned :)

Julian Eisel commented

2016-01-04 16:26:05 +01:00

It is not abandoned. It's still one of many things on my todo list ;)

Julian Eisel commented

2016-02-11 02:26:33 +01:00

I'd still like to work on this at some point again, but I totally lost track about the discussion. Could somebody recap the discussion results? Just so I don't have to fight myself through the wall of text here and in D1128 :)

I'd still like to work on this at some point again, but I totally lost track about the discussion. Could somebody recap the discussion results? Just so I don't have to fight myself through the wall of text here and in [D1128](https://archive.blender.org/developer/D1128) :)

koil commented

2016-02-14 01:49:01 +01:00

First-time contributor

The two main original features were:
1: Show only selected and hide unselected channels when selecting a channel name.
2: Auto focus to the curve when selecting the channel name (or names) for the curve(s).

The design discussion was, how the user should enable and use these features.

For me as a user, proposals 1 and 6 seemed to be the best proposals.

Proposal 1

Add 2 options to the graph editor, to change what LMB does when selecting channel names.
1: Auto Focus Channels, LMB or Shift+LMB the channel names to automatically focus to the selected channel fcurves when selected.
2: Auto Hide Channels, LMB or Shift+LMB the channel names to automatically hide unselected channel fcurves when selected.

Proposal 6

Add 2 mouse and keyboard features to the graph editor channels region.
1: Auto Focus Channels, Ctrl+LMB the channel names to automatically focus to the selected channel fcurves.
2: Auto Focus and Hide, Ctrl+Shift+LMB the channel names to automatically focus to the selected channel fcurves, and hide unselected channel fcurves.

Proposal 7

I think @cessen wanted to keep selecting channel names, and auto focus separate, so it didnt cause conflicts when selecting channel names.
@cessen proposed using the channel visibilty icon for the Auto Focus and Show Only Selected features.

https://developer.blender.org/T43933#296344

Other Ideas

Another idea was, if options/properties were going to be used, for them to be added as icons to the graph editor header regions, so theyre easier/quicker to find and enable.

Another idea was to move the View/Channel Properties to the Channels Region.
https://developer.blender.org/T43933#322827

The two main original features were: 1: Show only selected and hide unselected channels when selecting a channel name. 2: Auto focus to the curve when selecting the channel name (or names) for the curve(s). The design discussion was, how the user should enable and use these features. For me as a user, proposals 1 and 6 seemed to be the best proposals. **Proposal 1** Add 2 options to the graph editor, to change what LMB does when selecting channel names. 1: Auto Focus Channels, LMB or Shift+LMB the channel names to automatically focus to the selected channel fcurves when selected. 2: Auto Hide Channels, LMB or Shift+LMB the channel names to automatically hide unselected channel fcurves when selected. **Proposal 6** Add 2 mouse and keyboard features to the graph editor channels region. 1: Auto Focus Channels, Ctrl+LMB the channel names to automatically focus to the selected channel fcurves. 2: Auto Focus and Hide, Ctrl+Shift+LMB the channel names to automatically focus to the selected channel fcurves, and hide unselected channel fcurves. **Proposal 7** I think @cessen wanted to keep selecting channel names, and auto focus separate, so it didnt cause conflicts when selecting channel names. @cessen proposed using the channel visibilty icon for the Auto Focus and Show Only Selected features. https://developer.blender.org/T43933#296344 **Other Ideas** Another idea was, if options/properties were going to be used, for them to be added as icons to the graph editor header regions, so theyre easier/quicker to find and enable. Another idea was to move the View/Channel Properties to the Channels Region. https://developer.blender.org/T43933#322827

Aaron Carlisle commented

2016-02-20 19:13:28 +01:00

Added subscriber: @Blendify

Todor Imreorov commented

2016-06-16 02:13:05 +02:00

First-time contributor

This comment was removed by @TodorImreorov

*This comment was removed by @TodorImreorov*

Todor Imreorov commented

2016-06-16 02:15:40 +02:00

First-time contributor

I dont think its simply a user interface change proposal feature. It is a workflow automation feature that other software already has had for years - leading blender in the animation department.

Todor Imreorov commented

2016-06-16 04:44:16 +02:00

First-time contributor

Added subscriber: @nathan-45

Todor Imreorov commented

2016-06-16 04:44:16 +02:00

First-time contributor

@cessen
Do you approve this design:

It seems to solve everyone's concerns.
I thought that it's the best middle ground. I think partly why this is stuck in limbo for a year is the lack of communication here on the design.

This feels very much like bike shedding at this point. User interface discussions has kept this actual animation graph editor FEATURE from being implemented. Meanwhile a lot of other software has had it for years - software you can look for as example of interface presentation.

@cessen Do you approve this design: >![anim_options.png](https://archive.blender.org/developer/F149973/anim_options.png) It seems to solve everyone's concerns. I thought that it's the best middle ground. I think partly why this is stuck in limbo for a year is the lack of communication here on the design. This feels very much like bike shedding at this point. User interface discussions has kept this actual animation graph editor FEATURE from being implemented. Meanwhile a lot of other software has had it for years - software you can look for as example of interface presentation.

Nathan Houghton commented

2016-06-16 06:41:24 +02:00

First-time contributor

Removed subscriber: @nathan-45

Nathan Houghton commented

2016-06-16 06:41:44 +02:00

First-time contributor

Added subscriber: @nathan-45

Nathan Houghton commented

2016-06-16 06:41:44 +02:00

First-time contributor

Wrong Nathan I think....

Nathan Houghton commented

2016-06-16 06:42:04 +02:00

First-time contributor

Removed subscriber: @nathan-45

Todor Imreorov commented

2016-06-16 12:34:53 +02:00

First-time contributor

ah sorry, I just copied the name from an earlier comment by @koliz

Todor Imreorov commented

2016-06-16 12:37:01 +02:00

First-time contributor

Added subscriber: @nathan-45

Sybren A. Stüvel commented

2019-12-06 12:01:11 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2019-12-06 12:01:11 +01:00

There is no concrete plan/schedule here, so I'm moving this task to the 'Postponed' workboard in favour of the more recent proposal in #68962 (Graph Editor: Link Visible and Selected states).

Having the auto-zoom feature looks pretty nice as well, but IMO we should separate that from the feature proposed in #68962 (Graph Editor: Link Visible and Selected states).

There is no concrete plan/schedule here, so I'm moving this task to the 'Postponed' workboard in favour of the more recent proposal in #68962 (Graph Editor: Link Visible and Selected states). Having the auto-zoom feature looks pretty nice as well, but IMO we should separate that from the feature proposed in #68962 (Graph Editor: Link Visible and Selected states).

Julian Eisel removed their assignment 2019-12-09 15:32:30 +01:00

Julian Eisel commented

2019-12-09 15:32:30 +01:00

I won't have the time to look into this anytime soon. I'll leave it up to the animation team what to do with the task/proposal.

Adam Smith commented

2020-10-01 10:36:07 +02:00

First-time contributor

Added subscriber: @Adam.S

Adam Smith commented

2020-10-01 10:36:07 +02:00

First-time contributor

Man, I'm really having a hard time dealing with Blender's Graph editor, it's missing so many quality of life features like this one.
It's shame there is not enough developers to take care of it. it's the bread and butter for the Animators.

Man, I'm really having a hard time dealing with Blender's Graph editor, it's missing so many quality of life features like this one. It's shame there is not enough developers to take care of it. it's the bread and butter for the Animators.

Philipp Oeser removed the

Interest

Animation & Rigging

label 2023-02-09 14:36:52 +01:00

sanek122005 commented

2023-07-12 20:19:30 +02:00

First-time contributor

probably, it was fulfilled by #104523

Sybren A. Stüvel commented

2023-07-13 15:47:46 +02:00

There's quite a lot of discussion history here, and I don't want to close this task just because it's old -- there's plenty of gold to be found here.

Could someone go over the discussions, compare things to how Blender currently behaves, and make an overview of proposed changes? That way we have a more concrete picture of what could still be done.

There's quite a lot of discussion history here, and I don't want to close this task just because it's old -- there's plenty of gold to be found here. Could someone go over the discussions, compare things to how Blender currently behaves, and make an overview of proposed changes? That way we have a more concrete picture of what could still be done.

Nathan Vegdahl commented

2023-07-14 10:37:17 +02:00

@dr.sybren Yeah, I'll do that. (Especially since I was apparently part of the original discussion! So long ago...) I'll get to it some time next week.

Nathan Vegdahl commented

2023-07-18 17:32:03 +02:00

Here's my summary:

There are two features being discussed here that many animators want:
1: An option to tie f-curve visibility to channel selection, so that only the f-curves of selected channels are visible.
2: An option to auto-frame the f-curves of channels upon selection.
9-years-ago-me was concerned about keeping selection side-effect free, for consistency with other parts of Blender, and because when selecting channels for other reasons (e.g. to operate on them) it can be obnoxious to have all other curves disappear when you might want them for context.
9-years-ago-me subsequently proposed an alternate version of these options, where they change the behavior of clicking on the channel's visibility icon rather than the channel itself. Then clicking on the channel itself is still reserved as a side-effect-free selection operation.

With 9 years of hindsight, and reading this all afresh, I think I was putting too many eggs in the consistency basket. "A foolish consistency..." and all that. Moreover, in retrospect I think the visibility icon proposal is a little silly, since that's just as worth keeping consistent in its behavior as selection.

Importantly, two options have been added to Blender since this discussion took place that in combination achieve feature 1:

"Unselected Opacity": setting this to zero hides the line part of unselected f-curves.
"Only Show Selected F-Curve Keyframes": enabling this hides the keyframes and handles of unselected f-curves.

So in short, I think(?) feature 1 is already addressed now. Moreover, it's addressed in a more flexible way than either my proposal or what was originally requested. For example, users can also choose to just make unselected f-curve lines extremely faded instead of completely hidden, which preserves context while keeping the selected f-curves clear and prominent.

As for feature 2, I think it makes sense to implement on-selection auto-framing. It's probably best to split that into two options: vertical auto-frame and horizontal auto-frame. That way animators can enable whatever combination of the two is most useful to their personal workflow. For example, I would find vertical auto-framing useful, but I intentionally zoom into the time range (horizontal) of the part of an animation I'm currently working on, and having that destroyed every time I selected a different channel would be a nightmare for me.

Here's my summary: - There are two features being discussed here that many animators want: 1: An option to tie f-curve visibility to channel selection, so that only the f-curves of selected channels are visible. 2: An option to auto-frame the f-curves of channels upon selection. - 9-years-ago-me was concerned about keeping selection side-effect free, for consistency with other parts of Blender, and because when selecting channels for other reasons (e.g. to operate on them) it can be obnoxious to have all other curves disappear when you might want them for context. - 9-years-ago-me subsequently proposed an alternate version of these options, where they change the behavior of clicking on the channel's visibility icon rather than the channel itself. Then clicking on the channel itself is still reserved as a side-effect-free selection operation. With 9 years of hindsight, and reading this all afresh, I think I was putting too many eggs in the consistency basket. "A foolish consistency..." and all that. Moreover, in retrospect I think the visibility icon proposal is a little silly, since that's just as worth keeping consistent in its behavior as selection. Importantly, two options have been added to Blender since this discussion took place that in combination achieve feature 1: - "Unselected Opacity": setting this to zero hides the line part of unselected f-curves. - "Only Show Selected F-Curve Keyframes": enabling this hides the keyframes and handles of unselected f-curves. So in short, I think(?) feature 1 is already addressed now. Moreover, it's addressed in a more flexible way than either my proposal or what was originally requested. For example, users can also choose to just make unselected f-curve lines *extremely faded* instead of completely hidden, which preserves context while keeping the selected f-curves clear and prominent. As for feature 2, I think it makes sense to implement on-selection auto-framing. It's probably best to split that into two options: vertical auto-frame and horizontal auto-frame. That way animators can enable whatever combination of the two is most useful to their personal workflow. For example, I would find vertical auto-framing useful, but I intentionally zoom into the time range (horizontal) of the part of an animation I'm currently working on, and having that destroyed every time I selected a different channel would be a nightmare for me.

❤️ 1

Sign in to join this conversation.