... It mentions some wxWidgets types in its interface, but these are in the
acceptable utility subset of wxBase that we still consider GUI toolkit-neutral.
... but none of the methods is defined yet.
The intention is to inject dependencies on wxWidgets (or other) toolkit so that
lower-level files have less build dependency on wxCore classes or on the
event loop.
... These can happen in only two ways, using the application: from the Tools
menu, or using the Windows intaller program.
A review of all uses of wxFileConfig::DeleteAll() proves this.
The one special BoolSetting object was moved from UpdateManager to Prefs.cpp to
avoid a dependency cycle among source code files.
... the former uses Prefs, wxApp, and AudacityMessageBox, the latter has no
dependency on them.
Also move some other functions from GUIPrefs into namespace Languages.
... Expand it in AudacityApp where initializing i18n services.
Just call SetLang directly in CrashReport, because the argument was not null.
Also eliminate call to SetLang in Nyquist, where really only the system language
was needed.
... Now new project windows are opened when .aup3 files are opened; but
behavior chages only in that case.
Wherever opening of other files invoked import code, we still do or do
not make a new project in exactly the same cases as before; such as, when
opening multiple files with File > Open, be sure each imported file still opens
in its own separate window.
This means the decision whether to open a new project must be lowered into
ProjectFileManager, where the type of the file is discovered, and we pass it a
function object so it avoids a dependency cycle with ProjectManager.
It also means the checking for errors and closing of new projects in case of
failure must be replicated at all places where ProjectFileManager::OpenProject
is called directly.
The class ProjectManager::ProjectChooser simplifies this.
Recently introduced calls to SafeToOpenProjectInto(), before
ProjectManager::OpenProject(), are now lowered into that class, delaying the
safety check so it might also be called where ProjectFileManager is used
directly.
... It is false in exactly the cases where there is now also a check first for
the safety of opening a project file.
Those are the cases where a new project was made for imports, but this was not
necessary for safety. Yet old behavior will be preserved in such cases.
... It ended up not used, and long ago superseded by other TrackPanel
reorganization.
Such things as that (and many more) will be implemented with different
idioms (registries in various higher level code) without requiring changes in
this low level protocol for loading modules.
... This makes it impossible to forget to include the EXPERIMENTAL definitions
(such as when cutting and pasting code) and so get unintended quiet changes of
behavior.
The EXPERIMENTAL flags are now specified instead in new file Experimental.cmake
This will save the current log to the Audacity config directory and
a name of "lastlog.txt". This is for diagnosing errors that may
occur during Audacity exit.
Bug 2135 - Audacity crashes if launched with a locked pluginregistry.cfg file
Bug 2651 - If pluginregistry.cfg gets locked while Audacity is active the Plug-in Manager is blocked - with no help
Bug 2650 - Virgin launch fails with no pluginregistry.cfg file created
Bug 1264 - Writing to locked audacity.cfg not reported to user
Bug 2649 - Launching Audacity with a locked audacity.cfg file gives not one but three error messages - and no help
Bug 2652 - User is not warned if they launch Audacity with a locked pluginsettings.cfg file
... 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
... The 100ms sleep added at at a675b5907f was
meant to let NS framework events arrive on another thread and be detected by
wxWidgets. But there are still reports that it is not reliable enough.
This other fix may be sufficient alone, making the sleep unnecessary. But it
is harmless so we will leave it there.
... The reported continuing failure to fix bug 2437 -- sometimes -- appears to
have been a timing problem. I could observe it often with release builds but
not with debug.
