... The fix done at 2f9322e was undone at 43b1afc because of the unacceptable
file dependencies. This fixes it by other means. Make a null check in
SetProjectTitle in case it is invoked before ProjectWindow has been constructed;
also ensure in ProjectManager::New that it is called at least once after that.
Mac and Linux (correctly) allow files to be saved with an arbitrary
file extension, or no file extension at all. For the exported file
to be visible in the export dialog, the dialog must include an optional
wildcard for "All files".
... Four more pieces of former AudacityProject are:
1 ProjectAudioManager, for the callbacks from AudioIO
2 ProjectSelectionManager, for the callbacks from selection toolbars
3 ProjectHistory, for interacting with the undo manager
4 ProjectFileManager, combining parts that were in ProjectManager and
ProjectFileIO; it is intermediate between them
To summarize relations among the nine pieces of former AudacityProject:
ProjectManager (highest level) uses:
ProjectAudioManager, which uses ProjectAudioIO, and
ProjectFileManager, which uses ProjectSelectionManager and ProjectFileIO
Those subordinate managers are also directly used elsewhere, avoiding uses of
the top manager that would make cycles.
ProjectHistory is used in many places to make undo transactions, and it also
uses ProjectFileIO for auto-save. It uses ProjectWindow and ProjectSettings
too.
ProjectWindow is widely used, and uses ProjectAudioIO.
ProjectAudioIO and ProjectSettings are lowest-level and widely used.
Dependency of ProjectFileIO on ProjectWindow is now severed.
AutoRecovery is also split in two, with a new high-level file for a dialog.
There are thus five new .cpp files. ProjectAudioManager and ProjectHistory are
still in the big strongly connected component, as still are ProjectAudioIO,
ProjectFileIO, ProjectSettings, and ProjectWindow.
13 files, including ProjectManager, are freed from it to higher levels.
Net loss of 11, leaving 102 files.
Import file handles also use a registration system so Import.cpp doesn't depend
on them. This move was needed to free ProjectManager and others from the
cycles.
... freeing 15 files from the big strongly connected component:
ImportFFmpeg & ODDecodeFFMpegTask (still in a cycle of two)
ImportFLAC
ImportGStreamer
ImportLOF
ImportMIDI
ImportMP3
ImportOGG
ImportPCM
ImportQT
ProjectFileManager
ProjectFSCK
ProjectManager
ProjectSelectionManager
ODDecodeFlacTask
And eight header files in src/import are deleted.
This breaks a lot of cycles because Import, which is still in the big component,
no longer includes ImportLOF, which recursively uses ProjectManager. A
registration system for the subclasses of ImportFileHandle allows that
recursion without the cyclic compilation dependencies.
... The former will handle File menu items, and the choosing of file paths to
write; the latter will handle the XML contents and do auto-save. Auto-save is
a lower-level thing that must be done in many places whenever undo history
is pushed or modified.
... 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.
... 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.
... 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.