... This only cuts and pastes some functions from FileNames to another new file
and namespace, and changes namespace qualifiers where they are called.
The cycle resulted because of the need to include widgets/ErrorDialog.h
Aside from the breakage I added to it during the AUP3 conversion,
there was several other issues discovered in regards to how the
export paths were being handled.
... as std::mutex instead.
One is the mutex for the set of all files.
Another is in Profiler.h, which is now back into CMakeLists because the header
is included in one place. Maybe this utility will find more use again.
Restored one other but commented out, as not necessary now, but need might be
found to put it back again.
The class ODLock was a misnamed thing not specific to the on-demand manager but
used more widely as a thread synchronization utility, functioning as a mutex
object. It was a mistake to remove all uses of it along with the rest of the
on-demand system.
!!! THERE WILL NO DOUBT BE BUGS !!!
This is a big one and there's still several things to
complete. Just want to get this in the wild to start
receiving feedback.
One big thing right now is that it will NOT load pre-aup3
files. An importer is on the way for that.
This removes all of the OnDemand code embedded throughout
the main codebase. Individual files related specifically
to OD have been left in place, but removed from the build.
... Reimplemented without making dependency cycles.
Project and ProjectFileManager publish events for change of active project or
change of a project title.
WindowMenus.cpp can listen for those events, so that it can update the menu
appropriately. So it's all done nonintrusively in the rest of the code.
These changes were made too close to release and are considered too dangerous for 2.4.0.
We will use the changes Leland provided. We can review these proposed changes by Paul after 2.4.0 is released.
... Reimplemented without making dependency cycles.
Project and ProjectFileManager publish events for change of active project or
change of a project title.
WindowMenus.cpp can listen for those events, so that it can update the menu
appropriately. So it's all done nonintrusively in the rest of the code.
... in places that need the TrackPanel but only to invoke common wxWindow
methods on it.
This eliminates direct use of TrackPanel by Scrubbing and ProjectWindow
... 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.
... use registered factories instead, so class AudacityProject needn't know
the other classes.
This frees 9 .cpp files, related to various non-modal dialogs, to higher
levels out of the big strongly connected component, as determined by
scripts/graph.pl!
But in reality there is still link dependency on them that the script does not
detect. The remaining dependency is via the declarations of ViewMenu,
EffectMenu, etc. in Menus.cpp.
That could be broken with a registration system for menus.
... not member functions of AudacityProject.
AdornedRulerPanel is not (yet) made similarly independent of its overlay
code.
Two .cpp files implementing overlays escape dependency cycles to higher levels.
