[xfconf] Implementing Schema's / using GSettings

[Stephan Arts]

Hi Guys,

I would like to discuss the following scenarios with you guys
regarding the development of xfconf.

Let me first state that I really like xfconf the way it is, and I am
quite happy if we stay using it like this.

However, with the design of the profile-manager I stumbled upon 2
problems that are difficult to solve with the current implementation:

1) It is impossible to get a clear human-readable description of a
property, so /general/double-click-action in the xfwm4 channel is "The
action that is performed when a user double-clicks on the title-bar of
a window", something that you would not know without reading the
source, or guessing.

2) It is impossible to figure out, as a user, what the valid values
are for a property. This is a problem if you don't use the
configuration-dialog provided by the application-package. (like,
xfconf-query, xfce4-settings-editor, or the profile-manager) Using the
same property as earlier as an example, valid values for
/general/double-click-action are 'maximize', 'fill', 'shade', 'hide'
and 'none', it is a string, but only allows a limited set of values.
The only way to find out, is by trial and error, or reading the
source. (again)

A solution to this is the implementation of schema's. Similar to that
is already implemented in GSettings / dconf. [0]

A schema is a predefined layout of a channel, it defines which
properties are available, what their types are, the default value, the
allowed range of values and a translatable description of what this
property means.

Basically, all the information you'd want to communicate to a user
what it actually means when he is changing the properties. Another
advantage is that you will be warned if you try to write invalid
values or non-existing properties, because they must be pre-defined in
the schema. (Though some might find this a disadvantage, I think it
enforces a bit of discipline - which is a good thing IMO)

I am curious how you think about using schema's, and if we want to use
schema's, my next question is: do we want to implement it in xfconf,
or do we want to use GSettings then?

>From what I've seen from GSettings, is that it's almost a drop-in
replacement of xfconf. It has a similar API, and just like xfconf it
provides bind() functions to directly bind gobject properties to
xfconf/gsettings properties.

I came up with the following arguments pro and con GSettings, please
shoot or add some if you like:

Pro:
- We have schema's. (considering we've made it past my previous
question, this covers quite some pro's all together)
- (other then that, it is pretty much the same as xfconf)

Con:
- GSettings currently has only one backend (though others can be
attached), dconf, which has a binary settings-database. Not the neat
xml-style config we have now.
- dconf property-locking seems immature / unimplemented, I have not
been able to find anything with that regard except for the
'is_writable' functions of GSettings itself.
- xfconf is very stable, why move away from it?

Other observations:
- GSettings provides property-locking just like xfconf does.
- GSettings API is similar
- GSettings is part of GIO, so we don't need to add another dependency

Now, regarding property-locking (thus, kiosk-mode) and a
human-readable storage-format, we could consider implementing our own
settings-backend. Both in current xfconf and dconf, kiosk-mode related
features are a bit immature. Maybe we can come up with something that
works better, as we no longer have to focus on the interface, our
applications use, this seems possible. But again, do we want to?

Now, keep in mind I am not discussing any time-frame here. I want to
discuss the general ideas.

Kind regards,

Stephan

[0] http://developer.gnome.org/gio/2.31/GSettings.html