config daemon/library for 4.6

[Jannis Pohlmann]

Am Wed, 5 Sep 2007 14:55:43 -0400
schrieb "Erik Harrison" <erikharrison at gmail.com>:

> On 9/5/07, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> > Nick Schermer wrote:
> > > Maybe it's also useful to have a function to remove a channel and
> > > all the properties inside (for example when a plugin is removed
> > > from the panel, the panel can ask to remove all the plugin
> > > settings).
> > >
> > > gboolean xfconf_channel_remove (const gchar *channel_name,
> > >                                     GError **error);
> >
> > That sounds reasonable.  Another option would be to just remove the
> > channel when all properties are removed, but that's annoying.
> >
> > But really -- what application *ever* cleans up its settings on
> > uninstall?  Plugins never do either.  Is this even necessary?  Yes,
> > the store could get cluttered, but unused channels shouldn't impact
> > the daemon at all (they won't get loaded if no one asks for them).
> 
> Panel plugins are a special case because the panel guarantees that
> their configs don't step on each other or pull old settings. I suppose
> the panel could simply provide the XfconfChannel object and pull the
> same naming trick it does now with config files.

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.

> >
> > > The current api also lacks a bit of error handling, so errors in
> > > xfconf_channel_remove_property for example
> > >
> > > gboolean xfconf_channel_remove_property(XfconfChannel *channel,
> > >                                     const gchar *property,
> > >                                     GError **error);

Do we ever need this function by the way? Removing a whole channel
might make sense (where a channel bundles settings for one program),
but removing single properties? 

Concerning the error handling: IMHO Erik has a point with backend
developers being in need to debug the side-effects of their code. On
the other hand we really don't want to add a GError** parameter to all
of the get/set functions etc.. Error handling like this is useful when
dealing with critical resources likes files, but if we pass default
values then we don't need detailled explanations about why and how a
property could not be fetched (or stored - there a boolean return value
or something similar will do).

With an ...is_writable() function we make it possible for applications
to disable certain entries, check boxes or radio buttons. The
application/client has to assume that the config storage does it's damn
job - if not, just display an error message.

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20070905/5c16c88f/attachment.pgp>