Notes on Selection
Selection in GUI
Selecting a View that represents a Stripable in the editor does two things:
- the View is added to the GUI side selection model for that component (Editor/Mixer)
- the underlying Stripable (if any) has its PresentationInfo marked as selected
::set_selected()method called on it. This will eventually invoke
AxisView::set_selected()(since all views are ultimately AxisViews). If the View represents a Stripable, then the Stripable will have its PresentationInfo member marked as selected. This will in turn cause the emission of
PresentationInfo::PropertyChangefor the affected Stripable, with the
what_changedargument indicating a selection change. Individual views (GUI or control surface "strips") that want to track selection status for the Stripable that they represent will have registered a handler for this signal. The handler (or any other code) can check the selected status via the Stripable's PresentationInfo state.
After this, the View is actually added to the GUI side selection
model. This process may add additional Views representing
Stripables that share selection (e.g. via a RouteGroup) with the
one initially being added. Note
::set_selected() is not called on these Views,
which would cause a recursive (and potentially expensive to
halt) re-entrant loop. In all other ways, these Stripables'
state will be modified as if
Once adding all relevant Views is
Selection::TracksChanged is emitted. This
signal will be handled by both the Editor and the Mixer
component of the UI, to ensure that
has been invoked all appropriate View objects in both
components. This ensures that the Editor, Mixer and
PresentationInfo models of selected state remain consistent.
will be emitted. All control surfaces that care about overall
selection status have a handler for this signal. This handler
will note the new set of selected Stripables and ensure that the
surface's version of that (which might potentially only involve
a single Stripable) is synchronized with it. A surface may opt
not to use this signal but instead use the
PresentationInfo::PropertyChange signal and other logic to
maintain the surface support code's selection model.
Finally, the Editor will
to ensure that any control surfaces can determine
the first selected stripable. This matters for surfaces
with only a single fader, for example.
If the selection process took place in the Mixer, the steps
taken are more or identical with what is described above, except
AxisViewSelection::RoutesChanged is emitted
and handled by the Editor to keep the two selection models in
Note that the Editor's selection model contains many more object types than the Mixer's. The former may contain automation data, control points, track views, regions and more; the latter contains only axis views and processors.
Selection from a Control Surface
The code that supports a given surface/protocol should emit one
of the following
signal will be handled by the Editor GUI component, which will
then carry out a selection modification as if it were driven
from Editor itself.
Note that surfaces should not set a Stripable's PresentationInfo selected status directly.
The View object representing a Stripable is responsible for handling a DropReferences signal from the Stripable (indicating that it is about to be deleted). It needs to do this for many reasons, but one of them is so that it can remove itself from any Selection model that it may be a part of. So, for example, a RouteTimeAxisView representing a Stripable that has just sent DropReferences must ensure the the Editor's selection model no longer includes the RouteTimeAxisView. The same process applies to MixerStrips.
Control surface elements require similar handling of DropReferences, and are thus also responsible for ensuring the consistency of any local selection state in the control surface code for a given device/protocol.