XfconfChannel support for plugins.

[Brian J. Tarricone]

Nick Schermer wrote:
> 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.

No, no, I guess I wasn't clear.  You don't expose *anything* relating to 
the details of config storage to the plugins themselves.  They don't 
know about xfconf or anything.

You still have the plugin's 'configure' signal, but now its signature 
looks like this:

void xfce_panel_plugin_configure(XfcePanelPlugin *plugin,
                                  GHashTable *settings);

The hash table contains all the settings for that plugin.  The keys are 
string property names (sorta; see below), and the values are variant 
GValues.

Internally, the panel stores things in xfconf, say in a hierarchy that 
looks like "/plugins/$PLUGIN_NAME-$INSTANCE_ID/".  When passing property 
names to the plugin itself, it strips off this prefix.  So in Xfconf you 
might have "/plugins/launcher-12345/command", but the plugin only sees 
"command".  And if the plugin sets a string property name "foobarbaz", 
when the panel gets it, it will convert it to 
"/plugins/launcher-12345/foobarbaz" before storing it in xfconf.

The plugins don't know about XfconfChannels and don't link to libxfconf 
at all.  Neither does libxfce4panel; only the xfce4-panel binary knows 
about xfconf and links to libxfconf.  If (when?) we switch to a new 
config system in the future, the plugins don't need to change at all; 
only the xfce-panel binary does.

You could add something like:

void xfce_panel_plugin_store_settings(XfcePanelPlugin *plugin,
                                       GHashTable *settings);

to allow the plugin to send the changed settings back at its leisure. 
Or even a simpler one-setting-at-a-time API would probably work, but I 
think the hash table method is probably sufficient for most uses.

Although, you might want to add a:

gchar *xfce_panel_plugin_get_unique_id(XfcePanelPlugin *plugin);

for plugins that may want to do something unexpected/special with its 
settings and still maintain unique settings for different instances.

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

The panel should take care of it internally. Again you're exposing 
xfconf to the plugins.  There's no need for this.  I'd consider making a 
function like this available for the panel's use (and maybe the SM's use 
as well), but it seems kinda special-purpose, and the code to do it in 
the app is pretty simple anyway.

> 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 ^_^).

Hehe, thanks, but I wouldn't necessarily count on it, esp if 
dconf/gsettings eventually gains momentum.

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

Oh, cool.  I must not have noticed.  No objections, then.

Now, after I think about all this, I realise that this method makes us 
lose two very useful things:

1.  GObject/Xfconf property bindings.
2.  Async property change notification.

#2 isn't so important, I don't think: I wouldn't imagine most people 
would need/want to change plugin settings outside of their dedicated 
config dialogs.

But #1 is a shame: the bindings system *greatly* simplifies the settings 
code both in config dialogs and in the applications themselves. 
Xfdesktop's settings management at least is much more straightforward 
than it used to be simply because watching all but one setting is just a 
single line of code per setting.  But maybe this isn't such a big deal 
for plugins, esp. if we don't care so much about #2.

Or, maybe really the most flexible solution is for the panel to ONLY 
provide xfce_panel_plugin_get_unique_id(), and let the plugin do 
whatever the hell it wants with it, whether it's opening an XfceRc file, 
or linking directly to libxfconf and creating its own XfconfChannel, or 
something else.

	-brian