4 ms·
This issue is almost never raised in good faith. Just look at this document. Disingenuous, trolling, contemptuous of the work of FLOSS developers. Then look at
by jdub 5y ago
This issue is almost never raised in good faith. Just look at this document. Disingenuous, trolling, contemptuous of the work of FLOSS developers. Then look at the comments in this thread, repeating and escalating the same nastiness.
Crap like this contributes to burnout, people leaving the community, etc. Why spend your time on a volunteer effort if you're just going to be abused by non-contributors?
There's a reason behind the problem should anyone care to find out...
Most people reading this thread should have at least some sympathy (empathy, even) for architectural and social challenges in large, long-running software projects.
GNOME is a 22 year old project, and for much of that time its underlying toolkit, GTK (formerly GTK+), was intentionally maintained very separately. The consequence is that, broadly speaking, GTK could not depend on GNOME features.
So, shoving GNOME's Nautilus-powered file management in a GTK file chooser? That's tricky. Other GTK users would not appreciate GTK depending on, well, almost all of GNOME.
A point of integration was required, to allow the outside environment to provide the file chooser user interface. Turns out that's also tricky, especially when your toolkit is providing API/ABI guarantees. Consider that GTK 2.x maintained API/ABI compatibility for almost half the entire lifetime of the GTK project.
But no one gave up. More recently, the XDG portals work provides an opportunity to solve this (and quite a few other problems) cleanly and, more importantly, securely. This will also allow a KDE environment to provide the file chooser interface for a GTK application. Nice! Why isn't it already supported everywhere? Because there are a lot of people and projects involved.
It's entirely legitimate to ask, in good faith, why this wasn't done 10, even 20 years ago.
Consider that building a complete FLOSS desktop system is an immense amount of work, and that's what GNOME (even before 2.0) was focused on. Not just "a user interface for Linux", but making the entire stack work for real people. So many improvements in Linux desktop systems came from GNOME developers deciding that the status quo wasn't good enough. We wanted to fix the kernel, device discovery and enablement, dynamic wired and wireless network configuration, rich input devices, accessibility, etc., etc.
Remember, 20 years ago just getting X to work with your bloody monitor to work was enough of a pain.
Then, consider the priorities of the people contributing to the GNOME and GTK projects. Was it more important to break toolkit API/ABI compatibility to let GNOME replace the file chooser, or maintain that compatibility and work on other, arguably more fundamental problems?
Oh, and you know what happens when GTK/GNOME chose to break API/ABI compatibility for 3.x and 4.x? Everyone complained that FLOSS desktop developers can't maintain compatibility and that's the thing holding back "Linux on the desktop".
Anyway, if you're not already turned off by all the abuse that FLOSS desktop developers cop for literally everything they do, from people who don't know any better and people who should know better, I can still recommend it as deeply satisfying work. :-)
- weberer 5y ago>Then, consider the priorities of the people contributing to the GNOME and GTK projects To be fair, this has been the #1 most requested issue in GNOME for quite a few years. Though now it seems to be second behind a blurry text issue. https://gitlab.gnome.org/GNOME/gtk/-/issues?sort=popularity https://gitlab.gnome.org/GNOME/gtk/-/issues?sort=popularity >This issue is almost never raised in good faith. I have no idea what you mean by that. This is a big issue that affects a large portion of users. Nobody is just pretending they need to see thumbnails for some nefarious purpose.
- jdub 5y agoVotes in a bug tracker don't represent the priorities of developers or even a representative audience of users. Yes, it's a known issue, but there are trade-offs and a lot of work involved. Most people just aren't aware of the complexity involved in file chooser implementations and APIs. The file chooser issue is more often raised in the context of internet abuse than good faith user requests. That doesn't mean it's not real, it just means it's fodder for precisely the kind of document we're responding to.
- weberer 5y ago>Votes in a bug tracker don't represent the priorities of ... a representative audience of users >The file chooser issue is more often raised in the context of internet abuse than good faith user requests What are you basing this on? That sounds incredibly dismissive. I think the core of the issue is that you're so out of touch with your users, that you're mistaking a highly requested feature with hostility. Maybe a user survey would be a good idea to bridge the gap. I think one large discrepancy is that this only affects a subset of users who frequently handle a large amount of images. In this example, it is users of image boards. But it also includes artist, photographers, etc. Not so much professional programmers. But to those who are affected, they are hindered greatly. I also see an issue with your idea that there are "good faith" and "bad faith" feature requests. This seems like a really unhealthy way to look at things. There is no conspiracy that there are a bunch of people out there that want to give you a bunch of work to do just to mess with you. 100% of these people are honestly affected by the issue and would like it resolved.