xfconf VS libxfce4util Resource Config Files for configuration

[OmegaPhil]

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

I'm mainly thinking from just my plugin perspective, but obviously XFCE
as a whole is a good question too.

'user tools and demands' - is there a demand for such integrated and
extravagant settings maintenance though? (I know Matthew has responded a
little later, will respond to that too). Are these demands from
'enterprise', which seems to be like a bloat cancer to anything it
touches (e.g. its no longer a libre desktop under the control of the
user, it is part of a larger system of control by sysadmins that want to
have integrated settings, immediate updates, control over users and what
they can set, etc etc)?

If this functionality is unnecessary, then yes you are avoiding writing
or interfacing with lots of other external code that implements the
functionality. Less processes running, stuff to exploit, a user can
trust that the system is written efficiently etc.

Hmm, GKeyFile looks good, this is used in SpaceFM too (I was forwarded
some examples), so probably better for me to use this than GSettings.


On 01/05/16 17:03, Steve Dodier-Lazaro wrote:
> 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.

There isn't a maintenance burden here, since I'm around, and if there
was and I wasn't then you move to the question of whether it should be
part of the official XFCE4 codebase (but thats a long way in the future...).

I'm not part of the team, so I can choose freely here.

-------------- 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/96d6547c/attachment.sig>