For many things that can be Selected, there is also a state called Active. There can be 0..∞ Selected things, and 0..1 Active things. This applies to objects, bones, fcurves, fcurve keys, mesh elements, and more. These will just be referred to as thing in this task to avoid having to repeat that entire list.
The Selected and Active states are independent, so there are four states a thing can be in:
There are two states possible that can cause issues:
- There are Selected things, but none of them is Active: a sidebar/numerical/properties panel will not show information, and generally be empty without explanation why.
- There is an Active thing, but it is not Selected: this is not shown in the UI, as there is no separate color for this situation; all Active things are shown the same way regardless of them being Selected or not. This causes confusion and unexpected behaviour, and also doesn't allow for an actual clear use of this possibility.
These reports are examples of confusing situations where the disconnect between Active and Selected. The list is not exhaustive, and may be expanded later.
- T14429: selected bone is not active
- T65219: Objects don't become active object if they are selected by a box
- T68647: objects selected using box select cannot be moved to collection if there is no active object
- T81922: The Graph Editor doesn't show any curve of the Armature (if in Pose mode, but armature unselected, with box/circle/lasso tools)
This design task proposes linking Active and Selected such that:
- If there are Selected things, there is always one of those that is the Active thing.
- If a thing is Active, it is also always Selected.
Hurdles to Overcome
Rule 1. above requires that one of the selected things is marked active. There is not always a unique, obvious choice here, for example when box-selecting multiple things at the same time. In this case the choice should at least be consistent so that users know what to expect after a while. The thing closest to the mouse cursor (when using the mouse to select) could be a reasonable choice.
Rule 2. above can be dealt with in various ways:
- Create a function that returns the Active thing, and make it return nil when that thing is not also Selected. This is what was implemented for the Active Keyframe (rB983ad4210b9e). This has the downside that now nothing is active, breaking rule 1 and forcing the selection-changing code to pick another thing to become Active.
- Refuse deselection of the Active thing.
- ... something more elegant.
Goal of this Design Task
The goal of this design task is to answer the following questions:
- Is there an agreement that the current situation causes issues, and that having a stronger correlation between Active and Selected is a good thing?
- Is there an agreement that the proposed two rules are the way to go?
- How do we implement these rules in a way that makes sense to artists?
- Can we implement this in a way that can be reused by all the affected parts? Some unified selection/activation API that can be implemented for different data types?