... 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.
... Just one low-level function to simply set the variable, and one
high-level function that also pushes notifications. The danger of infinite
recursion in the toolbar code, as in the previous commit, doesn't exist here.
... Just one low-level function for each that simply sets; just one high-level
function for each that also pushes notifications; and to make that work,
toolbars need some rewriting to avoid recursion when the notifications they
post come back to them.
... use static Get() functions instead in the several classes.
This improves the results of scripts/graph.pl, freeing nine files from cycles
to higher levels. However there is really still a dependency on them from
the big strongly connected component, via menu code, which the script does
not detect.
... 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.
... instead, each of the related objects has a static Get function taking
a reference to a project.
The attached object system introduced at commit af039f1 now manages the
objects' lifetimes. The call to BuildAll in the constructor of
AudacityProject guarantees that all are created, without Project.cpp needing
to know the definitions of all of the classes.
This requires the implementations of those objects to include Project.h, but
makes Project.h unnecessary for client code that retrieves those objects, and
removes need for Project.cpp to include the header files for the objects.
Three files get freed from the big strongly connected component found by
scripts/graph.pl at high levels, but five low-level files are put back into it
because DirManager.cpp needs Project.h.
The intention is that AudacityProject will become little more than a container
for these objects and a source of events that other objects post on it. That
will make Project.cpp a low-level file after everything else moves out, and
that will free DirManager.cpp and others again from cycles.
... 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.
This was caused by commit: 7c0d05f
Problems:
1. LabelDialog::Show() is called both when dialog opens and closes, so SetFocus() was being called when the dialog closed.
2. The call for SetFocus() was only needed for mac and linux, and it would have been better to #ifdef it to prevent unforeseen bugs on other platforms.
This commits fixes the two issues.
... 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.
