Page MenuHome

Remember active fcurve when selecting other bones

Authored by Jacques Lucke (JacquesLucke) on Feb 6 2019, 3:35 PM.



Got this request from @Hjalti Hjálmarsson (hjalti).
It already works for objects.

Looks like this request is directly contrary to rB0fcfe8993e63d.
Commenting the code below out, makes it work; at least in my simple tests.
I don't really understand the implications of that change yet.

Note: I didn't add anyone as a reviewer, because we should clarify
the expected behavior first.

Diff Detail

rB Blender

Event Timeline

This seems to be a feature that was made for a reason but I can't for the life of me come up with a scenario where it's useful.

If I select a bone and highlight a channel I'll get the info of the modifiers of that bone (for example) and I would expect to get that information again if I re-select it, just like it works in Object mode, but right now this code forces all the channels to be highlighted every time you select a bone so you'll have to re-highlight the channel. Every single time.

Is this the case of it being useful in a niche case a long time ago that doesn't exist anymore?

Can someone please give me an example where this is a good thing?

@Joshua Leung (aligorith), do you know the reason why this code exists/was necessary in the first place.

Otherwise I'll get rid of it next week.

It would make some sense that if you select a bone, you can then also immediately edit its drivers or modifiers in the animation editors.

The problem is that a bone has multiple channels and the sidebar only shows one channel. It can't really work and instead gets in the way by always activating the first channel.

So I also do not see a good reason to have this behavior in the current state.

  • remove syncing fcurve selection with bones

Selection syncing is implemented for other things as well.
For example, selecting a node with fcurves selects all the fcurves.

It might make sense to remove this behavior completely, maybe...

Harbormaster completed remote builds in B2949: Diff 13721.
This revision is now accepted and ready to land.Feb 19 2019, 3:45 PM
This revision was automatically updated to reflect the committed changes.