... and LabelTrack listens to its own events, to update certain state.
This is roundabout for now, but that state is view-related and will move into
another class.
... which will simplify later rewrites that associate selection state with
the track group, not the track.
Since LabelTrack isn't notified immediately of selection changes, instead it
always tests whether it is selected, before using the stored selected label
index.
... eliminating some duplication in tables for Wave and Note track controls,
and freeing PlayableTrackButtonHandles from the big s.c.c, though in a cycle
yet with PlayableTrackControls
... and updating of them is accomplished privately in implementation files,
reducing intrusions into TrackPanel and ProjectWindow
This removes #include-s from TrackInfo.cpp, leaving dependency cycles better
than previously
... and eliminate some unnecessary calls to SubstitutePendingChangedTrack,
because the track and the substitute store Y and height in their shared
TrackView object.
Also make GetMinimizedHeight() virtual to avoid inclusion of TrackPanel.h in
TrackView.cpp.
... And Track no longer inherits TrackPanelCell, so be careful to rewrite
some dynamic_casts too to check instead for TrackView. Those casts won't fail
to recompile if not rewritten.
... but it does nothing yet.
This will be important to preserve undo/redo behavior of view changes, when
view state is moved out of the proper Track objects.
... in anticipation of making views to tracks many-to-one, but then the rulers
should be one-to-one with the views. So go through the view to get the ruler.
The ruler is really a left-hand extension for each view.
... and use std::enable_shared_from_this
Temporarily putting TrackControls.cpp back into the big s.c.c, now 59 files
Future rewriting might even eliminate all mention of those classes in
the definition of the Track classes.
... Mostly into CommonCommandFlags.cpp, but some elsewhere, to avoid giving
that new file problematic dependencies on LabelTrack, ControlToolBar, and
EffectManager.
Note that CutCopyAvailableFlag is critically ordered, for message purposes,
only with AudioIONotAvailableFlag, the only flag with a message that it combines
with in menu item definitions.
The dependency on LabelTrack.cpp might not be a bad one later, if the track and
its view can be separated, and that would allow CutCopyAvailableFlag to be
put with the others. But much other work on LabelTrack must happen first.