xfconf VS libxfce4util Resource Config Files for configuration

[OmegaPhil]

On 18/05/16 11:33, Steve Dodier-Lazaro wrote:
>>> The same goes for our settings backend. The way XfceRc saves changes is
> not
>>> compatible with the way GKeyFile works and probably not compatible with
>>> KDE's
>>> backend either. So we're producing files that other DEs and apps based on
>>> other
>>> toolkits may fail to process properly. By delegating XDG-related
> operations
>>> to our
>>> upstream, we can provide better consistency and reduce our maintenance
>>> costs.
>>>
>>> Yes, that means delegating control and thus taking risks.
>>
>> Bad behaviour by upstream 'maintainers' is evidence to drop/fork the
>> dependencies, not cosy up to them further. If there was a GLib function
>> etc, presumably they wouldn't maintain it so that it didn't have
>> breaking changes either?
> 
> [all situations below hypothetical; if you're an Internet troll and quote
> this
> email as "proof" that I hate on a DE or another, joke's on you]
> 
> Let's be honest. We don't *choose* to depend on GNOME and KDE to a certain
> extent.
> We're a Linux DE. This means we must participate to FreeDesktop.Org
> specification
> of cross Desktop standards. We're one of the few DEs who respect said
> standards,
> and when they evolve so must we. So in a sense, not depending on GTK+ or
> the GLib
> will not remove the problems we're having with GNOME apps and Xfce
> interpreting
> or naming .desktop files differently, for instance.
> 
> Even if GNOME at some point decides to stop respecting a standard or another
> without first proposing a new spec and letting other DEs implement it, our
> users
> *will* keep using GNOME products and they will keep addressing bug reports
> to us
> instead of GNOME. Because GNOME would care less about their products
> working on
> a competing platform than we do about our platform supporting our users'
> products,
> it's always going to be us who will have to fix the mess.
> 
> It doesn't matter if we think upstream is evil or nice. We still depend on
> them
> because our users use their products. Likewise we depend on KDE respecting
> standards or on us having the ability to cope with ways in which KDE does
> not
> respect standards.
> 
> If we had wanted NOT to depend on one DE or another, then we would have had
> to
> convince our users not to use their products. This discussion was had
> before the
> 3.14 cycle and the core developers decided to continue working within the
> GTK+
> ecosystem for a number of perfectly valid reasons. I disagree with that
> decision
> but I respect and support it. It doesn't matter if GNOME/GTK+ is a good or
> a bad
> upstream, our technical debt is too big for us to realistically not have
> them as
> an upstream so we have to accept whatever it is they do and move on.
> Otherwise
> we'll never get anything done.
> 
> And in GNOME/GTK+'s defence, as much as they don't take the time to build
> proper
> implementations for their new ideas, at least they listen to me when I go
> cry on
> their shoulders and they always try to help me navigate through their code
> to
> achieve whatever I need to do in my research project. They're a bad
> upstream for
> us in that we have different understandings of the word "stable" (but in
> that
> respect probably all upstreams other than Qt will be bad for Xfce, so this
> point
> is moot), but they're a much better upstream than e.g. Ubuntu/Unity in that
> they
> provide some degree of support for third-party developers.
> 
> Anyway, am back to work. If someone wants to chime in on XfceRc's odd
> features I
> can continue the port. Otherwise I'll just let go of this conversation
> alltogether.


I understand, it just means XFCE has effectively been annexed by the
upstreams (can't go off on its own to fight how it sees fit etc, abides
by upstreams rules/decisions/directions etc).

Good thing I don't work on a DE, I don't use 'products', I use malleable
programs with the right to hack on them for the better.

-------------- 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/20160524/5373be08/attachment.sig>