... Five new classes are split out for various special purposes, one odd thing
(the play region) is moved into ViewInfo, and very little remains in
Project.cpp and Project.h.
The five new things are intended to rank thus in the compilation dependency
hierarchy:
ProjectManager
ProjectFileIO
ProjectWindow
ProjectSettings ProjectAudioIO
And AudacityProject is lower than all.
The project class now holds the file name, status message, and a pointer
to its window, and a few other things that should perhaps go to
ProjectSettings instead.
It is also a container of other attached extension objects and window pointers,
which it treats opaquely. The several attached classes define their static
Get() functions, non-intrusively in AudacityProject.
It is also an event handler where other objects can post events or bind to
them, defining their own added event protocols non-instrusively.
The files for the new classes are still stuck in the big strongly connected
component, but Project is freed from it, with eight others -- notably
DirManager is again free (see comments at 2947a43).
The nine are:
AButton
DirManager
MissingAliasFileDialog
PCMAliasBlockFile
Project
Sequence
SilentBlockFile
SimpleBlockFile
Tags
... as a middle-level class that handles reading and writing of the .aup file
format.
There is only one small dependency on ProjectWindow for
mbInitializingScrollbar. Can that be removed, so we can just use
GetProjectFrame instead?
... as a high-level class allowed access to all of the sub-structures,
handling major events in project lifetime (creation, destruction, pushing
and resetting undo states), and also file opening and import
... 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 low-level class, to store the rate and various other per-project
values, and send an event to the Project when certain of them change (for
now, just the sync lock setting)
... 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.
