xfconf VS libxfce4util Resource Config Files for configuration

[Matthew Brush]

On 2016-04-30 05:23 AM, OmegaPhil wrote:
> I understand if you don't want to discuss this, but continuing:
>
> Can't you implement a hierarchy by using structure in INI section
> titles/groups, e.g. 'Default/DVI-0', also can be used in the settings
> names themselves?
>

That's how the GSettings keyfile backend does it, as well as Qt's 
QSettings on Linux platforms.

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

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

My 2 cents.

Cheers,
Matthew Brush

>
> On 30/04/16 12:47, flo.xfce at gmx-topmail.de wrote:
>> The big advantage of xfconf is hierarchical storage. Just have a look at
>> xfce4-settings-editor - how would you transform the display channel or
>> xfce4-panel channel settings into an rc file? (Nevertheless an rc file
>> can also be a valid choice, especially for plugns, which usually have
>> only a few settings).
>> The point here is: Different applications have different needs when it
>> comes to settings storage. You can either use a big complex backend
>> which tries to address all those needs or multiple lightweight backends.
>> Have you looked at GSettings? Maybe its more to your liking.
>>
>> Kind regards
>>
>> On 04/30/16 12:56, OmegaPhil wrote:
>>> I'm the maintainer of the XFCE4 Hardware Monitor Plugin [0], and I'm
>>> currently reviewing how I maintain configuration for the plugin.
>>>
>>> At the moment I use libxfce4util's rc file functionality, but I don't
>>> like the separation between reading and writing when you open an rc file
>>> (reading something and potentially writing a change based off that is a
>>> normal thing).
>>>
>>> xfconf appears to offer a more regular read/write approach (haven't
>>> tried it yet), but looking into its implementation, immediately fails on
>>> KISS (Keep It Simple Stupid) - hugely bloated - XML, DBus, GObject,
>>> probably other stuff I'm not aware of. The task is just to store and
>>> retrieve a few bits of data into a simple text file, which is the UNIX way.
>>>
>>> I'm aware of xfconf's ability to store more complicated data and a
>>> hierarchy of data, but I don't need this. There is also the catch that
>>> XFCE4 has already paid the price for the bloat, however that doesn't
>>> dictate whether I should support it or not ('ethics').
>>>
>>> Does anyone here have serious usage of xfconf, and can bring up good
>>> reasons for using it over a normal configuration file?
>>>
>>> Thanks
>>>
>>>
>>>
>>> 0:
>>> http://goodies.xfce.org/projects/panel-plugins/xfce4-hardware-monitor-plugin
>>>
>>>
>>>
>>> _______________________________________________
>>> Xfce4-dev mailing list
>>> Xfce4-dev at xfce.org
>>> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>>>
>> _______________________________________________
>> Xfce4-dev mailing list
>> Xfce4-dev at xfce.org
>> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>>
>
>
>
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>