... and much generality for the future in reporting the sub-view division to
TrackPanel.
SetDisplay will have the effect of making one of possibly multiple views take
up all the height. Where we need to save and restore or otherwise copy the
sub-views, there is more information now than just one enum value.
... 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.
... 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.
... 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.
... Warnings have been treated as errors in Xcode project settings since 2.3.1,
and there ware warnings about using override on only some but not all overridden
virtual functions in the PrefsPanel subclasses.
Following a lengthen discussion on the quality list, consensus is this option
should always have been off by default. The main argument for not changing
it now was that 'on' is what users have come to expect.
... That is: EffectsPrefs.cpp is consistent with overrides of
EffectDefinitionInterface::GetFamily for each of the six (separately).
(The six aren't consistent with each other. LADSPA really is an acronym, but
Vamp is not.)
See VAMPEFFECTS_FAMILY, which isn't up-cased, and LADSPAEFFECTS_FAMILY,
which is. We change EffectsPrefs.cpp to match those constants.
See also where PluginManager.cpp uses
PluginDescriptor::GetEffectFamily, which is where the preferences written by
EffectsPrefs.cpp are used.
Does this break compatibility of old config files? No, because lookup of
keys in wxConfigFile is case-insensitive, as determined by the preprocessor
constant wxCONFIG_CASE_SENSITIVE, which is false for all of our platforms.
So, no real effects here, but the consistency of string literals is reassuring.
It would be better, though, not to rely on such a coincidence of literals.
Problem:
In Mouse preferences, the list of bindings has a dummy empty column, which is a workaround for getting the Tool column to be right aligned. As a result, Narrator reads the list as having 5 columns which is confusing. In addtion, when arrowing down such a list, Narrator initially just reads the contents of the first column, which is unfortunately an empty string.
Fix:
After all the columns have been inserted, the dummy column can be deleted. This workaround was suggested by some Microsoft documentation.