... to break some dependency cycles. Install a callback at initialization time.
This frees CommonTrackPanelCell from cycles, which is important because it is
a base class of Track
This frees EIGHTEEN files from the big strongly connected component!!
They are:
Dependencies
Export
ExportCL
ExportFFmpeg
ExportFFmpegDialogs
ExportFLAC
EportMP2
ExportMP3
ExportOGG
ExportPCM
ExtImportPrefs
Import
ImportRaw
KeyConfigPrefs
KeyView
LibraryPrefs
PrefsDialog
SpectrumPrefs
... and that includes all of the remaining *Prefs files.
It does still leave the nine Export* files in a smaller s.c.c, which could be
broken with a registration system, as was done for import at commit e2cf1d9
... so that DeviceManager, DeviceToolbar, and PrefsDialog do not depend directly
on AudioIO.
But no function in the base class for starting streams, which would require
mention of Track types, which we want to avoid.
... New files, but (almost) empty; don't use the global variable gAudioIO,
but use one of two accessor function names (which are the same function for
now).
AudioIOBase will have fewer dependencies than AudioIO -- in particular, no
dependency on tracks.
It won't include StartStream. It will contain functions to query the
present state of streams, and device capabilities.
... confusingly, Envelope already carried its own limiting values, but those
in the TimeTrack were not guaranteed to be the same.
I'm just preserving behavior as I break file dependencies and won't try to fix
that confusion now.
... 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.
