config daemon/library for 4.6

[Brian J. Tarricone]

On Thu, 6 Sep 2007 08:52:24 +0200 Nick Schermer wrote:

> 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.

Oh, I see what you mean.  This isn't supported yet, but it will be.
It's just a backend implementation detail.

> > > 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 ;).

Well, it wasn't *always* the case, at least not shortly after Jasper
rewrote the panel (before your time, IIRC).  There was even a
discussion on xfce4-dev about whether or not the panel should remove
config files after a plugin is removed, and I'm pretty sure it was
decided that it shouldn't -- guess that decision changed.

Regardless, I've added a RemoveChannel() method, so...

	-brian