... which is not yet used for anything.
It could be used to describe textual paths for attaching plug-in menu items.
Strings are only path local, not necessarily globally unique, and may be
left empty for separators and for groups that should be transparent to
path identification.
It may also be empty for certain sub-menus, such as those that group effects
according to the changeable criteria in Preferences.
... Except a few where project or plugin manager state or preferences are
needed to compute the items, so evaluation is delayed, often inside lambdas
Comment "Delayed evaluation" wherever there are exceptions
... and deduce whether to exclude from macros inside NewIdentifier, simplifying
argument lists further
Also fix the localization of "..." added to names by PluginMenus.cpp
... Let the window respond to an undo manager event instead, whenever there
is a push or modify
Maybe this makes a few unnecessary redraws that did not happen before. If
that is important, then we should figure out how to put the logic for eliding
the redraw into ProjectWindow, and the extra information needed for the
decision into the events, but not make intrusions in other code all over the
place.
... 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.
... 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.
... that is, a factory function, open, close, import, undo/redo/rollback.
Also the callbacks from AudioIO, which need to invoke undo history push when
recording stops.
It is meant as a high-level class using several of the other things attached
to the project, while AudacityProject will be a low level class acting mostly
as just the container of the attached structures.
... as a preparation for splitting up class AudacityProject.
Use ProjectWindow as an alias for AudacityProject, and fetch it from the
project with a static member function, where certain of its services are used;
pretending they are not the same class.
Use global accessor functions to get wxFrame from the project where only
wxFrame's member functions are needed, so there will be less dependency on
ProjectWindow when it becomes a distinct class.
... use registered factories instead, so class AudacityProject needn't know
the other classes.
This frees 9 .cpp files, related to various non-modal dialogs, to higher
levels out of the big strongly connected component, as determined by
scripts/graph.pl!
But in reality there is still link dependency on them that the script does not
detect. The remaining dependency is via the declarations of ViewMenu,
EffectMenu, etc. in Menus.cpp.
That could be broken with a registration system for menus.
... so that USE_* macros will be seen first, and so
EXPERIMENTAL_AUTOMATED_INPUT_LEVEL_ADJUSTMENT, for one, is correctly defined.
I hesitated actually to include Audacity.h in Experimental.h. Maybe no
need for that hesitancy. But instead I use #error if Audacity.h has not been
seen yet.
... except Audacity.h; and in no others.
Do so even if Experimental.h gets multiply included, as in both the .h and
.cpp files.
This makes it easier to do a text scan to be sure there are no unintended quiet
changes of meaning because of omission of Experimental.h when the flag is
an enabled one.
Also move inclusions of Experimental.h earlier.
Also don't require Experimental.h to be preceded by Audacity.h to define
EXPERIMENTAL_MIDI_OUT correctly.
