per-display, per-session, etc. settings

[Havoc Pennington <hp redhat com>]

Hi,

I'm not sure how they relate, but the profiles etc. stuff was
previously planned for GConf in a slightly different way.

Here is an early writeup:
 http://mail.gnome.org/archives/gconf-list/2000-September/msg00012.html

There was some later discussion, and Colm implemented the idea of a
"partition map," and the plan changed somewhat.

But basically we specify per-key or per-directory
(e.g. /desktop/background/*) whether a setting is per-session
per-display etc. Colm has already implemented the idea of "partitions"
which lets you do that.

What's missing is a way to put a hint about which partition to use in
your schema file, and then setting up the default GConf path to
contain partitions for these various uses (per-display etc.)

This is a pretty different approach from the screenshot I saw of the
location manager. Instead of having the user choose which settings are
per-whatever, basically some things just magically end up being
per-machine or per-display or per-session and some do not.

(Sufficiently technical users can override the defaults, however.)

Anyway, I realize this mail isn't clear enough to explain it, but I
think there are a lot of advantages to transparently handling this
rather than having the user specify. Also, ultimately we don't want
this feature just for the control center but also for apps - and they
need to specify what a key is per- by default, and the logical place
to do that is in the schema file.

I believe there's also an outstanding issue with GConf not properly
handling notifications in the case where you have multiple database
stacks that contain the same database, so if you have:

    A.                   B. 
 per-:0 settings      per-:1 settings
           \            /
           global settings

Then changing global settings from config path A won't notify config
path B IIRC. But this is a bug.
      
Caveat: I haven't really looked at the Archiver stuff yet, I just
figured I'd go ahead and point out what we were thinking in this
area.

I think if we standardize on schema files and go ahead and add a hint
in there about whether a key is per-session, per-display, whatever,
then we'll be prepared for however we actually end up implementing the
per-foo settings. The hard work is going through and actually noting
for all keys what it's per-.

Havoc