... 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.
... In fact it was only ever different from flags when flags had the special
NoAutoSelect and mask did not. Now put that bit in the mask too, and make
the special NoAutoSelect always true in MenuManager::GetUpdateFlags(). This
still preserves the intended effects of NoAutoSelect.
... As when recording starts or stops, or the Tools button has changed, or
scrolling has changed the results of hit-test.
This reduces TrackPanel's intrusions into other code, including ProjectHistory.
Also for AdornedRulerPanel, which shares the base class CellularPanel
This frees EIGHTEEN files from the big strongly connected component!!
They are:
Dependencies
Export
ExportCL
ExportFFmpeg
ExportFFmpegDialogs
ExportFLAC
EportMP2
ExportMP3
ExportOGG
ExportPCM
ExtImportPrefs
Import
ImportRaw
KeyConfigPrefs
KeyView
LibraryPrefs
PrefsDialog
SpectrumPrefs
... and that includes all of the remaining *Prefs files.
It does still leave the nine Export* files in a smaller s.c.c, which could be
broken with a registration system, as was done for import at commit e2cf1d9
... The former will handle File menu items, and the choosing of file paths to
write; the latter will handle the XML contents and do auto-save. Auto-save is
a lower-level thing that must be done in many places whenever undo history
is pushed or modified.
... handling the callbacks from the selection toolbars.
Next ProjectFileManager will be split out of ProjectManager, and
ProjectSelectionManager will be used by it during file opening, so separating
files for it avoids a cycle.
... 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.
... To do that, hoist the call to GetActiveProject() into the factory that
makes BatchEvalCommand
Also remove unnecessary inclusion of CommandBuilder.h.
This frees Command.cpp from dependency cycles; CommandBuilder and
ScriptCommandRelay are now in a small cycle of only two.
... This involved populating it with a new registration system.
BatchEvalCommand, HelpCommand, MessageCommand escape from cycles and move
higher in the dependency graph, and CommandDirectory moves lower.
