Re: per-display, per-session, etc. settings



Havoc Pennington wrote:
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.)

I still don't know why we need the idea of "partitions", or "schemas". We can extend the bonobo-config interface slightly and it would be able to handle all those things:
void addDatabase (in ConfigDatabase default_db, in string path, in DBFlags flags)
Where flags is READ, WRITE or MANDATORY. This enables us to mount/link another database somewhere inside the tree. You can also easily create a sub-database from a existing database, representing a subtree. This enables you to make virtual links inside a database, for example you can make "/desktop/ " such a virtual link, pointing to another location inside the database "/somewhere/else/host.name.com:0.0/"

My view of things is that there is one system database, which stores the default values and the documentation, located somewhere in /usr/share (just an example, may be configurable). IMO there is no need for schemas, so it is just like any other database. They layout of my databases would be something like  this:

/path/to/a/value  - a normal value (a value in the system database is a default value)
/docs/                 - this subdir contains the documentation
/display/             - virtual link used to mount display specific settings
/session/             - virtual link used to store session specific stuff

The second database is the user database inside the user home directory. The default configuration database is then simply a combination of those databases. Please notice that you can combine databases in a quite complex manner, just using the above addDatabase() function. A simple, but very powerful mechanism.

- Dietmar
 
 
 
 
 
 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]