xfconf VS libxfce4util Resource Config Files for configuration

Matthew Brush mbrush at codebrainz.ca
Sun May 1 22:43:09 CEST 2016

On 2016-05-01 04:37 AM, OmegaPhil wrote:
> [...]
> The complexity is still there, and now in even more complicated code
> that you don't control, forcing dependencies on the bloat, reliance on a
> potentially hostile upstream to keep their code stable and to fix things
> in a timely fashion, etc etc. So its more a case of, 'what are the
> strong technical reasons for these extravagant features that override
> all the negative aspects?'. I think that most programmers don't consider
> the bloat, or just don't care in general and use whatever is at hand.

One of the really useful features of Xfconf and GSettings is the ability 
to bind settings to object properties so that when a setting changes, it 
can update all other places relating to that setting automatically, in 
any instance (window) of the application.

For example, if you had a "font" setting that was accessible through a 
preferences dialog, and maybe a couple of menu items, as well as the 
font property on some text widget, you can bind the value of the setting 
to the widgets in the prefs dialog, menu items and text widget, so when 
any changes, the font is not only updated in the text widget but also 
the prefs widgets and menu items are synchronized to the new value, in 
all windows of the application. Doing this without property binding 
requires lots of harder to maintain glue code, but with it, it's just a 
few simple calls to actually bind the properties.

Another positive is that using the "standard" mechanism keeps 
configuration in one central place making it easier to maintain from a 
user's POV than each app rolling their own adhoc settings mechanism, 
using various file formats and config directories.

Another nice thing is that Xfconf/GSettings offer some kind of 
introspection into the names, types and value ranges of the settings 
which allows interesting tools like xfconf-editor/dconf-editor, making 
it easier to manage app configuration in one place, as well as opening 
possibilities of remote controlling the application, for example by 
shell scripts.

My feeling is that since (at least in the case of GSettings) you're 
already paying the cost in terms of memory overhead and dependencies, 
you might as well make use of it and get a more powerful, optimized and 
debugged settings framework than rolling your own in each application, 
increasing memory overhead, probably decreasing performance, and 
creating a whole new set of application-specific bugs.

Of course if all you need is to read a handful of internal settings on 
startup and write them out on close, with no GUI binding or anything, 
Xfconf and GSettings would be massively overkill compared to GKeyFile or 

>>> [...]
> Thanks, GSettings with GKeyFile sounds sane, but even a cursory look
> into this is raising problems - suggestion that such a simple thing is
> not part of a stable API[0]. It least as its part of glib, it won't be
> subject to GTK-style breakage.. you'd think. I will do a test later (it
> needs to work in Debian-packaged libglibmm to be acceptable).

I think just the backend API is unstable[0], which doesn't matter unless 
you're writing your own backend. If you're just using GSettings it 
shouldn't be an issue, as the actual GSettings API is stable (as much as 
any other GLib API).

Mousepad uses GSettings, with a compile-time option to use the Keyfile 
backend. Overall it has allowed for some major improvements in the 
preferences system, though switching to it has caused a fair number of 
new bugs, mostly due to my misunderstanding and the sheer number of new 
features/preferences it facilitated adding.

Matthew Brush

[0]: "The GSettingsBackend API is exported to allow third-party 
implementations, but does not carry the same stability guarantees as the 
public GIO API." -- GSettingsBackend docs

> It does feel that I should just stick with what I am using now, since
> its written and is only slightly more complicated than is necessary to
> do the job.
> 0:
> https://stackoverflow.com/questions/9103724/how-to-use-the-keyfile-settings-backend-from-pygobject
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev

More information about the Xfce4-dev mailing list