Re: [Audacity-devel] Inconsistent default settings

[Richard A. <ri...@au...>]

On Wed, 2006-12-20 at 22:28 +0100, Markus Meyer wrote:
> Richard,
> 
> Richard Ash schrieb:
> > So we have two potential places to have a default coded into audacity?
> > One in the preferences, which only gets used after the preferences have
> > been opened, and one somewhere else (where?), which is presumably used
> > at first read of the preference.
> >   
> the default is hardcoded at every place the preference is read.
> Something like gPref->Read("/AudioIO/ShowMonkeysWhilePlaying", false).
> IIRC this was a design decision (well, using wxConfig was the design
> decision, and using wxConfig "as is" leads to this).
> 
> > I'm happy to look at it, but I think we might want to do something about
> > the underlying problem. Can we either concentrate all the defaults in
> > one place, or put them with the code that uses them, i.e. not in the
> > preferences dialogue at all, but in the code doing the work?
> >   
> We can't just put the defaults with the code that uses them because then
> the default would not easily be accessible from the pref dialog code.
That figures, and the pref dialogue needs to know them for the first
time you open the dialogue, when the settings (should) all show the
defaults.

> For putting the defaults in one place, I can think of two possible
> solutions:
> 
> 1. Use a class which has those defaults as static members. The impact of
> this is similar to an "explicit" prefs class which has a property /
> member for every preference. Dominic has repeatedly stated that he
> doesn't want this because it means that everytime a pref is added, all
> code that uses prefs (also unrelated code) has to be recompiled.
I see why this isn't desirable, also because it doesn't make
site-dependant defaults (which we currently lack) any easier.

> 2. Use a global function like GetPrefDefault() which retrieves prefs
> based on the name. This will avoid the compiling overhead of (1). This
> has to be coded by someone, but it is feasible. We could even use fancy
> macros or something like this to make the addition of new pref defaults
> really foolprof.
> 
> One problem with putting the defaults in one central location is that
> the code loses its locality (that is, the definition of the default is
> "far away" from the use of the default). Esentially, we lose locality
> put gain uniqueness. From an engineering POV it can be argued which
> property (locality vs. uniqueness) is more important in the prefs case.

Hmm, I wasn't thinking so much about our changing the defaults, but
about future proofing, and what happens when someone wants to add a new
preference for the feature they've just written a patch for.

A fairly common request from users is for a way to set up global default
audacity settings that are site-specific (the usual one is the path to
the LAME dll) for all users on a machine. This is currently impossible
or at least messy (various registry / patch-the-user's-file-system hacks
exist). What we don't have is any way of reading /etc/audacity.conf to
get a locally set up default when there isn't a setting in the
user's .audacity-data/audacity.cfg file (to use the linux files as an
example).

This means the defaults have to come out of the code altogether, and go
into a chunk of code that does the relevant manoeuvres to get a default
that is set at runtime not compile time. There would obviously still be
a compiled-in default that was used if there was neither a global nor a
local configuration file, but it moves another step back in the chain.

I think (2) would help with this, because the "read global and use if
found, else use compiled default" logic can all go in there (at a latter
date if we want to get it working sooner), and is hidden from the rest
of the code. I see what you mean about loss of locality, but if the
default is already local to two different places (the interface and the
use, effectively) it's already less useful.

Richard