XfconfChannel support for plugins.

[Nick Schermer]

2008/10/13 Brian J. Tarricone <bjt23 at cornell.edu>:
> I was thinking about something similar for the xfce4-session splash
> engines this morning.  Right now they use XfceRc as well.
>
> Need to look into it more, but I'm planning on just passing around
> GHashTables full of properties as (gchar *, GValue *) pairs.  That way
> the splash engines don't need to know what kind of config system is
> being used, and nothing needs to change in them if we change systems
> again.  xfce4-session will handle emptying out the GHashTable,
> prepending appropriate property names, and storing the result in xfconf
> (as well as the reverse).
>
> So I guess you could do something similar for the panel.  Of course,
> that leaves out the ability to fetch one property at a time, but in
> practice, I think most (all?) plugins read all their settings at startup
> and rewrite all of them whenever the user changes the settings, so it's
> not a big deal.

Yeah that's probably 99% of the plugins, so it would be nice for reading the
plugin settings, but for writing you still need to xfconf channel, with the
property_base if you write everything to a single channel.
So IMHO it's not convering enough of the problem.

Maybe (just thinking here) we can add an
xfconf_channel_new_with_property_base (const gchar *channel_name,
const gchar *property_base).
Plugins can read/write to this 'channel' (if kiosk allows it) but they
have no idea where the data is stored (in this case the plugin channel
channel with the plugin name and id as property base). All parts of
xfconf respect this base and prepend/filter this when handling the
other xfconf commands.

There are probably reasons not to implement this, but in the plugin
case it could be quite useful and developer-friendly (although it
makes a config system switch harder, but xfconf is good and i think
we'll stick with it for a while ^_^).

> Personally I'd say a single xfce4-panel-plugins channel would be ok,
> BUT: only if you remove old config branches when a plugin is removed.
> Otherwise channels could end up getting very large, and xfconfd parses
> the entire channel whenever you read a single property from the channel.
>  I know we don't unlink() the old config files when a plugin gets
> removed today, but personally I've always thought we should.

We _do_ unlink the config files. But only when a plugin is removed
normally, when a plugin craches, the config file remains.

Nick