xfconf VS libxfce4util Resource Config Files for configuration

[Matthew Brush]

On 2016-05-02 05:39 AM, OmegaPhil wrote:
> 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.
>

As a counter example, Geany (another app I contribute to) uses plain 
GKeyFiles and it's kind of a nightmare trying to work in multiple 
instances. You have to always be sure to close the instances in the 
correct order depending on what settings/sessions you want to be saved 
or else you lose settings, clobbered by the last closed instance. Also 
it has a whole code module (file) that tries to duplicate the 
widget/object binding provided by GLib/GSettings/Xfconf, which is 
confusing and not that many developers even understand it. Also, you 
can't really edit its own config file in itself because if you do, when 
you close it, it overwrites the changes you just made. It has a special 
case hack in its code to try and work around this by detecting if the 
file being saved is its own config file, but it doesn't seem to work. It 
even has a special menu item to reload configuration file, but it 
doesn't completely reload all configuration because some of it is only 
on code paths reached at startup. All in all, if Geany was re-written to 
use something like GSettings, barring any new bugs introduced in the 
process, it would eliminate loads of complicated, redundant, 
bug-report-causing code.

It's an example of where choosing what may seem like the KISS approach 
has the exact opposite effect.

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

It's important not to confuse programming bugs with problems of 
"extravagant" configuration systems. That is a bug I introduced because 
I'm a bad programmer, not because GSettings is 
bad/extravagant/bloated/whatever.

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

See above about Geany, it's an example where the supposed KISS way ends 
up causing lots of overly-complicated code in the app, and weird 
sequencing bugs that even still trips me up, as a long-time user, and 
developer, fully aware of the problems. You can't really escape the 
complexity, you can only choose whether you make your own mess, or you 
use the mess someone else maintains.

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

Actually re-using code other people wrote and maintain is a 
long-standing best practice in software (especially FOSS). At some point 
if you roll your own system, it will eventually re-invent the wheel 
someone else has already written, debugged and optimized, and you'll be 
left with wads of inefficient, bug-laden code that is specific to your 
application.

There's nothing unethical about re-using libraries people already wrote. 
You could consider rolling your own when there's something already 
pre-written and loaded into memory unethical, I suppose, though I 
wouldn't use such a strong term for this.

Cheers,
Matthew Brush