xfconf VS libxfce4util Resource Config Files for configuration

Sun May 1 18:03:32 CEST 2016

I should state that I also agree to GNOME being a dislikable upstream (and
three years from now someone will probably give me a printout of this email
and poke fun at me for it, damn). Yes, upstreams are people that we depend
on and so it means we must trust them not only to provide reliable software
now but also in the future. I do not trust GNOME/GTK+ with that given all
that has happened with the themes in the past few years, and that's why I
proposed switching to Qt as an upstream. We've made a decision already
years ago about that - which I fully support now because we're a team - and
we will pay the consequences of it no matter what happens in the future.
It's unlikely that a panel plugin not making that commitment of trust makes
a difference in that regard if we need to change upstreams in the future.
It is however very likely that said plugin not adopting a coherent / joint
code base with the other Xfce code bits will complexify maintenance on a
daily basis and force us to maintain a wider range of expertise on the code
base. I would have preferred working on a C++ / Qt code base or even on a
plain C / GTK+2 code base, but that's not possible and so we shouldn't hold
back and create more complications in the future.

On 1 May 2016 at 16:58, Steve Dodier-Lazaro <sidnioulz at gmail.com> wrote:

> Xfce4util uses the GLib, which is maybe not 90% of the codebase but
> definitely 90% of the complexity of Libxfconf's dependencies. Bugs in XML
> parsers are easy to test for / detect. Recursive GObject dependencies and
> GType init race conditions are an absolute pain in the *** to detect,
> reproduce, debug and fix. I threw away months worth of code on Unity
> because their software is too crippled for me to efficiently debug whatever
> atrocities they are doing to GType / GObject.
>
> So if you want simpler, KISS-er libraries I propose we throw the baby with
> the bath water and reimplement Xfce in C++. Then we can get rid of GObject.
> Otherwise since we're already in on it and already suffer all the
> programming style inconvenients, alleged bloatedness and memory usage of
> GTK+ / GIO / GLib, we might as well use it in full to delegate most of the
> API testing to the GNOME folks (who unlike us are sponsored by a
> multi-million dollar company full of good software engineers), and just
> write as little code as we need. Xfconf is in my opinion better in design
> than GSettings because it integrates better with user tools and demands,
> but XfceRC should really be a thing of the past. We already have GKeyFile
> (already integrated with GDesktopAppInfo) and Xfconf. When I have to modify
> Xfce apps for my downstream projects, having to deal with XfceRc / GKeyFile
> conversions between different bits (Exo, Xfce4Util, Xfce4UI, Garcon) is
> plain annoying.
>
> Anyway, just my personal opinion :-)
>
> On 30 Apr 2016 14:24, "OmegaPhil" <OmegaPhil at startmail.com> 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?
>>
>> 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.
>>
>> 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.
>>
>>
>> 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
>>
>

-- 
Steve Dodier-Lazaro
PhD Student
University College London
Free Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160501/db198802/attachment-0001.html>