... 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.
... leaving AutoRecovery as a lower-level file, to be used by ProjectHistory
for auto-save, and not including ProjectManager.
The new file floats to a high level of the graph, but AutoRecovery.cpp
remains in the big strongly connected component.
... This should have been done with commit 4abc71c
But the C style pointer casting (bad practice!) left the mistake compilable.
I reviewed all other casts to wxWindow* in the source and this was the only
bad one.
Problem:
When the keyboard first moves to the top panel using ctrl+f6, the click to pin button in the ruler is the focus. It should be the first control in the top tooldock.
This problem was introduced by commit: 4abc71c. Prior to this commit the top tooldock was created before the ruler, and afterwards the order was reversed. The default tab order is the order of creation.
Fix:
Explicitly set the tab order of the top tooldock and the ruler, so that the creation order doesn't matter.
... 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)
