config daemon/library for 4.6
erikharrison at gmail.com
Tue Sep 4 19:26:22 CEST 2007
On 9/4/07, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> Hey guys,
> Just spent a few hours hacking together a config daemon and library
> sorta somewhat based on Jannis' spec.
> 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 .
> 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.
> 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?
I can imagine wanting to distinguish between "unset", and "set to
something essentially empty". On the other hand I can't come up with
an actual example.
> 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?
To my mind this makes it utterly useless. My only use for a
transaction is in the case of an all or none cluster of property
changes. It's not just the danger of a crash leaving the data in an
inconsistent state - I might use a transaction to avoid a race
condition if my application depends on A = X if B = Y.
In previous discussions, no one has actually come up with a use for
transactions, just that they can imagine wanting them for
completeness, or in some vague future. If no one needs it why
implement a finicky half solution?
> 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.
Would this put the migration up to the application, or would old MCS
data become transparently available via Xfconf? I can see pros and
cons to both. But I tend to prefer transparent migration, so there is
the least dependence on independent developers to write migration
> 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?
None that I can think of at the moment. But I'm sure we can churn some up.
>  http://lunar-linux.org/~jannis/mcs-design-proposal.txt
>  http://svn.xfce.org/svn/kelnos/xfconf/trunk/common/xfconf-dbus.xml
>  http://svn.xfce.org/svn/kelnos/xfconf/trunk
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
"If you want to go somewhere, goto is the best way to get there." - Ken Thompson
More information about the Xfce4-dev