config daemon/library for 4.6

[Nick Schermer]

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

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.

> Ooh, I like that.  To avoid complicating the dbus interface,
> _channel_remove() may be client-side: it just does GetAll() and then
> Remove() on each property.  The daemon could have a policy that it
> removes a channel if it has no properties left.  This isn't optimal
> performance-wise (a round-trip per property), but it's not a common
> operation.  Should I care about optimising this, or just add a
> RemoveChannel() method to the dbus API?

I've vote for _property_remove in dbus and _channel_remove clientside
if that also cleans the channel_name (with a file backend: not only
emty the file, but also remove it).

> Does it matter?  I left out the error returns for simplicity.  Really,
> how are they useful?

Error handling could be useful and you don't _have_ to use it. It's
just a good way to allow communication between the xfconf backends and
the user, when needed.
Personally I'd like to know when something failed and better tell the
user something when wrong (no write permissions with a file backend),
before he/she loses information, but maybe I'm a bit GError addicted,
duno, /me just likes it ^_^ and IMHO it's the cleanest wait of error
handling in a library.

Nick