xfconf VS libxfce4util Resource Config Files for configuration
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
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. 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, 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.
: "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.
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
More information about the Xfce4-dev