Split up preference data structure definition into 'pref.h'

.. and rename the badly named 'output_units/input_units' variables.

We used to have this confusing thing where we had two different units
(input vs output) that *look* like they are mirror images, but in fact
"output_units" was the user units, and "input_units" are the XML parsing
units.

So this renames them to be clearer.  "output_units" is now just "units"
(it's the units a user would ever see), and "input_units" is now
"xml_parsing_units" and set by the XML file parsers to reflect the units
of the parsed file.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Make the default preferences explicit

This makes it explicit what the default preferences are, so that we can
more easily avoid unnecessarily saving default settings.  It also makes
imperial metrics the default for the US (Burma and Liberia always get
forgotten!)

Right now we tend to be somewhat confused about defaults.  We do have
them, but then even if something has a default value, we tend to write
it out to the config file.  Which is not just unnecessary, but makes it
really hard to see after-the-fact whether the user actually wanted that
*specific* value, or whether they just wanted the default behavior.

So this prepares for having explicit configuration for when we want
something different than the defaults.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Clean up preference saving code

The old code (on purpose) didn't try to differentiate "nonexisting
boolean configuration" with "existing boolean configuration set to
false", which is problematic if we optimize the saving to not save
default preferences at all.

Which this does.

So in addition to the logic to know about default preferences, this has
to change the interfaces for the PREF_BOOL reading code so that you can
tell the difference between "no value" and "false".

And since the previous calling convention was an abomination of doing
pointer casting and having case-statements for the config types, change
that while at it.  Both from a usage perspective *and* from a back-end
perspective it is actually much simpler to just have different functions
for the string vs boolean config read/write versions.  The OSX versions
in particular end up being one-liners.

(The GConf library is a nightmare, and doesn't seem to have any way to
know whether a boolean value exists or not, so you have to read it as a
GConfVal and then turn it into a gboolean rather than just get the "oh,
it didn't exist" as an error value).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fix Windows build

Just making the code in the last commit (cross) compile on Windows.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fix Mac build

Just make the code compile on MacOS X

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>