... 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.
... 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.
... 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.
