... 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.
... 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.
... To do that, hoist the call to GetActiveProject() into the factory that
makes BatchEvalCommand
Also remove unnecessary inclusion of CommandBuilder.h.
This frees Command.cpp from dependency cycles; CommandBuilder and
ScriptCommandRelay are now in a small cycle of only two.
... This involved populating it with a new registration system.
BatchEvalCommand, HelpCommand, MessageCommand escape from cycles and move
higher in the dependency graph, and CommandDirectory moves lower.
... which by default used GetActiveProject(); do that call instead at a
higher level; so that AudacityCommand.cpp does not depend on Project.cpp.
We lose the override of that for CompareAudioCommand which just did nothing.
But in fact this overload of the base class method could only be used
by EffectUIHost constructed from a command, which never happened: it was only
ever constructed from effects.
This frees two files from dependency cycles
... which called ::GetActiveProject(), but one purpose of the CommandContext
class was to eliminate many uses of that global function, because a
CommandContext must always be constructed from a reference to a project
(which was always in fact the active one), then passed around to where it is
needed!
Also, just use the project member directly -- because CommandContext was
intended as just a P.O.D (plain-old-data) structure.
This also eliminates a dependency of CommandContext.cpp on Project.cpp.
This is not enough by itself to break any dependency cycles.
... and break its compile dependency on CommandManager.h by letting it install
callbacks.
This also removes Objective-C mixed code from CommmandManager.
This also eliminates four inclusions of Project.h!
Capture handler state is also global, not per project, though the
CommandManager's callbacks still do depend on the active project.
... Unnecessary because transitively included.
But each .cpp file still includes its own .h file near the top to ensure
that it compiles indenendently, even if it is reincluded transitively later.
Problem:
1. Use either no prior config files, or set the default shortcuts to standard.
2. If a set of keyboard shortcuts is imported, then any shortcut for a command which only has a default shortcut in the full set is not set, unless it differs from the default shortcut.
This occurs because in CommandManager::HandleXMLTag(), the imported shortcut is only used if it's different from the default shortcut. But for all commands, even those commands which only have a default shortcut in the full set, GetDefaultKeyFromName() returns the default shortcut.
Fix:
Use the imported shortcut, regardless of whether it is different from the default shortcut. (I've left the function GetDefaultKeyFromName(), even though it is not longer used.)
Note:
This results in a change of behaviour:
Before: if you'd customized the shortcut for a command, then if you imported a set of shortcuts, that customized shortcut would only have been changed if the imported shortcut was also customized.
Now: If you import a set of shortcuts, then these become your shortcuts, regardless of any customizations present before the import.
I think the new behaviour is what a user would expect.
