saving them; that's up to PrefsManager.
Treat IPreference as a simple data holder, with simple facilities for
looking them up by name, converting to/from strings, and storing to/from
an XNode, but with no application-specific code to save to disk. This
can be used alone as a way for code to configure things internally, even
for uses that have no notion of storing user preferences (eg. unit tests),
and other programs can use it to store preferences in entirely different
ways (SMPackage could use it to store to the registry). PrefsManager is
layered on top, to implement StepMania's particular use of Preference
(saving and loading INIs), but isn't needed for Preference to be useful.
This also makes Preference only use XNode, not the more specialized IniFile.
(One piece is missing: several low-level places, eg. Dialog, want to set
a preference and write it to disk immediately. The only way to do that
is to have access to PREFSMAN. FIXME.)
mostly useful for pointing casual users to drivers, but any URLs
we give them will just go out of date, and 404s don't help people.
It's also too heavyweight to be done in ArchHooks; aim to not use
anything in it that we don't want to always include.
(I'm sort of undecided about this. This definitely needs to be out
of HOOKS; it could be moved to GraphicsWindow. It's potentially
useful, in theory, but it'd be a major hassle to maintain and always
be incomplete. Since it's only used for one ancient card and has
never been used for anything else, I'm just removing it for now.)
(used by XmlFile) to depend on THEME, so use localized strings.
We may *always* want LocalizedString. One reason we may not
is if we start using the DynamicThemeMetric paradigm more.
That evaluates expressions when they're used, which allows
metrics to change dynamically. However, we may really not
want to do that for localized strings, since it would complicate
translation, so we may want to restrict localized strings to
pre-evaluation anyway.
Glenn Maynard