... 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.
... Rename it as SetStatus; make it part of AudacityProject not
TrackPanelListener; and use a roundabout event signalling to cause the timer
restart.
Because SetStatus will be one of very few things left in AudacityProject, but
the timer handling will be part of another class decoupled from it.
And TrackPanelListener won't really be needed: TrackPanel will not need to
pretend it doesn't know what an AudacityProject is.
... 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.
... not member functions of AudacityProject.
AdornedRulerPanel is not (yet) made similarly independent of its overlay
code.
Two .cpp files implementing overlays escape dependency cycles to higher levels.
... not member functions of AudacityProject
This puts DirManager.cpp and four others back into the big strongly connected
component of link dependencies. They will break out again when Project.cpp
becomes a low-level file.
... Generalizing what was first done at 280e8d9 for certain menu command
handlers.
Allow core data structures to host data attached by other code, on which it
need have no compilation or link dependencies.
... which makes Project.cpp a bit less dependent on some details of other
classes
This puts Tags.cpp back into the big strongly connected component of the
dependency graph. That will be remedied later when Project.cpp becomes a
low-level file
... Send an event via the app that projects listen to for theme update; don't
push it to projects directly.
This frees three files from dependency cycles.
... There was no reason to store the help location preferences as per-project
state. Also move the dialog for quick fixes near its only use in
HelpMenus.cpp.
This takes 22 files out of the big strongly connected component, notably
the much used lower level utilities, ErrorDialog and AudacityException.
HelpSystem itself is still in a small cycle with LinkingHtmlWindow.
... and break its compile dependency on CommandManager.h by letting it install
callbacks.
This also removes Objective-C mixed code from CommmandManager.
This also eliminates four inclusions of Project.h!
Capture handler state is also global, not per project, though the
CommandManager's callbacks still do depend on the active project.
