xfconf VS libxfce4util Resource Config Files for configuration

[OmegaPhil]

Just a disclaimer here: This isn't me VS XFCE, its just me having a
discussion about bloat with people who actually code this stuff and
therefore have some experience. So its part thought experiment for me.



On 01/05/16 21:43, Matthew Brush wrote:
> 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.

Yes, its a 'nice to have' to have multiple instances of an application
share configuration, but it is standard practice for this not to happen
(because naturally settings are saved in one configuration file that
should be read at the start, and written to later etc etc). Beyond this
you can lock the configuration file and tell the user that other
instances should be closed before you commit any changes.

Yeah, I understand the idea of a central settings object, not objecting
to that (just XML, anything dbus, having a superfluous always-running
daemon just for configuration, etc etc).


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

The user isn't supposed to be maintaining configuration directly at its
store, but they are welcome to if necessary with a standard INI file
structure (XML is not appropriate here, its designed to be an extremely
verbose guaranteed way to store data for communicating between disparate
databases controlled by different groups etc).

The registry (ala Windows) is considered a bad thing from my
understanding? Huge semi-maintained blob of data, anti-user etc
(although I don't think the XFCE4 implementation of such a thing is so
anti-user mind).

Different things are supposed to be separate, independent (I don't mean
pointlessly different but modular) - its not a mess, e.g. panel plugins
have a designated directory to save settings in, are given a path to use
to save the settings file as, etc.

Yes, these are extravagant 'nice to have' things, but not KISS.


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

Yes I'm probably going to go with GKeyFiles - the GUI does drive the
configuration, but nothing extravagant is needed - something changes,
its saved in a central configuration object (which is an integral part
of the program) and it gets written to the config file (not a database,
generated XML, not broadcast over some weird messaging system), thats
it. Not sure what bugs will happen there, the point is it should be
'anti-bug' since its only doing what is necessary and isn't touching
anything vaguely complicated.

Even in my limited experience as a user here, I've seen a serious
screwup with this extravagant configuration style - a mousepad config
change causing infinite dconf traffic spam resulting in serious CPU
whorage [0] - a problem that has absolutely nothing to do with changing
a simple configuration value (so 'acceptable bugs' here would be more
like, 'setting doesn't cause a change' or 'failed to update config file
due to read-only or disk failure').

You would say, 'but there is more than one instance of the program!',
and I would say that its understood that you need to restart the program
to load a new configuration (or that updating configuration in both
programs will overwrite each other's changes) - thats just a bit of user
education. Lots of stuff can be programmed around, but its not worth the
cost of violating KISS (this is where the care bit comes in, presumably
most programmers that actually take the time to do this work don't care
enough about the bloat - 'its normal' - and therefore perpetuate this).
And the ever-attractive 'sunk cost' argument, the bloat is already there
so why not embrace it? Thats where the ambiguous 'ethics' thing comes
in, I don't use proprietary software just because its there, or even
when it makes up the bulk of something - its still bad, and something to
be avoided/not to be encouraged. Makes for an easier escape when the
time comes to get out of the 'bad thing'.


0: https://bugzilla.xfce.org/show_bug.cgi?id=12134

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160502/95da7a14/attachment.sig>