config daemon/library for 4.6

[Brian J. Tarricone]

Hey guys,

Just spent a few hours hacking together a config daemon and library
sorta somewhat based on Jannis' spec[1].

I changed the name to 'Xfconf' to avoid confusion with the old MCS
system and libraries.  The dbus interface is basically the same with a
couple cosmetic changes and some functional changes to the GUI-related
stuff.  You can take a look at my interface definition at [2].

It's not complete.  It compiles, but there's no configuration store
backend (well, there is one, but the get/set parts aren't implemented
yet).  The client library should be functionally complete (though I'm
not sure I'm happy with the API yet), and the daemon runs but doesn't
really do all that much.

You can take a look at what I have so far in my sandbox svn repo[3].

The client API has a bunch of functions for getting/setting properties
that look sorta like this:

gboolean xfconf_channel_get_int(XfconfChannel *channel,
                                const gchar *property,
                                gint *value);

A few open questions:

1.  I don't really like this all that much, but I want an API where you
can tell from the return if the property was or wasn't in the config
store at all (in this case, by the gboolean return type).  Any thoughts
on a better way?

2.  I also wonder if we need a way to remove properties entirely?

3.  Would the model used for XfceRc work better?  XfceRc doesn't have a
true/false return, but instead has an extra 'fallback' parameter which
gets returned instead if the value isn't in the config file.  This
works well in situations where you want to have a default value if one
isn't set yet, without having a bunch of if/else trees.

4.  There's a string list property API that I'm not thrilled with.
Another option is to be HAL-like, and have list append/prepend/remove
functions instead of just a single set function.

5.  Do we even need a string list property API?

6.  I plan on adding a generic set/get pair to the API so you can set
(semi-)arbitrary GValue types.  Useful?

7.  I plan on adding a simple client-side transaction type thing where
you can start a transaction, and then anything you change gets queued
until you end the transaction, after which everything is sent.  Does
this seem useful?  Also, obviously a client-side transaction system
isn't atomic since it will send over each property change one by one
upon commit.  Does this reduce the usefulness?

8.  I'm planning on adding a special read-only backend that can be used
to seamlessly migrate over all old MCS settings, but I haven't quite
decided how I want to do it yet.

9.  There's no GUI in the daemon; in fact, it doesn't even init gtk.
I'd like to keep it this way.  The current settings manager button
table thing should be implemented as a separate helper app, and the
dialog windows for all the settings dialogs should be implemented in
the applications that need them, and will provide a way to run them
using the .desktop file method in Jannis' spec.

10.  I'm not sure what to do with the XSETTINGS stuff.  This would
require X11 stuff in the daemon, which I'm not happy about.  One
possibility is to have a separate XSETTINGS daemon that is just another
Xfconf client and watches for property changes for stuff it needs to
set XSETTINGS properties for (like gtk theme, icon theme, etc.).

11.  In theory, dbus activation will take care of starting the daemon
as needed, but this isn't set up yet.

I'm sure there are other questions in my head, but I'm too tired to
pull them out.  Any other thoughts/comments/criticisms?

	-brian

[1] http://lunar-linux.org/~jannis/mcs-design-proposal.txt
[2] http://svn.xfce.org/svn/kelnos/xfconf/trunk/common/xfconf-dbus.xml
[3] http://svn.xfce.org/svn/kelnos/xfconf/trunk