<div dir="ltr">>> The same goes for our settings backend. The way XfceRc saves changes is not<br>>> compatible with the way GKeyFile works and probably not compatible with<br>>> KDE's<br>>> backend either. So we're producing files that other DEs and apps based on<br>>> other<br>>> toolkits may fail to process properly. By delegating XDG-related operations<br>>> to our<br>>> upstream, we can provide better consistency and reduce our maintenance<br>>> costs.<br>>><br>>> Yes, that means delegating control and thus taking risks.<br>> <br>> Bad behaviour by upstream 'maintainers' is evidence to drop/fork the<br>> dependencies, not cosy up to them further. If there was a GLib function<br>> etc, presumably they wouldn't maintain it so that it didn't have<br>> breaking changes either?<br><br>[all situations below hypothetical; if you're an Internet troll and quote this<br>email as "proof" that I hate on a DE or another, joke's on you]<br><br>Let's be honest. We don't *choose* to depend on GNOME and KDE to a certain extent.<br>We're a Linux DE. This means we must participate to FreeDesktop.Org specification<br>of cross Desktop standards. We're one of the few DEs who respect said standards,<br>and when they evolve so must we. So in a sense, not depending on GTK+ or the GLib<br>will not remove the problems we're having with GNOME apps and Xfce interpreting<br>or naming .desktop files differently, for instance.<br><br>Even if GNOME at some point decides to stop respecting a standard or another<br>without first proposing a new spec and letting other DEs implement it, our users<br>*will* keep using GNOME products and they will keep addressing bug reports to us<br>instead of GNOME. Because GNOME would care less about their products working on<br>a competing platform than we do about our platform supporting our users' products,<br>it's always going to be us who will have to fix the mess.<br><br>It doesn't matter if we think upstream is evil or nice. We still depend on them<br>because our users use their products. Likewise we depend on KDE respecting<br>standards or on us having the ability to cope with ways in which KDE does not<br>respect standards.<br><br>If we had wanted NOT to depend on one DE or another, then we would have had to <br>convince our users not to use their products. This discussion was had before the<br>3.14 cycle and the core developers decided to continue working within the GTK+<br>ecosystem for a number of perfectly valid reasons. I disagree with that decision<br>but I respect and support it. It doesn't matter if GNOME/GTK+ is a good or a bad<br>upstream, our technical debt is too big for us to realistically not have them as<br>an upstream so we have to accept whatever it is they do and move on. Otherwise<br>we'll never get anything done.<br><br>And in GNOME/GTK+'s defence, as much as they don't take the time to build proper<br>implementations for their new ideas, at least they listen to me when I go cry on<br>their shoulders and they always try to help me navigate through their code to<br>achieve whatever I need to do in my research project. They're a bad upstream for<br>us in that we have different understandings of the word "stable" (but in that<br>respect probably all upstreams other than Qt will be bad for Xfce, so this point<br>is moot), but they're a much better upstream than e.g. Ubuntu/Unity in that they<br>provide some degree of support for third-party developers.<br><br>Anyway, am back to work. If someone wants to chime in on XfceRc's odd features I<br>can continue the port. Otherwise I'll just let go of this conversation alltogether.<br><br>> Well, I'm not happy brushing it off like that. IG has earnt his right to<br>> speak to me through his work on the only serious GNU/Linux file manager<br>> I'm aware of, and it does tally up with other complaints I've read<br>> elsewhere. I won't talk about this further since its unlikely to be on<br>> topic enough for this list.<br><br>*pats Jannis on the shoulder* It's ok buddy, it's ok.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 May 2016 at 21:51, OmegaPhil <span dir="ltr"><<a href="mailto:OmegaPhil@startmail.com" target="_blank">OmegaPhil@startmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/05/16 23:34, Steve Dodier-Lazaro wrote:<br>
>> Thanks for your detailed responses, I've had a look around your site etc<br>
>> but I can't see a donation email address etc?<br>
><br>
> I am curious why this idea came up :D I don't need donations for just<br>
> annoying<br>
> people on the mailing list :-)<br>
<br>
</span>Because at least I have some solid reasons for xfconf, DBus etc (which<br>
saves me from having to gain the experience, which I probably wouldn't<br>
get anyway as I avoid them altogether), and potentially I can bug you in<br>
the future for counterpoints against stuff I come across.<br>
<span class=""><br>
<br>
>> In general: I'm coming from the standpoint of implementing a minimal<br>
>> amount of functionality around a core problem that is to be solved - the<br>
>> aim isn't to solve all problems or everyone's problem. In your emails<br>
>> you talk a lot about the bad consequences of the alternative to using<br>
>> shared libraries for solving (from my perspective) non-core problems -<br>
>> I'm saying they aren't in the scope of the program and therefore aren't<br>
>> to be solved (changing a program's underlying configuration store and<br>
>> expecting it to update as appropriate, running more than one instance<br>
>> and expecting configuration to be shared, etc). The use cases you<br>
>> describe (loads of IDEs, Firefox instances, sandboxing, application<br>
>> migration etc) sound very much like unusual edge cases that would be<br>
>> rejected (or relegated to a separate optional removable<br>
>> layer/implementation), with KISS.<br>
><br>
> Yes, you're right. Reasoning about what you need from an individual<br>
> perspective<br>
> differs from reasoning about it from a global perspective. This problem<br>
> exists<br>
> in design, in urbanism, in systems engineering, and so on... When there are<br>
> multiple stakeholders involve with similar, yet slightly different needs,<br>
> savings<br>
> can be made at scale through reuse. This goes for code as well :-)<br>
<br>
</span>Yes, I'm not fixing a 'global' problem, I'm purposely keeping scope<br>
small for control, understandability, etc. If I got paid a decent amount<br>
of money then it would make sense to go beyond solving the problem I<br>
want to solve.<br>
<div><div class="h5"><br>
<br>
>> Forgetting about my simple plugin, yes I do agree with the idea of a<br>
>> shared settings store when it comes to things like styles. I guess the<br>
>> next question is, if xfconf is portrayed as an ideal central<br>
>> configuration and changes manager, why do kernel programmers chose to do<br>
>> a similar thing (without change notification mind, theres inotify for<br>
>> that) through RAM-based filesystems (procfs, sysfs etc)?<br>
><br>
> Procfs is not that handy. Most files have an awkward syntax that poorly<br>
> interacts<br>
> with C (e.g. environ, you need to parse NUL separated strings and you can't<br>
> figure the size of the entire file because it's a procfs file so you have<br>
> to parse<br>
> blindly until you encounter two NULs in a row; takes a while to figure that<br>
> out).<br>
> No atomic changes, no caching of changes, etc (e.g. GFileMonitor has a<br>
> method it<br>
> uses to cache multiple changes to files in order to reduce the processing<br>
> cost of<br>
> file changes for child applications). THe max size of an environ array is in<br>
> hundreds of megabytes on a modern Linux so you also need a logic to reason<br>
> about<br>
> reading the file in multiple chunks if too big, and a logic to reason about<br>
> whether<br>
> a string you're processing is truncated by your buffer size or not. Not<br>
> funny at<br>
> all to do and I trust few CS students to do this right.<br>
><br>
> For me the KISS approach would be to provide proper functions in the system<br>
> call<br>
> interface that have well defined and well scoped semantics, for all commonly<br>
> required operations, rather than let hoards of developers guess how they<br>
> should<br>
> go about parsing complex files that violate some of the expectations of what<br>
> constitutes a file. ;-) Procfs is useful to provide opportunities for<br>
> advanced<br>
> sysadmins / developers who have needs that were not anticipated by the Linux<br>
> developers. I personally would love to have a getenv that takes a damn PID<br>
> as a<br>
> parameter rather than have to write awkward parsers.<br>
<br>
</div></div>Yes thats true - wrapping libraries around this raw data then, like<br>
libgtop for process state, disk usage etc.<br>
<div><div class="h5"><br>
<br>
>> I'm not sure why you've picked on 'standard place for configuration' a<br>
>> few times, I don't have a problem with using what<br>
>> xfce_panel_plugin_lookup_rc_file provides. I'm not rebelling against<br>
>> desktop organisation.<br>
><br>
> Multiple methods of processing config = multiple code bases that need to<br>
> implement<br>
> the same standard. Now given that our upstream GTK+ loves to break their<br>
> own rules<br>
> and existing XDG standards, and that the most popular Xfce distro is based<br>
> on an<br>
> upstream that equally loves to break conventions, we can expect that every<br>
> now and<br>
> then our upstreams will change how their code works, and ours will be<br>
> lagging behind.<br>
><br>
> For instance GNOME has changed how they name .desktop files. This has<br>
> forced me<br>
> to rewrite some code (somewhere in GTK+ or Xfce, forgot) that reverse looks<br>
> up<br>
> desktop ids from exec names, which is now much more complex. If a function<br>
> had<br>
> been provided for this by the GLib, I would not have had to triage a bug,<br>
> and then<br>
> patch a piece of software.<br>
<br>
> The same goes for our settings backend. The way XfceRc saves changes is not<br>
> compatible with the way GKeyFile works and probably not compatible with<br>
> KDE's<br>
> backend either. So we're producing files that other DEs and apps based on<br>
> other<br>
> toolkits may fail to process properly. By delegating XDG-related operations<br>
> to our<br>
> upstream, we can provide better consistency and reduce our maintenance<br>
> costs.<br>
><br>
> Yes, that means delegating control and thus taking risks.<br>
<br>
</div></div>Bad behaviour by upstream 'maintainers' is evidence to drop/fork the<br>
dependencies, not cosy up to them further. If there was a GLib function<br>
etc, presumably they wouldn't maintain it so that it didn't have<br>
breaking changes either?<br>
<span class=""><br>
<br>
>> I don't know much about DBus, specifically why its needed compared to<br>
>> more normal alternatives (so now I know it is at least a means for<br>
>> broadcasting configuration changes) - I just see it as extra insecure<br>
>> inefficient complexity. Yes I know that DBus has been attempted to be<br>
>> pushed into the kernel a number of times - I read the reason for pushing<br>
>> it in was to get extra efficiency, but rather it is its<br>
>> design/implementation that is inefficient, so it was rejected.<br>
><br>
> DBus is the IPC mechanism used by nearly every Linux applications. In ten<br>
> years<br>
> of CS there are several native IPC mechanisms I've simply never used; this<br>
> is how<br>
> rarely they end up being better than the alternatives. Including DBus thus<br>
> makes<br>
> sense, it serves a purpose.<br>
><br>
>> The kernel inclusion is also suspected to be an attempt to engineer<br>
>> insecurity, and possibly further control by RedHat?[0] Can't really<br>
>> comment on that as I don't have any experience here.<br>
><br>
> Haha. People come up with such funny ideas :-)<br>
<br>
</span>Well, I'm not happy brushing it off like that. IG has earnt his right to<br>
speak to me through his work on the only serious GNU/Linux file manager<br>
I'm aware of, and it does tally up with other complaints I've read<br>
elsewhere. I won't talk about this further since its unlikely to be on<br>
topic enough for this list.<br>
<br>
<br>_______________________________________________<br>
Xfce4-dev mailing list<br>
<a href="mailto:Xfce4-dev@xfce.org">Xfce4-dev@xfce.org</a><br>
<a href="https://mail.xfce.org/mailman/listinfo/xfce4-dev" rel="noreferrer" target="_blank">https://mail.xfce.org/mailman/listinfo/xfce4-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Steve Dodier-Lazaro<br>PhD Student<br>University College London<br>Free Software Developer<br></div></div></div>
</div>