xfconf VS libxfce4util Resource Config Files for configuration

[OmegaPhil]

On 30/04/16 19:16, Matthew Brush wrote:

>> I get the feeling its not so much 'needs' but programmer 'wants', to
>> make things convenient to program etc, without paying attention to the
>> cost of its actual implementation ('oh look this random library/system
>> has already been created that has all sorts of bells and whistles, just
>> use that!'). Simplicity is supposed to be extremely important for
>> resource usage, debugging, control, etc.
>>
> 
> Also which features are needed/wanted. For example, should the app
> update itself when the backing storage changes? Are you using GObject
> and want to bind the values to GObject properties? Should multiple
> instances be able to use the settings at the same time? etc.
> 
> If you need/want those features, with something like Xfconf or GSettings
> the complexity is moved out of the application and into a single
> library/daemon shared between multiple applications, making it easier to
> manage configuration across applications and making the application more
> simple and efficient.

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.


>> GSettings uses XML and compiled schemas (!!!), and looks to be another
>> programming frontend to god knows what (I'm seeing 'backend' and dbus
>> mentioned in places), so definitely fails KISS.
>>
> 
> GSettings is rather like Xfconf, except is built into GLib already and
> uses dbus/dconf/etc instead of it's own daemon/tools. I believe the use
> of schemas is to declaratively define the settings used as opposed to
> doing it in code using API calls. I assume it compiles the schemas to
> binary to avoid the overhead of parsing XML all the time.
> 
> GSettings can also use a GKeyFile backend rather than dbus, where it
> will read/write to a normal keyfile, and uses GFileMonitor or similar to
> watch the file for changes and such.
> 
> If you just need to store and retrieve a few simple values from a config
> file and don't care about schemas, change notifications, property
> bindings etc. you should probably just use GKeyFile, which is about as
> simple and lightweight as you can get for such a simple use case.

Simple use case -> normal use case - maintaining settings for a program.

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

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

-------------- 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/20160501/8a830d55/attachment.sig>