UniConf auto: configuration

[Avery Pennarun]

Hi,

I'll try to answer the various questions all at once.  Sorry if I lose the
attributions... but I'm lazy.

> Does that mean as it is planned at the moment all apps would need to be
> switched over to UniConf to make use of it?

Not at all - that's the opposite of the point of UniConf.  That's why my
example moniker pointed into gconf:, for example... so that your gnome app
can still store its stuff in gconf and be gnome-friendly.

Of course, to get *all* the advantages of UniConf, they should all use
UniConf, or you should use more kinds of frontends (for example, instead of
having uniconf store in gconf, you could have gconf store in uniconf).

> $KDEHOME/share/apps/*1

Okay, several corrections later, the example string is now:

	org/kde/apps/* = $KDEHOME/share/config/*1rc

Of course, craziness could ensue if you don't have $KDEHOME actually set to
something, so we probably have to be a bit more careful than that.

> Right, sounds great! So, galeon can access all keys this way:
> 
> 	auto:/org/gnome/apps/galeon   	(gconf:/apps/galeon)
> 	auto:/org/kde/apps		(share/apps/...)
> 	auto:/foo			(/tmp/everything-else.ini)
> 	etc

Correct, although I don't really know why galeon would want to do that :)

> Could the config file be $XDG_CONFIG_DIRS/uniconf.conf [1]? That would
> allow users to override it (for example, if I get a login somewhere else,
> I can make it get my settings from my main machine, just for my user).

That's probably a good idea.  The nice thing is that *this* particular
string is hardcoded into the UniConf library itself in only one place, so we
or a distribution maintainer can set it to whatever we/they want.

If we're feeling crazy, auto: could also use the list: moniker (since the
uniconf configuration itself is just any old uniconf moniker):

	list: default:ini:$XDG_CONFIG_DIRS/uniconf.conf \
		default:ini:/etc/uniconf.conf

> Once there's a separate release, I'll look at whether we can use it in ROX
> (we need a new config system anyway). The main requirements for us are
> that it can be easily installed, has minimal dependancies and can run
> optionally without a daemon (some of our users run on low-end systems, or
> just don't like having too many processes).

I've twiddled the uniconf makefiles a bit so it doesn't require all of
wvstreams (or the more obscure uniconf generators) anymore.  That gets us
down to a 437k "libwvbase.so" (includes uniconf, the .ini generator, and
some supporting stuff from WvStreams), and it could be reduced even further
with a bit more work (many of the included object files have more
functions/clases in them than we actually strictly need, and should be split
up).

The only outside dependency is libxplc for for making cross-platform
loadable plugins, but it's microscopic (20k).

Have fun,

Avery