Although e.g. in the dopesheet there is no specific concept of
active action, displaying panels requires singling out one action
reference. It is more efficient and clearer to implement this
natively in the context rather than using selected_visible_actions[0].
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
Event Timeline
Comment Actions
One question to consider: should this be active_action or active_visible_action to match selected_visible_actions.
There is also active_editable_fcurve in the Graph Editor, I wonder if it should also have active_visible_fcurve for completeness.
Comment Actions
IMO the concept of "visible Action" is a bit weird, since Actions themselves don't have any visibility. So, for me active_action would be preferred.
There is also active_editable_fcurve in the Graph Editor, I wonder if it should also have active_visible_fcurve for completeness.
If we have a concrete need for it.
Comment Actions
It is derived from 'visible fcurve' (there are selected_visible_fcurves and selected_editable_fcurves, as well as editable_fcurves/visible_fcurves etc), which means 'visible in the current editor based on whatever filters are active'. In the end it corresponds to a filter flag given to the animation channel enumeration code.
Comment Actions
Accepting but I'd like to confirm that the active vertex shown in the UI panel should always be from the active action (if that's not the case I think it makes the concept of active less useful).
If this is not the case it should be documented that "active_action" is more of a convenience utility and doesn't work the same way "active" does elsewhere.
Also, if accessing the active action via a filter function could be made into a utility function, especially if this logic is being duplicated (BKE for example where the context isn't accessible, then that could be moved into a utility function, from a quick check it seems this may not be the case though).