... which makes Project.cpp a bit less dependent on some details of other
classes
This puts Tags.cpp back into the big strongly connected component of the
dependency graph. That will be remedied later when Project.cpp becomes a
low-level file
... To append files during recording or import, it doesn't depend on the
subclasses of BlockFile, instead taking a factory function to which it gives
the filename; and the choice of factory function is also lifted up through the
level of class Sequence which is just above DirManager.
This frees four files from dependency cycles, including DirManager.cpp but not
yet Sequence.cpp
... 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.
... freeing three files from dependency cycles.
The class is only constructed by ODManager so move its definition there.
Meanwhile, the (now misnamed) ODTaskThread.cpp implements some thread
synchronization utilities used in several other places, not dependent now on
ODManager.cpp, and also not on ODTask.cpp.
These utilities should be eliminated in favor of standard library alternatives,
but that is a task for later.
... Send an event via the app that projects listen to for theme update; don't
push it to projects directly.
This frees three files from dependency cycles.
... There was no reason to store the help location preferences as per-project
state. Also move the dialog for quick fixes near its only use in
HelpMenus.cpp.
This takes 22 files out of the big strongly connected component, notably
the much used lower level utilities, ErrorDialog and AudacityException.
HelpSystem itself is still in a small cycle with LinkingHtmlWindow.
... when special initial population of preferences is lifted into
AudacityApp.cpp.
This takes four files out of the big strongly connected component of the graph
into low levels, but three of them (Prefs, Languages, FileNames) are still in
a small cycle. FileHistory is the fourth, depending on the others.
... 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.
