config daemon/library for 4.6

[Nick Schermer]

2007/9/5, Brian J. Tarricone <bjt23 at cornell.edu>:
> Nick Schermer wrote:
> >>> Exactly that is what I had in mind. Just provide a unique XfconfChannel
> >>> to each plugin and that's it. It doesn't sound like a bad idea to
> >>> cleanup old settings of plugins when they are removed from the panel.
> >>> And after all, such an xfconf_channel_remove() function wouldn't cost
> >>> much time to be written.
> >
> > Remember that plugin can have a different read and write location.
>
> What do you mean?  A plugin would read settings from one location and
> write to another?  Why?

Reading the default configuration for example. First the plugin gets
/usr/share/etc/xdg/xfce4/panel/launcher-7.rc as read location, but
when saving ~/.config/xfce4/panel/launcher-123456789.rc.

> > And plugin settings are already removed when you remove the plugin
> > from the panel (the unique id will never be generated again),
> > therefore I'd like to have a xfconf side way of removing the data. It
> > doesn't matter if it's *fast* or not.
>
> Er, no they aren't, unless you've changed this in SVN.  I have loads of
> stale config files in ~/.config/xfce4/panel/ from plugins I've removed.

No you're wrong. When a plugin is properly removed and uses the config
path provided by xfce4-panel, the file is unlinked. In both the 4.4
branch and trunk. The config files left in your directory are 'custom'
config names (not known to the panel), or from plugins that crashed.
If you still don't believe me, search libxfce4panel for unlink ;).

> I agree that GError is great for passing around error information when
> you don't have a GUI, but the point I'm trying to make is: the intended
> audience that I have in mind for the client library *doesn't care* why
> and operation failed when it failed, and in some instances may not even
> care whether an operation succeeded or failed.  I want to keep this API
> as clean and simple and easy-to-use as possible.  Error explanations are
> just extraneous noise for this application.
>
> Now, if someone wanted to write an app that cares about getting GErrors
> back, the dbus interface provides them.  The XfconfChannel API is really
> a pretty thin layer on top of the dbus interface and it's not very hard
> to just take generated glib bindings header for it, and call (e.g.)
> xfconf_client_set().

Ok, no gerrors... I can live with that if the dbus interface provides them.

Nick