xfconf VS libxfce4util Resource Config Files for configuration

[Steve Dodier-Lazaro]

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

> Well, I'm not happy brushing it off like that. IG has earnt his right to
> speak to me through his work on the only serious GNU/Linux file manager
> I'm aware of, and it does tally up with other complaints I've read
> elsewhere. I won't talk about this further since its unlikely to be on
> topic enough for this list.

*pats Jannis on the shoulder* It's ok buddy, it's ok.

On 16 May 2016 at 21:51, OmegaPhil <OmegaPhil at startmail.com> wrote:

> On 11/05/16 23:34, Steve Dodier-Lazaro wrote:
> >> Thanks for your detailed responses, I've had a look around your site etc
> >> but I can't see a donation email address etc?
> >
> > I am curious why this idea came up :D I don't need donations for just
> > annoying
> > people on the mailing list :-)
>
> Because at least I have some solid reasons for xfconf, DBus etc (which
> saves me from having to gain the experience, which I probably wouldn't
> get anyway as I avoid them altogether), and potentially I can bug you in
> the future for counterpoints against stuff I come across.
>
>
> >> In general: I'm coming from the standpoint of implementing a minimal
> >> amount of functionality around a core problem that is to be solved - the
> >> aim isn't to solve all problems or everyone's problem. In your emails
> >> you talk a lot about the bad consequences of the alternative to using
> >> shared libraries for solving (from my perspective) non-core problems -
> >> I'm saying they aren't in the scope of the program and therefore aren't
> >> to be solved (changing a program's underlying configuration store and
> >> expecting it to update as appropriate, running more than one instance
> >> and expecting configuration to be shared, etc). The use cases you
> >> describe (loads of IDEs, Firefox instances, sandboxing, application
> >> migration etc) sound very much like unusual edge cases that would be
> >> rejected (or relegated to a separate optional removable
> >> layer/implementation), with KISS.
> >
> > Yes, you're right. Reasoning about what you need from an individual
> > perspective
> > differs from reasoning about it from a global perspective. This problem
> > exists
> > in design, in urbanism, in systems engineering, and so on... When there
> are
> > multiple stakeholders involve with similar, yet slightly different needs,
> > savings
> > can be made at scale through reuse. This goes for code as well :-)
>
> Yes, I'm not fixing a 'global' problem, I'm purposely keeping scope
> small for control, understandability, etc. If I got paid a decent amount
> of money then it would make sense to go beyond solving the problem I
> want to solve.
>
>
> >> Forgetting about my simple plugin, yes I do agree with the idea of a
> >> shared settings store when it comes to things like styles. I guess the
> >> next question is, if xfconf is portrayed as an ideal central
> >> configuration and changes manager, why do kernel programmers chose to do
> >> a similar thing (without change notification mind, theres inotify for
> >> that) through RAM-based filesystems (procfs, sysfs etc)?
> >
> > Procfs is not that handy. Most files have an awkward syntax that poorly
> > interacts
> > with C (e.g. environ, you need to parse NUL separated strings and you
> can't
> > figure the size of the entire file because it's a procfs file so you have
> > to parse
> > blindly until you encounter two NULs in a row; takes a while to figure
> that
> > out).
> > No atomic changes, no caching of changes, etc (e.g. GFileMonitor has a
> > method it
> > uses to cache multiple changes to files in order to reduce the processing
> > cost of
> > file changes for child applications). THe max size of an environ array
> is in
> > hundreds of megabytes on a modern Linux so you also need a logic to
> reason
> > about
> > reading the file in multiple chunks if too big, and a logic to reason
> about
> > whether
> > a string you're processing is truncated by your buffer size or not. Not
> > funny at
> > all to do and I trust few CS students to do this right.
> >
> > For me the KISS approach would be to provide proper functions in the
> system
> > call
> > interface that have well defined and well scoped semantics, for all
> commonly
> > required operations, rather than let hoards of developers guess how they
> > should
> > go about parsing complex files that violate some of the expectations of
> what
> > constitutes a file. ;-) Procfs is useful to provide opportunities for
> > advanced
> > sysadmins / developers who have needs that were not anticipated by the
> Linux
> > developers. I personally would love to have a getenv that takes a damn
> PID
> > as a
> > parameter rather than have to write awkward parsers.
>
> Yes thats true - wrapping libraries around this raw data then, like
> libgtop for process state, disk usage etc.
>
>
> >> I'm not sure why you've picked on 'standard place for configuration' a
> >> few times, I don't have a problem with using what
> >> xfce_panel_plugin_lookup_rc_file provides. I'm not rebelling against
> >> desktop organisation.
> >
> > Multiple methods of processing config = multiple code bases that need to
> > implement
> > the same standard. Now given that our upstream GTK+ loves to break their
> > own rules
> > and existing XDG standards, and that the most popular Xfce distro is
> based
> > on an
> > upstream that equally loves to break conventions, we can expect that
> every
> > now and
> > then our upstreams will change how their code works, and ours will be
> > lagging behind.
> >
> > For instance GNOME has changed how they name .desktop files. This has
> > forced me
> > to rewrite some code (somewhere in GTK+ or Xfce, forgot) that reverse
> looks
> > up
> > desktop ids from exec names, which is now much more complex. If a
> function
> > had
> > been provided for this by the GLib, I would not have had to triage a bug,
> > and then
> > patch a piece of software.
>
> > 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?
>
>
> >> I don't know much about DBus, specifically why its needed compared to
> >> more normal alternatives (so now I know it is at least a means for
> >> broadcasting configuration changes) - I just see it as extra insecure
> >> inefficient complexity. Yes I know that DBus has been attempted to be
> >> pushed into the kernel a number of times - I read the reason for pushing
> >> it in was to get extra efficiency, but rather it is its
> >> design/implementation that is inefficient, so it was rejected.
> >
> > DBus is the IPC mechanism used by nearly every Linux applications. In ten
> > years
> > of CS there are several native IPC mechanisms I've simply never used;
> this
> > is how
> > rarely they end up being better than the alternatives. Including DBus
> thus
> > makes
> > sense, it serves a purpose.
> >
> >> The kernel inclusion is also suspected to be an attempt to engineer
> >> insecurity, and possibly further control by RedHat?[0] Can't really
> >> comment on that as I don't have any experience here.
> >
> > Haha. People come up with such funny ideas :-)
>
> Well, I'm not happy brushing it off like that. IG has earnt his right to
> speak to me through his work on the only serious GNU/Linux file manager
> I'm aware of, and it does tally up with other complaints I've read
> elsewhere. I won't talk about this further since its unlikely to be on
> topic enough for this list.
>
>
> _______________________________________________
> 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/20160518/255cd0f8/attachment.html>