The biggest problem with GNOME right now is Gtk3 and gtkfilechooserwidget.c. It is so spaghetti and so many things rely on it that no one at GNOME is willing to work on it for fear of breaking something. And for the same reason they won't accept drive-by patches. It is, effectively, frozen broken, and has been for many years. This applies to any attempt to add thumbnails to the file chooser but there are far worse, actual bugs, beyond the lack of thumbnails.
As of right now if you File->Open in any program using modern Gtk3 and try to paste a file path in you'll get an error instead of pasting your filepath in a text field to open, "The folder contents could not be displayed\nOperation not supported" http://erewhon.superkuh.com/gtkfilechooserwidget-paste-fail....
It's unfixable behavior because the GNOME devs stopped respecting their own gsettings, org.gtk.Settings.FileChooser location-mode, to FORCE the path-bar experience on everyone. Because no one needs to type file paths, apparently. So why bother respecting the settings for path-bar or filename-entry? Their demographic doesn't care. Unfortunately gtk3 is used by far more than GNOME's demographic.
They have fixed this bug in gtk4, for all the good that does.
This is a pet peeve of mine - why is it that in Linux it's idiomatic to start like 5 processes and pipe their outputs together to find a file containing a certain word from the shell, but something like a file chooser cannot be its own program?
> … but something like a file chooser cannot be its own program?
That's happening! Gtk 3 and 4 include GtkFileChooserNative[1]. It works like a file dialog except the application doesn't know about its widgets. That means it can proxy another application.
So if you're running a Gtk app in a sandbox like Flatpak or Snap, Gtk will use the Xdg file chooser portal[2]. In GNOME, this is implemented by an application (in the host) which, itself, creates a GtkFileChooser. In the future, it could be a beefier application. One benefit of that taking a while to happen is, once the implementation gets fancier, there won't be too many weird mismatched applications.
(Also, I mention GNOME, but it's important to notice the file chooser portal is itself platform neutral; KDE apps use this, too, and the implementation depends on what desktop you are running. Yay, decoupling!).
Not everything uses GtkFileChooserNative, but pretty much any recent Gtk app that doesn't have weird requirements probably does. Off the top of my head, Firefox, Secrets, Bottles, GNOME Builder and GNOME Text Editor (although they still ask for access to all of the of the files for other reasons), … even Slack and VS Code! (Electron switched over recently).
You'd need some way to inform the window manager that "windows from this process should be considered modals over this window of mine" - probably something that's in the realm of the possible to hack together?
>> It's unfixable behavior because the GNOME devs stopped respecting their own gsettings, org.gtk.Settings.FileChooser location-mode, to FORCE the path-bar experience on everyone. Because no one needs to type file paths, apparently. So why bother respecting the settings for path-bar or filename-entry?
Control + L will turn the path bar into a simple string w/ autocomplete. Am I missing something here or are you talking about pasting a path into the filename portion of the dialog?
Hiding important features behind arbitrary keyboard shortcuts is definitely on my list of things I hate about modern desktop environments. (Not to mention, extremely unfriendly to accessibility.)
i installed a new debian box for work and i forgot to choose xfce4 so went with the default. gnome 3. i tried. i tried so hard to get used to it. for 2 horrible months i tried.
i only need a terminal, emacs, browser, thunderbird, the occasional screenshot and it was still horrific.
to be clear it was only the usability that was a nightmare. i experienced no bugs. it's solid. but wow it is unusable.
please, please, please someone at gnome headquarters ... can you make it usable? look at win10, win11, macos, kde, chromeos they all work fine. can't you do something like that? i believe you have the best software stack out there, and you're throwing it away with that frightful design.
This is purely my impression and not something I could prove, but it feels like Gnome wanted to have an out-of-the-box Mac-like experience, while not really understanding while people like using Macs. "You don't have a million configuration options on a Mac, so neither should we!" doesn't account for Apple having whole departments working on UI things, choosing sane defaults, etc. People don't like macOS because it doesn't give them options, but because it tried to make good decisions and patterns so that they won't need to tweak everything.
I know lots of people don't like Macs because they're not super tweakable, and that's fine. It's still my impression that Gnome is aiming for that target, while not quite understanding why a lot of people do like Macs.
No idea what problems you encountered, but I find Gnome to be a joy to use. It was such a relief after years on Windows. Gnome Boxes is such a smooth experience compared to VirtualBox. Maximizing content area by putting UI elements in the title bar is also something I appreciate.
The biggest problem with GNOME is that the organization needs to get their shit together. Their priorities and design choices are awkward at best so I must say they don't care for their users at all.
GNOME's design choices are either extremely good or extremely bad. I like the general workflow, but the panel looks like some crummy i3 config. You could almost get rid of GNOME's panel altogether, placing the network icon etc on the "Applications" view. You can't even switch Audio or Bluetooth devices using the panel. It's dead real estate.
>The biggest problem with GNOME right now is Gtk3 and gtkfilechooserwidget.c. It is so spaghetti and so many things rely on it that no one at GNOME is willing to work on it for fear of breaking something.
I wonder, why can't they introduce something like gtkfilechooserwidget2.c leaving the original widget intact?
The big guest Jon for me is, in 2022, why write UI code in C? (I say this as one who contributed to GNOME a little (all icons) back in like ’98–’02 and who writes high-performance C++ professionally.)
You may know this, but if you type / in the file chooser window, it replaces the path buttons with a text bar that you can type or paste into. I discovered that by accident, probably a couple years after the text bar vanished...
Try typing the name of a folder that will be found by the integrated tracker search into a gnome file chooser that’s trying to save a file. Then double-click that folder. The results are poor, to say the least.
My favourite idiocy is that gnome-terminal will offset the items in the right click menu and display hex and and octet translation of a number you happen to have highlighted... for reasons.
When someone posted this as a bug because of the obvious unintended idiocies with this a being a default immutable behavior, the maintainer essentially told him to f off and go build his own version.
Suspect one of the impetuses behind such stagnation is that in reality not that many Linux users use GUIs to do file stuff as so many of us live in the command line.
>> Suspect one of the impetuses behind such stagnation is that in reality not that many Linux users use GUIs to do file stuff as so many of us live in the command line.
GTK is a GUI toolkit. It is literally made for building GUI applications. The Gnome developers are building a graphical DE. Your reasoning doesn't seem to sensible to me.
Gtk3 filechooser worked fine until 2014. Distros with gtk3 released before this have a gtk3 lib that handles pasting file paths in the file chooser and the gsettings still work. My last desktop with functional Gtk3 is Ubuntu 14.04 on Extended Service Mantainance (ESM) support. But it'll age out of support fairly soon.
- the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
- missing top menu (but a bar is still there wasting space for a ... clock wtf)
- general window positioning; like, if you open an app, rather than just opening a window as new top window, gnome opens it behind others and pushes a notification "FF is ready" wtf
- mainstream desktop apps not ported to dark mode, so those icons look even more puzzling
I could go on, but I'm definitely leaving gnome/gtk apps behind. I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB. I'm also totally not looking forward to wayland, containerize-all-the-things such that basic file workflows stop working, and other attitudes, all the while the apps I'm using are exactly the same I've used 15 or 20 years ago, without new ones coming.
>> the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
That one drives me insane.
>> general window positioning
I want my applications to come up where they were when I last closed them. This used to be up to the app under X, and I'm fully on board with the Wayland idea that an application shouldn't know or be able to modify its window position. But that means putting things where they were is the DE/compositors responsibility now, and I fear they're going to fight that idea forever. I hope I'm wrong though.
> I'm fully on board with the Wayland idea that an application shouldn't know or be able to modify its window position
Why? Genuine question - that sounds like an incredibly opinionated position for the display server to force up the stack, and I don't have a good intuition for why it should be necessary.
> I could go on, but I'm definitely leaving gnome/gtk apps behind. I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB
Kubuntu was my first distro and posts like these reconfirm my decision to stick with KDE.
> - the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
I deeply hate this one, it always gets me when I'm saving in a hurry.
And let's not forget about buttons on windows title bars. Someone please tell GTK developers that most of us aren't using tablets; computers with actual keyboards and mice are here to stay for a long time.
That one drives me absolutely fucking batty. Nobody uses GNOME on the touch screens that the UI was clearly designed for, and moving the default requestor buttons out of the bottom right where literally every single GUI of any note throughout history puts them is a particularly galling bit of NIH snowflakery.
Yes I'm aware Mac OS isn't a panacea either (used MacBooks/PowerBooks and Mac mini on and off alongside Linux since 2003). But I had such a craptastic experience with PC hardware lately: on my 3rd Dell Latitude/Precision with battery and other hw defects ootb sent by customers for work within 8 months, and my 2019 Thinkpad has a stuck trackpad - miniscule as it is - due to completely unused mechanical parts (buttons, think point, and whatnot). Meanwhile, M1/2 MacBooks leave x86 notebooks in the dust performance-wise, and have left PC notebooks behind in terms of screen resolution for a long time now, also wrt trackpad and keyboard, and value retention, it's not funny
> - general window positioning; like, if you open an app, rather than just opening a window as new top window, gnome opens it behind others and pushes a notification "FF is ready" wtf
I like this behavior. It only happens for apps that take too long to start. When an app takes too long to start, it is usual for me to continue doing other things while it starts, when it starts, I don't want it stealing my focus. I think this feature works exactly as intended.
This has worked as expected to me. It generally opens windows on top of the stack unless the app takes too long to start and you've interacted with the window on top. In that case I appreciate it doesn't change focus (I could be typing something for example).
I started with desktop linux with KDE2, and KDE3 was... seemingly perfect. I watched some colleagues move to KDE4 when it came out and it felt like a ... mess. I tried it myself for a few days and it was too foreign. Never cared for gnome as a main desktop, although I do recognize gnome foundation did provide a lot of useful software over the years, some of which I used.
Moved to mac for main desktop around 2008. I look back some times and KDE5/plasma/whatever might be worthwhile to check out again. Mac annoyances are piling up over the years, but I suspect it would be "the grass is greener" somewhere else, and I'd find a lot of the KDE annoyances which led to me leave may still be there.
Same here. GNOME 2 was just about perfect.* KDE 3 was even better. Rock solid and lots of excellent, well-integrated functionality. Everything after those two have been a showcase of failed UX experiments.
* (It's successor MATE has not aged gracefully, unfortunately.)
> I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB
I'm curious, what do you expect won't work under KDE?
Nothing in particular; maybe third-party apps like MS Teams (ugh) I need for my customer projects (which also didn't work right on gnome for years, and had trouble when switching logins/customers), that kind of stuff. I considered kubuntu, but thought I was leaving Ubuntu mainstream for good anyway, so why not go to eg Slackware w/ KDE Plasma and say goodbye to systemd, snaps, and containerized browser behemoths that want to update themselves all the time anyway. Don't want that shit on my main machine period. I'll be keeping my old (Ubuntu 16.04 ESM and 20.04 LTS) notebooks around just in case, but customers keep sending me shite notebooks, and MacBooks are more than capable to run Docker crap anyway.
I ran into not being able to open Nautilus as an admin without having to install some packages through apt. Why is Linux the only OS that doesn't allow me to edit or view a system file out of the box?
I loathe all auto-closing so much, it's such a cheap way out of issue triage. The ostrich method of project management. It's a good red flag though, I know not to waste my time on the project. Who knows what major issues have been auto-ignored.
It can be especially inane if the issues are also locked automatically, you're already ignoring the issue why the f can't you let people discuss workarounds or request reopen.
Firefox Android did that and I stopped contributing. It's not even that I hold a grudge, but the ostrich method is extremely frustrating to the reporters
This is the thing - if you're going to be like Apple and dictate design, you have to get it right. macOS and Apple hardware is not to everyone's taste, and they make mistakes, but they prototype and dogfood and iterate like crazy and they have thumbnails in the damn file picker.
When you're picking a file, you can even tap space to get a blown-up preview of an image or PRF. I use this feature almost every time I need to pick an image.
One thing I'll give Apple credit for is in the early days of OS X, they had (and perhaps still have, if it's the same thing) a document called Human Interface Guidelines. They actually did real experiments with real people and came up with a set of UI patterns that were proven by science to make software features and UI discoverable, usable, and clear, with the least amount of cognitive load.
Things like, the buttons on a dialog should should be a verb indicating the _action_ the user wants to take. Like "Run This" and "Go Back" instead of "Yes" and "No". (Or worse, the old Windows "OK" and "Cancel", which is rife with ambiguity in so many cases.)
And the tone of the document was that it was intended to be useful to _all_ user interface designers of all software and on all platforms, not just OS X. I just skimmed over the current edition and as far as I can tell, these days it's basically just about how to stay "on brand" with the Apple experience when writing your own UI.
> When you're picking a file, you can even tap space to get a blown-up preview of an image or PRF. I use this feature almost every time I need to pick an image.
Wait, what? That would have been super useful, but how was I supposed to find out?
I just don't use anything Gnome related, if I can help it. I have found some things that unfortunately use the toolkit and somehow manage to not be intentionally irritating, but I assume that's an oversight to be corrected once I'm dependent on it.
This comment might come off a little off-topic but I think it's pretty related.
The Gnome Project has always struck me of having this Apple-Like attitude of "We know Best", and subsequently ignoring/shrugging off user concerns/issues/etc.
It's pretty obvious that Gnome is at the very least "inspired" by macOS. Heck Apple started version bumping by whole numbers at right about the same time Gnome switched from 3.x to 4x.
I use it on my Touchscreen Convertible Laptop (with Wayland), since it supports multi-touch gestures (on the touchpad too), and as long as I install extensions to bend Gnome to my will, it seems to work pretty darn well for me. (For example, adding window tiling with the https://github.com/Leleat/Tiling-Assistant extension).
Perhaps there is a better way that I should switch too, but currently I remain ignorant.
At this point, it has become evident that they don't "want" to support this feature. So you're limited to what KDE has to offer if you need this.
Personally, I've bailed on the whole DE thing. Take the tiling-wm-pill and move on. Now I have to deal with tumblerd random high-cpu usages and thunar's unexpected crashes.
I've not seen anyone using a tiling window manage with 32" and larger 4k displays. It's just an awful experience.
I would use a tiling window manager (and have) on something like a chromebook or if I'm a youtuber that does everything in a VM at 1080p. I have a hybrid approach that I use with XFCE (aggressive window snapping with custom shortcuts), but it's hardly a typical tiling window manager experience.
Regarding Thunar, I don't have any issues, but if you are not using it in XFCE, you might want to try and see what plugins you are loading. Some expect XFCE and could be the root of your issues.
> I've not seen anyone using a tiling window manage with 32" and larger 4k displays. It's just an awful experience.
I'm using i3 / sway on both, my Workstation's 40" 21:9 (5120x2160) and my private 32" 16:9 4K displays, and see no reason why a bigger display, or one with a higher DPI, would make using a tiling window manager working worse, on the contrary, for me, it's all the more important to have good management if I got more "screen estate" to handle.
IME using tiling WMs on bigger/HiDPI screens is a fantastic experience.
I’ve never been able to make tiling work for me regardless of screen size. Windows constantly end up being awkward sizes that cause scrolling that would be unnecessary in a floating WM, and I’m constantly tweaking window sizes to try to make it less awkward. It’s very micromanage-y, and it drives me nuts.
But I don’t live in a terminal and/or text editor — my most frequently used programs are IDEs, VCS UIs, and graphics editors… stuff with lots of panes and palettes and such. Simpler apps get use too, but it’s skewed enough that popping some apps into floating mode in a tiling WM isn’t enough. My ideal environment is floating-first with light optional tiling, like macOS with something like Moom installed.
> I've not seen anyone using a tiling window manage with 32" and larger 4k displays. It's just an awful experience.
I do this. How is it a bad experience? If anything I get more mileage out of my tiling WM on my large screen than I do on my laptop, where I tend to just use a lot of full screen apps and change tag/workspace a lot.
Meh, I'm so disilluded that I've resorted to using nautilus as my file picker and just drag 'n dropping files from it into the program I want to open the file with.
I've done this. First I did pure BSPWM, then pure i3. Frankly, it's just too light for me. I spent so much time having to handle all these one-off scenarios like, hot-plugging multiple monitors, bluetooth, audio volume (with switching output when I plug into my big monitor). I had cobbled together so many scripts and I was constantly fighting with something that had worked the prior day. Having an actual environment under the hood made it much nicer.
Yes but in a tilling setting, a new window (say Thunar), right beside your main app is just a single key-combination away. And it places the window correctly too. So you can drag-drop the file and close the auxiliary window.
Also, since a twm is not tied to a DE, you can pick KDE set of apps for example in i3. Then you'd have a file picker with thumbnails.
That said, I do neither of those things and I suffer from this bug. So you are right in a sense.
I'm beyond grateful the Qt is not engineered by KDE.
I am now running a hybrid setup with KDE + i3. It works really well because I get to have all my network settings, display settings, etc on the fly, I can use konqueror, and i still get i3 nicely.
Luckily for the Gnome team, Microsoft ripped out features from their desktop interface in Windows 11. So Gnome might look comparatively functional when Windows 10 is EOL.
I came to Linux from a Windows world, so KDE always made more sense to me. I think, with the exception of 4.0, KDE has been fundamentally less bad than gnome since at least 2002. A sweet spot for me was KDE3.5 and then again current day KDE plasma. I like the customisability.
The file picker has always been one of the weakest parts of our GUI paradigm, and it has been since the Mac.
Navigating file system via GUIs is slow, painful, and for me takes a ton of cognitive effort after a short amount of time of accumulating files. Coming up with a system for organizing files is kind of hard in itself. Reorganizing as the number of files outgrows the system is also painful.
And choosing a place to save a file is often the best time to start a reorganization. But if I save a file in a new location, having to switch apps and now go back to that same spot in the hierarchy and reorganize is painful.
I don't have a good solution, just complaints, unfortunately. But after ~50 years of GUIs and hierarchical file systems I'm surprised somebody more clever than me hasn't come up with a better solution.
This comment reminds me when Apple revamped Finder to include "All My Files". To me it felt like they were giving up. "FINE! Can't find something? HERE'S EVERYTHING!"
These sort of pseudo-directories honestly bother me more than just plain old hierarchy. For example on Windows, "This PC/Documents" is really "%userprofile%/Documents", but to get to %userprofile% you have to go to C:\Users\<username>. But there's TONS of other stuff that lives in %userprofile%
And it hasn’t evolved with cloud/sandboxing/magic-paths/whatever. Like today on the Mac I used the popup directory path to try to navigate to the parent directory (since it showed it to me, and it was selectable) and it couldn’t; it just threw me to my home folder as if that was my request. I can only assume it was some weird cloud thing but when path navigation itself is a question mark we have problems.
KDE 5.25 is very exciting, it feels great being on a desktop that gets updates where features are added instead of removed. Definitely the place to be in 2022!
I love the fact that right there on KDE.org there's a screenshot of Kontact with that big obnoxious vertical "HTML Message" black bar in the middle of the screen. I remember reading a bug report some 10 or 15 years ago to allow it to be hide-able somehow at least with the author just flat-out refusing to do it or allow patches for it.
I'll never use Kontact for this reason but I do like most of the rest of KDE.
> First of all, how do developers so casually ignore this issue?
GNOME has never struck me as a project interested in implementating polish work. Polish work is disproportionately hard (it sometimes upends your understanding of the problem, forcing you to rethink your core structures, which impacts other features. In short, polish work has a tendency to explode).
> Second of all, how do users so casually ignore this issue?
GNOME users are accustom to polish not being the priority of the developers. Those who couldn't take it stopped using GNOME.
> GNOME users are accustom to polish not being the priority of the developers.
Wasn't the whole spiel of Gnome 3 that it was all about "UIXP" and perfection on defaults, sacrificing power-user functionality if necessary? That's effectively all about interfaces that do very little, but do it very well - i.e. they are super-polished, if less featureful.
It is true, though, that a lot of people stopped using GNOME. In fact, despite Ubuntu and RedHat effectively pumping users into the ecosystem for years, most Linux folks I know use either KDE or boutique DEs.
I don't know enough about GNOME's history, but I wonder if the people making those promises fell into the trap of believing that a more polished desktop environment would be one with cleaner code, and when they said super-polished they meant clean abstractions.
A super-polished UI (in the sense of "well-rounded, meets expectations, minimizes user surprise, behaves predictably") has messy abstractions because humans are messy. I've never met one that looked good on the outside and didn't have ugly snaggy bits on the inside to get all that good-lookingness to actually work in the corner cases. Perhaps GNOME has fallen into the trap of sacrificing features for purity of form. If they're saying things like "We'll have thumbnails when someone can figure out how to do it cleanly" they've fallen into that trap.
> sacrificing power-user functionality if necessary?
Scratch "if necessary". Power users have privilege, so deliberately throwing them curveballs for the sake of equitable outcomes seems to be the GNOME way.
The devil's advocate response is "How essential could they be? We went decades without 'em."
I don't think it's the right answer, but it's an answer that works (GNOME continues to be the dominant Linux desktop environment in spite of lacking that feature).
> If Apple or Microsoft had something like this "misfeature" in their OS, they could and likely would lose sales.
I disagree. Microsoft and Apple[1] had both had immense blunders that users hated, yet those users still paid money for the blunders.
At least with Gnome, people switched.
[1] I've used almost all the Window Managers and Desktop environments since 1995, I've used Windows since 1995. The current apple GUI is more painful to figure out than I had expected when I started using it last year. It's easily one of the least intuitive environments that I've come across, and watching non-tech users struggle with it reinforces my point.
I mean, GNOME is the default on several commercially supported distributions. Redhat is the largest contributor. Granted, a lot of those commercially supported distributions are for customers who don't care about GUI uses but Ubuntu and RHEL/Fedora have a decent number of workstation users. KDE/Plasma have much less commercial support (AFAIK) and are probably closer to what you're saying, but at least to my tastes manage to be much more sensible.
It's hard to coordinate and improve software effectively among people with different ideas of what something should look like.
This is why Windows and Mac will always remain dominant desktop operating systems, I think. It only takes a few issues like this for a user to give up and go back to the big two players.
I'm not sure what the proper term is but having thousands of MS developers working and being led by managers, defined organizational processes and sense of direction vs hundreds of thousands open source developers led by their own ideas, what good and should look like, and different motiviation, a lack of coordination and a organisational process as big as a paragraph inside an obscure README.md
Except for the part where tons of people are up in arms because MS removes or changes their UI. Fisher price, new control panel (XP), vista, UAC, start menu search, ads, mandatory logins, new control panel (8/10/11), new inflexible taskbar and so on
Except for the part where all of those people are Linux users who complain about Windows as a hobby, and have no effect on the relative market shares of Linux/Windows because they would never switch back to Windows under any circumstances.
This is probably why Linux has been such a large success. For all the submissions, suggestions, filtering by those lower down the chain...at the end of the day it's Linus that says "Yes" or "No". (And/or chews people out for bad code.)
Since the comments here are rapidly turning into a "dump on GNOME" section, does anyone know if there is a master list of "What the GNOME documentation calls an application" <-> "What everybody else calls an application"
Tbh KDE is worse at this because at least when you are using Gnome it won't call Nautilus Nautilus. It will call it Files, unlike on Plasma where Dolphin will be called Dolphin instead of being called Files or File Manager, which means that people who don't know Dolphin is the file manager will just be really confused as to what Dolphin is, especially if they don't already know that this icon always means file manager no matter what 0S you're on. Linus actually had this issue when he couldn't figure out what Kate was because he saw Kate and he thought what's Kate. Whereas on Gnome it would just say Text Editor instead of gedit. If you are using the terminal, you are more likely to know the actual name of the program so that's less bad for me. And on KDE if you are opening graphical applications through the console, you still have to open them through their weird code names. For example, Dolphin which makes no sense whatsoever. Just the same as Nautilus makes no sense whatsoever so that arguement is somewhat disingenuous.
Can anyone explain why this bug has gone so long without a fix? Is it technically challenging to fix, or does the Gnome team disagree that thumbnails are necessary?
I read over the ticket[0] and from what I could see it was mostly bickering about the format of the patch or something. I didn’t really see any “ba humbug, command line is all you need” kinds of posts from some graybeard.
So in short it looks more like an organizational problem than a technical or even political problem.
>Conway's law is an adage that states organizations design systems that mirror their own communication structure. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967. His original wording was:
>Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
>— Melvin E. Conway
In Gnome's case, the structure of its design is a copy of its disorganized communication structure.
This reminds me of the problem with scrolling on Chromium, and now because of Electron a whole bunch of other programs. A single click of the scroll wheel moves the page by 100 px on Windows, for some reason it’s only 53 px on Linux, which means scrolling is twice as slow. This is not just compared to Windows, but it’s also much slower compared to other native Linux programs.
If you search for this issue, there are countless discussions and half broken attempts to work around this problem, including Chromium bug reports including some that are now nearly 10 years old. It’s 2022 and scrolling in Chromium and Electron apps with a mouse on Linux is still unbearably slow with no way to adjust that. There used to be a hidden CLI option, which was added for ChromeOS which probably had the same issue, but that was later removed.
The best solution I found so far is running patched libinput that multiplies the scroll amount delta by whatever you want, and having a daemon running which watches the window that is currently being scrolled and alters that scroll multiplier accordingly. It’s absurd that this is what I have to do to get acceptable scrolling behavior with a mouse on Linux.
> This file picker does not have a thumbnail view. It is broken software. Thumbnails are not a cute little extra, they are essential. This is as bad as a file picker that doesn’t list the name of the files, only their creation date, or inode serial number. It is broken software. No, individual file previews aren’t "thumbnails."
As is unfortunately typical of articles like this, it overstates its case to the point of making it difficult to engage with. No, it isn't as bad as a file picker that doesn't list the names of the files. No, for most things one uses a file picker for, it isn't essential.
For that matter, I was actually completely unaware that my file picker (I use KDE) supports showing a thumbnail view. I did not know this because I have not ever needed to use such a feature. I use the file picker in "details" mode exclusively. On the rare occasional where I need to disambiguate two files because I don't know the name of what I'm looking for, the image preview has been more than sufficient.
I'll certainly grant that this is a feature that it makes a lot of sense for a file picker to have, and for a handful of use cases (trying to find a single image in a large directory of badly named image files) it might even be essential. But this tendency to overstate one's case is at the very least irritating, and IMO it leads to unwarranted attacks on developers that makes people shut down and resist spending their time on solving your problem.
File picker horror? Use the built-in file picker of Javas own Swing-Toolkit.
Integrating a GUI into a programming language library is inherently wrong. And while Sun was on the wrong path they doubled down and spread it across multiple platforms because they assumed their GUI was a solution. It wasn't and luckily Java based applications disappeared - with the exception of Java based developer tools.
This seems to be a Linux exclusive problem. In general Linux is great, but there's so many people that really don't care about usability.
The problem with open source is that programmers often set priorities(Which is why I'm a fan of Cathedral model software).
FOSS programmers love to program so much, that everything they write is usually a tool to help make other programs.
Without outside feedback, or some kind of strong mission to really focus on the mainstream, the whole entire ecosystem can turn into jusr one massive IDE made of loosely coupled utilities.
This is a weird hill to die on. I've never cared much about the file picker and the individual file preview is "good enough" to ensure you pick the correct file. Now if Nautilus didn't have image previews in "icon view", then that's cause for rioting in the streets.
That just tells me that you never upload images, or that your image folder is not particularly large. If trackpad drivers were broken, that would still be a pretty big issue, even though you personally always use a mouse.
I upload files all the time and for some reason I don't encounter this problem in gnome. Just give the files appropriate names?
Seems like a channer problem. It's not suprising that no one from /g/ has made a patch yet.
Edit: Actually, I just checked and apparently it's because the file picker actually does show thumbnail icons, just very small ones. For example, https://files.catbox.moe/h3s3c3.png
I guess I can usually make out what the image is from the small thumbnail icons!
You'd expect the file picker and nautilus to share behaviour though, right? Also for me, if I open the file picker from Chrome/Edge/an Electron app it's forced full screen and there's no preview on the right either.
I love GNOME, use it on both desktop and laptop, but this is one of those things that's just bad.
I definitely agree that it's strange that Nautilus can do this and the file picker can't. I also agree that consistency is important, but this issue has never caused me problems so I don't think anything of it. There are other things in Gnome that are keeping me from using it after being a vocal supporter for decades.
Huh... I just opened Pluma in MATE and used the file opener, and it had image previews in the list view. I never really paid much attention to this though, so no idea if the MATE team added it or what.
They are a bit smaller than I'd like though... let's see if there's a configuration option for that.
> Huh... I just opened Pluma in MATE and used the file opener, and it had image previews in the list view. I never really paid much attention to this though, so no idea if the MATE team added it or what.
But, MATE isn't Gnome. That's almost their slogan, how could you not know?
I mean that every line in the file picker has a small image beside it.
It's just that since it's a list view, they are a bit smaller than I'd like (set to line height). I guess increasing line height or font size would help. Nonetheless it's good enough for roughly figuring out what image is what.
I tested both in Pluma and Firefox - this seems normal for MATE file pickers, but I don't know if it was normal in Gnome2 as well and I never noticed.
I read the entire mediocre post. I need to take a dump now. Luckily, my toilets both flush, so I can choose whichever is most convenient. Right now I wish I had a third one in the basement, but that would require a pump, which would likely fail.
The Gtk file picker has for years offered a notoriously horrendous user experience. A lot of critical functionality is missing in the name of the GNOME people's vaunted simplicity or what-not.
... although reading superkuh's comment, maybe the explanation is more mundane (and sad) than that.
When I try to attach a file in Chrome on Linux, it shows a file picker that defaults to only showing files I recently uploaded, which is the exact opposite of what I want.
Here is the ultimate problem with GNOME. It is essentially a lie.
What I mean: Imagine you bought a ticket for Matrix 4, and they showed John Wick.
That's what GNOME 3 did. They made a new and different product; whether you like it more or less than the last one isn't the point. They betrayed the reliance we had on the old thing by a "lie of omission." A more honest approach would have been to name Gnome 3 something different (and perhaps hand the Gnome name off to the MATE people?)
there is an xdg-desktop-portal feature that allows this, or pretend that a different desktop is used by setting XDG_CURRENT_DESKTOP for the application, as well as KGtk which is a library that can be loaded with LD_PRELOAD.
either of these have to be applied per application though.
I mean, in this case, it literally is as easy as adding an alternate CSS style and then managing the proper dark-mode switching.
...not that this is really a concern in the first place. If you read through someone's blog and the best comment you have is on their website's OS integration, I think you've got your priorities misaligned.
Yes it does. I'm looking at a thumbnail in my Gnome file picker right now. I'm on Fedora 36 (Gnome 42)
Edit: It looks like the specific complaint is that the Gnome file picker does not allow icon view. That is true, but I still see two thumbnails: one next to the actual file, and one in the thumbnail pane.
A better title might be "Gnome has no file picker icon view and I create flamebait titles."
When forced to use windows the first thing I do is turn this feature off. Something doesn't feel right when a tool to list files tries to process content of files (e.g. image processing did come with severe security holes in the past, and it probably still does today).
Your toilets work because you keep a jug of water next to them to pour directly into the bowl to flush it, because you disconnected the toilet tank. You've decided that a tool that tries to remove waste shouldn't also intake water. After all, intakes have failed in the past and flooded houses.
Better to do that part by hand to be on the safe side.
This is the nature of desktop UI. Your argument for purity of function is sound, but users want their desktop UI to read images for thumbnails and previews anyway because an image file means more to them, semantically, than a pile of inscrutable bits inside a file pointer. Desktops, over time, become a junk drawer of the features "most users want" for "controlling their computer" in the space between dedicated programs.
file-picker is a GUI tool whose language is visual instead of text. If ls must do text processing and formatting to output that colorful list, so too must file-picker do image processing to complete its function.
The writer seems willingly disingenuous. Not having a feature isn't the same as having a bug. The software is behaving exactly as designed. Do you say that older versions of windows develop "bugs" as soon as a newer version adds a new feature? Of course not.
I agree with the conclusion though, these little missing conveniences add up to a worse experience for converts. I understand open source apps choosing not to do things exactly the same way as proprietary solutions, but we at least need something as good.
That said, it has always been the case that if a feature didn't exist in the pile of software that was freely and openly provided to you, you would either contribute the feature yourself or just go elsewhere. So the bounty would have sufficed, there is no point in being a shithead about it.
The biggest problem with GNOME right now is Gtk3 and gtkfilechooserwidget.c. It is so spaghetti and so many things rely on it that no one at GNOME is willing to work on it for fear of breaking something. And for the same reason they won't accept drive-by patches. It is, effectively, frozen broken, and has been for many years. This applies to any attempt to add thumbnails to the file chooser but there are far worse, actual bugs, beyond the lack of thumbnails.
As of right now if you File->Open in any program using modern Gtk3 and try to paste a file path in you'll get an error instead of pasting your filepath in a text field to open, "The folder contents could not be displayed\nOperation not supported" http://erewhon.superkuh.com/gtkfilechooserwidget-paste-fail....
It's unfixable behavior because the GNOME devs stopped respecting their own gsettings, org.gtk.Settings.FileChooser location-mode, to FORCE the path-bar experience on everyone. Because no one needs to type file paths, apparently. So why bother respecting the settings for path-bar or filename-entry? Their demographic doesn't care. Unfortunately gtk3 is used by far more than GNOME's demographic.
They have fixed this bug in gtk4, for all the good that does.
This is a pet peeve of mine - why is it that in Linux it's idiomatic to start like 5 processes and pipe their outputs together to find a file containing a certain word from the shell, but something like a file chooser cannot be its own program?
> … but something like a file chooser cannot be its own program?
That's happening! Gtk 3 and 4 include GtkFileChooserNative[1]. It works like a file dialog except the application doesn't know about its widgets. That means it can proxy another application.
So if you're running a Gtk app in a sandbox like Flatpak or Snap, Gtk will use the Xdg file chooser portal[2]. In GNOME, this is implemented by an application (in the host) which, itself, creates a GtkFileChooser. In the future, it could be a beefier application. One benefit of that taking a while to happen is, once the implementation gets fancier, there won't be too many weird mismatched applications.
(Also, I mention GNOME, but it's important to notice the file chooser portal is itself platform neutral; KDE apps use this, too, and the implementation depends on what desktop you are running. Yay, decoupling!).
Not everything uses GtkFileChooserNative, but pretty much any recent Gtk app that doesn't have weird requirements probably does. Off the top of my head, Firefox, Secrets, Bottles, GNOME Builder and GNOME Text Editor (although they still ask for access to all of the of the files for other reasons), … even Slack and VS Code! (Electron switched over recently).
[1] https://docs.gtk.org/gtk4/class.FileChooserNative.html
[2] https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...
3 replies →
You'd need some way to inform the window manager that "windows from this process should be considered modals over this window of mine" - probably something that's in the realm of the possible to hack together?
18 replies →
GNOME often rejects the ideas from the rest of the ecosystem.
It's a matter of human resources, gtk3 is an extremely small team compared to its influence.
2 replies →
>> It's unfixable behavior because the GNOME devs stopped respecting their own gsettings, org.gtk.Settings.FileChooser location-mode, to FORCE the path-bar experience on everyone. Because no one needs to type file paths, apparently. So why bother respecting the settings for path-bar or filename-entry?
Control + L will turn the path bar into a simple string w/ autocomplete. Am I missing something here or are you talking about pasting a path into the filename portion of the dialog?
Hiding important features behind arbitrary keyboard shortcuts is definitely on my list of things I hate about modern desktop environments. (Not to mention, extremely unfriendly to accessibility.)
i installed a new debian box for work and i forgot to choose xfce4 so went with the default. gnome 3. i tried. i tried so hard to get used to it. for 2 horrible months i tried.
i only need a terminal, emacs, browser, thunderbird, the occasional screenshot and it was still horrific.
to be clear it was only the usability that was a nightmare. i experienced no bugs. it's solid. but wow it is unusable.
please, please, please someone at gnome headquarters ... can you make it usable? look at win10, win11, macos, kde, chromeos they all work fine. can't you do something like that? i believe you have the best software stack out there, and you're throwing it away with that frightful design.
this is tragic.
This is purely my impression and not something I could prove, but it feels like Gnome wanted to have an out-of-the-box Mac-like experience, while not really understanding while people like using Macs. "You don't have a million configuration options on a Mac, so neither should we!" doesn't account for Apple having whole departments working on UI things, choosing sane defaults, etc. People don't like macOS because it doesn't give them options, but because it tried to make good decisions and patterns so that they won't need to tweak everything.
I know lots of people don't like Macs because they're not super tweakable, and that's fine. It's still my impression that Gnome is aiming for that target, while not quite understanding why a lot of people do like Macs.
2 replies →
No idea what problems you encountered, but I find Gnome to be a joy to use. It was such a relief after years on Windows. Gnome Boxes is such a smooth experience compared to VirtualBox. Maximizing content area by putting UI elements in the title bar is also something I appreciate.
1 reply →
The biggest problem with GNOME is that the organization needs to get their shit together. Their priorities and design choices are awkward at best so I must say they don't care for their users at all.
GNOME's design choices are either extremely good or extremely bad. I like the general workflow, but the panel looks like some crummy i3 config. You could almost get rid of GNOME's panel altogether, placing the network icon etc on the "Applications" view. You can't even switch Audio or Bluetooth devices using the panel. It's dead real estate.
this is seriously a mystery to me. how do people use gnome? how can you be productive with it? i tried so hard: https://news.ycombinator.com/item?id=31782882
5 replies →
The file chooser has been broken since at least gnome 2, and was antiquated in the gnome 1 days. I don't believe it will work in gnome 4.
I understand how things get this way, but it is a super easy problem to fix:
1. spin up a new file picker: GTKFilePicker.c
2. add a deprecation warning to gtkfilechooserwidget.c
3. wait 20 years, then git rm gtkfilechooserwidget.c
>The biggest problem with GNOME right now is Gtk3 and gtkfilechooserwidget.c. It is so spaghetti and so many things rely on it that no one at GNOME is willing to work on it for fear of breaking something.
I wonder, why can't they introduce something like gtkfilechooserwidget2.c leaving the original widget intact?
The big guest Jon for me is, in 2022, why write UI code in C? (I say this as one who contributed to GNOME a little (all icons) back in like ’98–’02 and who writes high-performance C++ professionally.)
A lot of work, maybe? Also, bug-to-bug compatibility?
1 reply →
You may know this, but if you type / in the file chooser window, it replaces the path buttons with a text bar that you can type or paste into. I discovered that by accident, probably a couple years after the text bar vanished...
or ~ if you want to navigate $HOME
Try typing the name of a folder that will be found by the integrated tracker search into a gnome file chooser that’s trying to save a file. Then double-click that folder. The results are poor, to say the least.
My favourite idiocy is that gnome-terminal will offset the items in the right click menu and display hex and and octet translation of a number you happen to have highlighted... for reasons.
When someone posted this as a bug because of the obvious unintended idiocies with this a being a default immutable behavior, the maintainer essentially told him to f off and go build his own version.
https://bugzilla.redhat.com/show_bug.cgi?id=1644986
Made another MacOS covert with that exchange, I'm sure.
I don't get your last comment? Everything is going to move into gtk4 or move to other toolkits as gtk3 gets obsoleted, it's the way of the world.
Suspect one of the impetuses behind such stagnation is that in reality not that many Linux users use GUIs to do file stuff as so many of us live in the command line.
>> Suspect one of the impetuses behind such stagnation is that in reality not that many Linux users use GUIs to do file stuff as so many of us live in the command line.
GTK is a GUI toolkit. It is literally made for building GUI applications. The Gnome developers are building a graphical DE. Your reasoning doesn't seem to sensible to me.
12 replies →
Gtk3 filechooser worked fine until 2014. Distros with gtk3 released before this have a gtk3 lib that handles pasting file paths in the file chooser and the gsettings still work. My last desktop with functional Gtk3 is Ubuntu 14.04 on Extended Service Mantainance (ESM) support. But it'll age out of support fairly soon.
My top gtk3/gnome 30 wtfs:
- the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
- missing top menu (but a bar is still there wasting space for a ... clock wtf)
- general window positioning; like, if you open an app, rather than just opening a window as new top window, gnome opens it behind others and pushes a notification "FF is ready" wtf
- mainstream desktop apps not ported to dark mode, so those icons look even more puzzling
I could go on, but I'm definitely leaving gnome/gtk apps behind. I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB. I'm also totally not looking forward to wayland, containerize-all-the-things such that basic file workflows stop working, and other attitudes, all the while the apps I'm using are exactly the same I've used 15 or 20 years ago, without new ones coming.
I think I'm going back to Mac.
>> the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
That one drives me insane.
>> general window positioning
I want my applications to come up where they were when I last closed them. This used to be up to the app under X, and I'm fully on board with the Wayland idea that an application shouldn't know or be able to modify its window position. But that means putting things where they were is the DE/compositors responsibility now, and I fear they're going to fight that idea forever. I hope I'm wrong though.
> I'm fully on board with the Wayland idea that an application shouldn't know or be able to modify its window position
Why? Genuine question - that sounds like an incredibly opinionated position for the display server to force up the stack, and I don't have a good intuition for why it should be necessary.
15 replies →
I got used to type slash(/) which opens file input field when ever I'm pasting file.
With respect to the Wayland devs, as they've been fighting more than an uphill battle for a decade now, but that is so bone-headed.
If their design philosophy is like this in general, no wonder no one is adopting it. It's just a worse X.
1 reply →
> I could go on, but I'm definitely leaving gnome/gtk apps behind. I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB
Kubuntu was my first distro and posts like these reconfirm my decision to stick with KDE.
I wish it was mine too. I would have gone for Linux as my main OS lot earlier.
> - the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
I deeply hate this one, it always gets me when I'm saving in a hurry.
And let's not forget about buttons on windows title bars. Someone please tell GTK developers that most of us aren't using tablets; computers with actual keyboards and mice are here to stay for a long time.
That one drives me absolutely fucking batty. Nobody uses GNOME on the touch screens that the UI was clearly designed for, and moving the default requestor buttons out of the bottom right where literally every single GUI of any note throughout history puts them is a particularly galling bit of NIH snowflakery.
1 reply →
> I think I'm going back to Mac.
This is poor conclusion imo. KDE might better suite your needs. Plus, macOS comes with its own wtf's: https://medium.com/@parttimeben/mac-it-just-works-horribly-c...
Yes I'm aware Mac OS isn't a panacea either (used MacBooks/PowerBooks and Mac mini on and off alongside Linux since 2003). But I had such a craptastic experience with PC hardware lately: on my 3rd Dell Latitude/Precision with battery and other hw defects ootb sent by customers for work within 8 months, and my 2019 Thinkpad has a stuck trackpad - miniscule as it is - due to completely unused mechanical parts (buttons, think point, and whatnot). Meanwhile, M1/2 MacBooks leave x86 notebooks in the dust performance-wise, and have left PC notebooks behind in terms of screen resolution for a long time now, also wrt trackpad and keyboard, and value retention, it's not funny
2 replies →
Mine is that they kind of abandoned Vala and then started using their own JavaScript engine for everything beyond bare bones Gtk+.
The slowness and leaks of not having a V8 class implementation, has made me embrace XFCE for the surviving device I still run GNU/Linux natively on.
And to think 22 years ago I was arguing for GNOME, advocating for Gtkmm versus Qt.
"Their own JavaScript engine" is Mozilla SpiderMonkey 91.
https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Home.md
It appears to be broadly competitive with V8.
https://www.anandtech.com/show/16078/the-2020-browser-battle...
3 replies →
> - general window positioning; like, if you open an app, rather than just opening a window as new top window, gnome opens it behind others and pushes a notification "FF is ready" wtf
I like this behavior. It only happens for apps that take too long to start. When an app takes too long to start, it is usual for me to continue doing other things while it starts, when it starts, I don't want it stealing my focus. I think this feature works exactly as intended.
You prefer a notification to steal your focus instead? :)
1 reply →
> general window positioning
This has worked as expected to me. It generally opens windows on top of the stack unless the app takes too long to start and you've interacted with the window on top. In that case I appreciate it doesn't change focus (I could be typing something for example).
I started with desktop linux with KDE2, and KDE3 was... seemingly perfect. I watched some colleagues move to KDE4 when it came out and it felt like a ... mess. I tried it myself for a few days and it was too foreign. Never cared for gnome as a main desktop, although I do recognize gnome foundation did provide a lot of useful software over the years, some of which I used.
Moved to mac for main desktop around 2008. I look back some times and KDE5/plasma/whatever might be worthwhile to check out again. Mac annoyances are piling up over the years, but I suspect it would be "the grass is greener" somewhere else, and I'd find a lot of the KDE annoyances which led to me leave may still be there.
If you're a KDE 3 fan, https://trinitydesktop.org/ is actively maintained.
Same here. GNOME 2 was just about perfect.* KDE 3 was even better. Rock solid and lots of excellent, well-integrated functionality. Everything after those two have been a showcase of failed UX experiments.
* (It's successor MATE has not aged gracefully, unfortunately.)
1 reply →
> I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB
I'm curious, what do you expect won't work under KDE?
Nothing in particular; maybe third-party apps like MS Teams (ugh) I need for my customer projects (which also didn't work right on gnome for years, and had trouble when switching logins/customers), that kind of stuff. I considered kubuntu, but thought I was leaving Ubuntu mainstream for good anyway, so why not go to eg Slackware w/ KDE Plasma and say goodbye to systemd, snaps, and containerized browser behemoths that want to update themselves all the time anyway. Don't want that shit on my main machine period. I'll be keeping my old (Ubuntu 16.04 ESM and 20.04 LTS) notebooks around just in case, but customers keep sending me shite notebooks, and MacBooks are more than capable to run Docker crap anyway.
2 replies →
I ran into not being able to open Nautilus as an admin without having to install some packages through apt. Why is Linux the only OS that doesn't allow me to edit or view a system file out of the box?
Gnome people basically looked as how Apple managed to be firm about design and though they can be even tougher since they do it for free.
Such reasonable / obvious requests linger for decades and after a while the system has been rewritten and bugs are auto-closed.
I no longer report any bugs nor care.
I loathe all auto-closing so much, it's such a cheap way out of issue triage. The ostrich method of project management. It's a good red flag though, I know not to waste my time on the project. Who knows what major issues have been auto-ignored.
It can be especially inane if the issues are also locked automatically, you're already ignoring the issue why the f can't you let people discuss workarounds or request reopen.
Firefox Android did that and I stopped contributing. It's not even that I hold a grudge, but the ostrich method is extremely frustrating to the reporters
I keep hoping someone will be gutsy enough to build and deploy a bumpbot (or bots!) to combat stalebot.
4 replies →
This is the thing - if you're going to be like Apple and dictate design, you have to get it right. macOS and Apple hardware is not to everyone's taste, and they make mistakes, but they prototype and dogfood and iterate like crazy and they have thumbnails in the damn file picker.
When you're picking a file, you can even tap space to get a blown-up preview of an image or PRF. I use this feature almost every time I need to pick an image.
One thing I'll give Apple credit for is in the early days of OS X, they had (and perhaps still have, if it's the same thing) a document called Human Interface Guidelines. They actually did real experiments with real people and came up with a set of UI patterns that were proven by science to make software features and UI discoverable, usable, and clear, with the least amount of cognitive load.
Things like, the buttons on a dialog should should be a verb indicating the _action_ the user wants to take. Like "Run This" and "Go Back" instead of "Yes" and "No". (Or worse, the old Windows "OK" and "Cancel", which is rife with ambiguity in so many cases.)
And the tone of the document was that it was intended to be useful to _all_ user interface designers of all software and on all platforms, not just OS X. I just skimmed over the current edition and as far as I can tell, these days it's basically just about how to stay "on brand" with the Apple experience when writing your own UI.
4 replies →
> When you're picking a file, you can even tap space to get a blown-up preview of an image or PRF. I use this feature almost every time I need to pick an image.
Wait, what? That would have been super useful, but how was I supposed to find out?
4 replies →
> I no longer report any bugs nor care.
Past that point years back, kept going.
I just don't use anything Gnome related, if I can help it. I have found some things that unfortunately use the toolkit and somehow manage to not be intentionally irritating, but I assume that's an oversight to be corrected once I'm dependent on it.
Like is too short to use irritating software.
This 1000x. Apparently it's called being "opinionated" nowadays.
Related:
GNOME has no thumbnails in the file picker and my toilets are blocked - https://news.ycombinator.com/item?id=25719796 - Jan 2021 (724 comments)
This comment might come off a little off-topic but I think it's pretty related.
The Gnome Project has always struck me of having this Apple-Like attitude of "We know Best", and subsequently ignoring/shrugging off user concerns/issues/etc.
It's pretty obvious that Gnome is at the very least "inspired" by macOS. Heck Apple started version bumping by whole numbers at right about the same time Gnome switched from 3.x to 4x.
I use it on my Touchscreen Convertible Laptop (with Wayland), since it supports multi-touch gestures (on the touchpad too), and as long as I install extensions to bend Gnome to my will, it seems to work pretty darn well for me. (For example, adding window tiling with the https://github.com/Leleat/Tiling-Assistant extension).
Perhaps there is a better way that I should switch too, but currently I remain ignorant.
At this point, it has become evident that they don't "want" to support this feature. So you're limited to what KDE has to offer if you need this.
Personally, I've bailed on the whole DE thing. Take the tiling-wm-pill and move on. Now I have to deal with tumblerd random high-cpu usages and thunar's unexpected crashes.
I've not seen anyone using a tiling window manage with 32" and larger 4k displays. It's just an awful experience.
I would use a tiling window manager (and have) on something like a chromebook or if I'm a youtuber that does everything in a VM at 1080p. I have a hybrid approach that I use with XFCE (aggressive window snapping with custom shortcuts), but it's hardly a typical tiling window manager experience.
Regarding Thunar, I don't have any issues, but if you are not using it in XFCE, you might want to try and see what plugins you are loading. Some expect XFCE and could be the root of your issues.
> I've not seen anyone using a tiling window manage with 32" and larger 4k displays. It's just an awful experience.
I'm using i3 / sway on both, my Workstation's 40" 21:9 (5120x2160) and my private 32" 16:9 4K displays, and see no reason why a bigger display, or one with a higher DPI, would make using a tiling window manager working worse, on the contrary, for me, it's all the more important to have good management if I got more "screen estate" to handle.
IME using tiling WMs on bigger/HiDPI screens is a fantastic experience.
4 replies →
I’ve never been able to make tiling work for me regardless of screen size. Windows constantly end up being awkward sizes that cause scrolling that would be unnecessary in a floating WM, and I’m constantly tweaking window sizes to try to make it less awkward. It’s very micromanage-y, and it drives me nuts.
But I don’t live in a terminal and/or text editor — my most frequently used programs are IDEs, VCS UIs, and graphics editors… stuff with lots of panes and palettes and such. Simpler apps get use too, but it’s skewed enough that popping some apps into floating mode in a tiling WM isn’t enough. My ideal environment is floating-first with light optional tiling, like macOS with something like Moom installed.
3 replies →
> I've not seen anyone using a tiling window manage with 32" and larger 4k displays. It's just an awful experience.
I do this. How is it a bad experience? If anything I get more mileage out of my tiling WM on my large screen than I do on my laptop, where I tend to just use a lot of full screen apps and change tag/workspace a lot.
Something like i3 would work great on a monitor like that. Something like dwm maybe less so.
I don't (because I have 3 24" displays), but at least two of my coworkers have 32" and larger 4k displays and use i3
Meh, I'm so disilluded that I've resorted to using nautilus as my file picker and just drag 'n dropping files from it into the program I want to open the file with.
Maybe you’ve tried it, but Xfce as DE plus i3 is for me the dream team.
I've done this. First I did pure BSPWM, then pure i3. Frankly, it's just too light for me. I spent so much time having to handle all these one-off scenarios like, hot-plugging multiple monitors, bluetooth, audio volume (with switching output when I plug into my big monitor). I had cobbled together so many scripts and I was constantly fighting with something that had worked the prior day. Having an actual environment under the hood made it much nicer.
I've had some weird issues with thunar too. Currently using spacefm after trying several options.
> Take the tiling-wm-pill and move on.
But that doesn't really solve the issue with the file picker...
Yes but in a tilling setting, a new window (say Thunar), right beside your main app is just a single key-combination away. And it places the window correctly too. So you can drag-drop the file and close the auxiliary window.
Also, since a twm is not tied to a DE, you can pick KDE set of apps for example in i3. Then you'd have a file picker with thumbnails.
That said, I do neither of those things and I suffer from this bug. So you are right in a sense.
I'm beyond grateful the Qt is not engineered by KDE.
I am now running a hybrid setup with KDE + i3. It works really well because I get to have all my network settings, display settings, etc on the fly, I can use konqueror, and i still get i3 nicely.
Except... It is. There are a lot of contributions by KDE volunteers to Qt.
Luckily for the Gnome team, Microsoft ripped out features from their desktop interface in Windows 11. So Gnome might look comparatively functional when Windows 10 is EOL.
I came to Linux from a Windows world, so KDE always made more sense to me. I think, with the exception of 4.0, KDE has been fundamentally less bad than gnome since at least 2002. A sweet spot for me was KDE3.5 and then again current day KDE plasma. I like the customisability.
I think the gnome foot is a better icon, though.
I suggest searching for JWZ CADT for a 19 year old article describing the same class of problems with Gnome.
My pet peeve: "<ctrl>-s filename <enter>" does something horrible instead of writing to filename.extension.
Why no just link it: https://www.jwz.org/doc/cadt.html
Anyone who still has their brwoser sent cross-site Referer headers in $current_year deserves what they get.
The file picker has always been one of the weakest parts of our GUI paradigm, and it has been since the Mac.
Navigating file system via GUIs is slow, painful, and for me takes a ton of cognitive effort after a short amount of time of accumulating files. Coming up with a system for organizing files is kind of hard in itself. Reorganizing as the number of files outgrows the system is also painful.
And choosing a place to save a file is often the best time to start a reorganization. But if I save a file in a new location, having to switch apps and now go back to that same spot in the hierarchy and reorganize is painful.
I don't have a good solution, just complaints, unfortunately. But after ~50 years of GUIs and hierarchical file systems I'm surprised somebody more clever than me hasn't come up with a better solution.
This comment reminds me when Apple revamped Finder to include "All My Files". To me it felt like they were giving up. "FINE! Can't find something? HERE'S EVERYTHING!"
These sort of pseudo-directories honestly bother me more than just plain old hierarchy. For example on Windows, "This PC/Documents" is really "%userprofile%/Documents", but to get to %userprofile% you have to go to C:\Users\<username>. But there's TONS of other stuff that lives in %userprofile%
That's an example of a badly thought-out hierarchy. The pseudo-directories should be something like "This PC/My Files/Documents".
But it's not a good reason why pseudo-directories are bad.
There's few things I despise more than the "All My Files" view, because it is so useless to me. Perhaps it works for some, however!
And it hasn’t evolved with cloud/sandboxing/magic-paths/whatever. Like today on the Mac I used the popup directory path to try to navigate to the parent directory (since it showed it to me, and it was selectable) and it couldn’t; it just threw me to my home folder as if that was my request. I can only assume it was some weird cloud thing but when path navigation itself is a question mark we have problems.
I've used KDE all this time and never noticed. Try it, it's not heavier than LXDE nowadays, which is saying something!
KDE 5.25 is very exciting, it feels great being on a desktop that gets updates where features are added instead of removed. Definitely the place to be in 2022!
I love the fact that right there on KDE.org there's a screenshot of Kontact with that big obnoxious vertical "HTML Message" black bar in the middle of the screen. I remember reading a bug report some 10 or 15 years ago to allow it to be hide-able somehow at least with the author just flat-out refusing to do it or allow patches for it.
I'll never use Kontact for this reason but I do like most of the rest of KDE.
kde gang
> First of all, how do developers so casually ignore this issue?
GNOME has never struck me as a project interested in implementating polish work. Polish work is disproportionately hard (it sometimes upends your understanding of the problem, forcing you to rethink your core structures, which impacts other features. In short, polish work has a tendency to explode).
> Second of all, how do users so casually ignore this issue?
GNOME users are accustom to polish not being the priority of the developers. Those who couldn't take it stopped using GNOME.
> GNOME users are accustom to polish not being the priority of the developers.
Wasn't the whole spiel of Gnome 3 that it was all about "UIXP" and perfection on defaults, sacrificing power-user functionality if necessary? That's effectively all about interfaces that do very little, but do it very well - i.e. they are super-polished, if less featureful.
It is true, though, that a lot of people stopped using GNOME. In fact, despite Ubuntu and RedHat effectively pumping users into the ecosystem for years, most Linux folks I know use either KDE or boutique DEs.
I don't know enough about GNOME's history, but I wonder if the people making those promises fell into the trap of believing that a more polished desktop environment would be one with cleaner code, and when they said super-polished they meant clean abstractions.
A super-polished UI (in the sense of "well-rounded, meets expectations, minimizes user surprise, behaves predictably") has messy abstractions because humans are messy. I've never met one that looked good on the outside and didn't have ugly snaggy bits on the inside to get all that good-lookingness to actually work in the corner cases. Perhaps GNOME has fallen into the trap of sacrificing features for purity of form. If they're saying things like "We'll have thumbnails when someone can figure out how to do it cleanly" they've fallen into that trap.
> sacrificing power-user functionality if necessary?
Scratch "if necessary". Power users have privilege, so deliberately throwing them curveballs for the sake of equitable outcomes seems to be the GNOME way.
1 reply →
Thumbnails are not polish. They’re an essential feature of working with images.
The devil's advocate response is "How essential could they be? We went decades without 'em."
I don't think it's the right answer, but it's an answer that works (GNOME continues to be the dominant Linux desktop environment in spite of lacking that feature).
4 replies →
If Apple or Microsoft had something like this "misfeature" in their OS, they could and likely would lose sales.
GNOME has no customers and can't lose sales, therefore they don't have to care at all.
> If Apple or Microsoft had something like this "misfeature" in their OS, they could and likely would lose sales.
I disagree. Microsoft and Apple[1] had both had immense blunders that users hated, yet those users still paid money for the blunders.
At least with Gnome, people switched.
[1] I've used almost all the Window Managers and Desktop environments since 1995, I've used Windows since 1995. The current apple GUI is more painful to figure out than I had expected when I started using it last year. It's easily one of the least intuitive environments that I've come across, and watching non-tech users struggle with it reinforces my point.
1 reply →
I mean, GNOME is the default on several commercially supported distributions. Redhat is the largest contributor. Granted, a lot of those commercially supported distributions are for customers who don't care about GUI uses but Ubuntu and RHEL/Fedora have a decent number of workstation users. KDE/Plasma have much less commercial support (AFAIK) and are probably closer to what you're saying, but at least to my tastes manage to be much more sensible.
1 reply →
Yet GNOME is the most polished Linux Desktop Environment.
It's easy to polish something that doesn't have many visible parts.
Isn't this a problem with open source in general?
It's hard to coordinate and improve software effectively among people with different ideas of what something should look like.
This is why Windows and Mac will always remain dominant desktop operating systems, I think. It only takes a few issues like this for a user to give up and go back to the big two players.
I'm not sure what the proper term is but having thousands of MS developers working and being led by managers, defined organizational processes and sense of direction vs hundreds of thousands open source developers led by their own ideas, what good and should look like, and different motiviation, a lack of coordination and a organisational process as big as a paragraph inside an obscure README.md
Too many cooks in the kitchen sour the soup.
Except for the part where tons of people are up in arms because MS removes or changes their UI. Fisher price, new control panel (XP), vista, UAC, start menu search, ads, mandatory logins, new control panel (8/10/11), new inflexible taskbar and so on
Except for the part where all of those people are Linux users who complain about Windows as a hobby, and have no effect on the relative market shares of Linux/Windows because they would never switch back to Windows under any circumstances.
2 replies →
This is probably why Linux has been such a large success. For all the submissions, suggestions, filtering by those lower down the chain...at the end of the day it's Linus that says "Yes" or "No". (And/or chews people out for bad code.)
That's the kernel. DE's are their own beast.
> Too many cooks in the kitchen sour the soup.
That sounds like a translation from another language? The English idiom is remarkably similar: "Too many cooks spoil the broth"
Everybody wants to make it into the "Too Many Cooks" credits.
https://www.youtube.com/watch?v=QrGrOK8oZG8
(Is that RMS with the machete?)
Since the comments here are rapidly turning into a "dump on GNOME" section, does anyone know if there is a master list of "What the GNOME documentation calls an application" <-> "What everybody else calls an application"
e.g.
- "Passwords and Keys" <-> "seahorse"
I want a master cheatsheet for gnome commands too. These are some of the commands I needed to memorize when working with gnome:
nautilus <-> File Manager
evince <-> Document Viewer
eog <-> Image viewer
baobab <-> Disk Usage Analyzer
Tbh KDE is worse at this because at least when you are using Gnome it won't call Nautilus Nautilus. It will call it Files, unlike on Plasma where Dolphin will be called Dolphin instead of being called Files or File Manager, which means that people who don't know Dolphin is the file manager will just be really confused as to what Dolphin is, especially if they don't already know that this icon always means file manager no matter what 0S you're on. Linus actually had this issue when he couldn't figure out what Kate was because he saw Kate and he thought what's Kate. Whereas on Gnome it would just say Text Editor instead of gedit. If you are using the terminal, you are more likely to know the actual name of the program so that's less bad for me. And on KDE if you are opening graphical applications through the console, you still have to open them through their weird code names. For example, Dolphin which makes no sense whatsoever. Just the same as Nautilus makes no sense whatsoever so that arguement is somewhat disingenuous.
6 replies →
Can anyone explain why this bug has gone so long without a fix? Is it technically challenging to fix, or does the Gnome team disagree that thumbnails are necessary?
I read over the ticket[0] and from what I could see it was mostly bickering about the format of the patch or something. I didn’t really see any “ba humbug, command line is all you need” kinds of posts from some graybeard.
So in short it looks more like an organizational problem than a technical or even political problem.
[0] https://gitlab.gnome.org/GNOME/gtk/-/issues/233
More like a disorganizational problem.
https://en.wikipedia.org/wiki/Conway%27s_law
>Conway's law is an adage that states organizations design systems that mirror their own communication structure. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967. His original wording was:
>Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
>— Melvin E. Conway
In Gnome's case, the structure of its design is a copy of its disorganized communication structure.
This reminds me of the problem with scrolling on Chromium, and now because of Electron a whole bunch of other programs. A single click of the scroll wheel moves the page by 100 px on Windows, for some reason it’s only 53 px on Linux, which means scrolling is twice as slow. This is not just compared to Windows, but it’s also much slower compared to other native Linux programs.
If you search for this issue, there are countless discussions and half broken attempts to work around this problem, including Chromium bug reports including some that are now nearly 10 years old. It’s 2022 and scrolling in Chromium and Electron apps with a mouse on Linux is still unbearably slow with no way to adjust that. There used to be a hidden CLI option, which was added for ChromeOS which probably had the same issue, but that was later removed.
The best solution I found so far is running patched libinput that multiplies the scroll amount delta by whatever you want, and having a daemon running which watches the window that is currently being scrolled and alters that scroll multiplier accordingly. It’s absurd that this is what I have to do to get acceptable scrolling behavior with a mouse on Linux.
The program "imwheel" helped me work around an issue like this.
Have you tried disabling smooth scrolling?
Wow, I just read a rant on a site that hosts static websites, damn I miss that! Sounds like this person needs to snake his sewer line.
I found this article funny, engaging, and touched on a point that I’ve had for years about Linux on the desktop. (I won’t spoil it)
> This file picker does not have a thumbnail view. It is broken software. Thumbnails are not a cute little extra, they are essential. This is as bad as a file picker that doesn’t list the name of the files, only their creation date, or inode serial number. It is broken software. No, individual file previews aren’t "thumbnails."
As is unfortunately typical of articles like this, it overstates its case to the point of making it difficult to engage with. No, it isn't as bad as a file picker that doesn't list the names of the files. No, for most things one uses a file picker for, it isn't essential.
For that matter, I was actually completely unaware that my file picker (I use KDE) supports showing a thumbnail view. I did not know this because I have not ever needed to use such a feature. I use the file picker in "details" mode exclusively. On the rare occasional where I need to disambiguate two files because I don't know the name of what I'm looking for, the image preview has been more than sufficient.
I'll certainly grant that this is a feature that it makes a lot of sense for a file picker to have, and for a handful of use cases (trying to find a single image in a large directory of badly named image files) it might even be essential. But this tendency to overstate one's case is at the very least irritating, and IMO it leads to unwarranted attacks on developers that makes people shut down and resist spending their time on solving your problem.
> it’s much easier to accept mediocrity than to pursue adequacy.
pretty much describes most of today's software
File picker horror? Use the built-in file picker of Javas own Swing-Toolkit.
Integrating a GUI into a programming language library is inherently wrong. And while Sun was on the wrong path they doubled down and spread it across multiple platforms because they assumed their GUI was a solution. It wasn't and luckily Java based applications disappeared - with the exception of Java based developer tools.
This seems to be a Linux exclusive problem. In general Linux is great, but there's so many people that really don't care about usability.
The problem with open source is that programmers often set priorities(Which is why I'm a fan of Cathedral model software).
FOSS programmers love to program so much, that everything they write is usually a tool to help make other programs.
Without outside feedback, or some kind of strong mission to really focus on the mainstream, the whole entire ecosystem can turn into jusr one massive IDE made of loosely coupled utilities.
Dude, please, please get your drains fixed. It's bothering me now.
I finished the article unclear whether or not the toilet story is a parable.
> This bug has received over one hundred comments over the course of nearly two decades.
This is best counter argument to the old saw that “Open source will always get better.”
Yo... You know what's more retarded on this GNOME screenshot https://jayfax.neocities.org/mediocrity/Filepickermeme.png than the absence of thumbnails? The button order. Don't use GTK. Ever! Do you get me? [No][Yes]
This is a weird hill to die on. I've never cared much about the file picker and the individual file preview is "good enough" to ensure you pick the correct file. Now if Nautilus didn't have image previews in "icon view", then that's cause for rioting in the streets.
That just tells me that you never upload images, or that your image folder is not particularly large. If trackpad drivers were broken, that would still be a pretty big issue, even though you personally always use a mouse.
I upload files all the time and for some reason I don't encounter this problem in gnome. Just give the files appropriate names?
Seems like a channer problem. It's not suprising that no one from /g/ has made a patch yet.
Edit: Actually, I just checked and apparently it's because the file picker actually does show thumbnail icons, just very small ones. For example, https://files.catbox.moe/h3s3c3.png
I guess I can usually make out what the image is from the small thumbnail icons!
19 replies →
You'd expect the file picker and nautilus to share behaviour though, right? Also for me, if I open the file picker from Chrome/Edge/an Electron app it's forced full screen and there's no preview on the right either.
I love GNOME, use it on both desktop and laptop, but this is one of those things that's just bad.
I definitely agree that it's strange that Nautilus can do this and the file picker can't. I also agree that consistency is important, but this issue has never caused me problems so I don't think anything of it. There are other things in Gnome that are keeping me from using it after being a vocal supporter for decades.
2 replies →
I don't have image previews ;)
Huh... I just opened Pluma in MATE and used the file opener, and it had image previews in the list view. I never really paid much attention to this though, so no idea if the MATE team added it or what.
They are a bit smaller than I'd like though... let's see if there's a configuration option for that.
> Huh... I just opened Pluma in MATE and used the file opener, and it had image previews in the list view. I never really paid much attention to this though, so no idea if the MATE team added it or what.
But, MATE isn't Gnome. That's almost their slogan, how could you not know?
Heh. Well, it's a fork of Gnome2 which was their main selling point. I just can't remember if these previews existed in Gnome2 before the fork or not.
Per TFA:
> No, individual file previews aren’t "thumbnails."
I mean that every line in the file picker has a small image beside it. It's just that since it's a list view, they are a bit smaller than I'd like (set to line height). I guess increasing line height or font size would help. Nonetheless it's good enough for roughly figuring out what image is what.
I tested both in Pluma and Firefox - this seems normal for MATE file pickers, but I don't know if it was normal in Gnome2 as well and I never noticed.
1 reply →
I read the entire mediocre post. I need to take a dump now. Luckily, my toilets both flush, so I can choose whichever is most convenient. Right now I wish I had a third one in the basement, but that would require a pump, which would likely fail.
The Gtk file picker has for years offered a notoriously horrendous user experience. A lot of critical functionality is missing in the name of the GNOME people's vaunted simplicity or what-not.
... although reading superkuh's comment, maybe the explanation is more mundane (and sad) than that.
the sad situation of desktop Linux is kind of reminiscent of democracy and how people work in general.
In case anyone is interested: https://gitlab.gnome.org/GNOME/gtk/-/issues/233
This was reported before some HNers were even born.
Someone remind me: When was the "Year of the Linux Desktop"?
1994, for me...
20 years after heat death of the multiverse.
For me it was around 2008, when kompiz came on Ubuntu ... those were good years.
When I try to attach a file in Chrome on Linux, it shows a file picker that defaults to only showing files I recently uploaded, which is the exact opposite of what I want.
Switched to KDE because of stupid crap like that. Never ever looked back
My advice: download a live-system with a KDE desktop and give it a spin, maybe?
Here is the ultimate problem with GNOME. It is essentially a lie.
What I mean: Imagine you bought a ticket for Matrix 4, and they showed John Wick.
That's what GNOME 3 did. They made a new and different product; whether you like it more or less than the last one isn't the point. They betrayed the reliance we had on the old thing by a "lie of omission." A more honest approach would have been to name Gnome 3 something different (and perhaps hand the Gnome name off to the MATE people?)
Except John Wick has been better than all the Matrix movies but the first
That actually doesn't contradict my point. It's fine if you like it better, the problem is pretending it's the same thing.
so the technical question then is: how can i replace the file picker that the apps on my desktop use?
a startingpoint for answers may be here: https://superuser.com/questions/944119/replace-gtk-file-dial...
there is an xdg-desktop-portal feature that allows this, or pretend that a different desktop is used by setting XDG_CURRENT_DESKTOP for the application, as well as KGtk which is a library that can be loaded with LD_PRELOAD.
either of these have to be applied per application though.
Fork those apps, remove GTK, add Qt.
stick a note onto the commode or the toilet door that reminds your family members of the fact.
This is a great example of "that's an explanation, not an excuse", albeit a weird one
O_o
Gnome design is sometimes weird.
With recent donation from Microsoft, GNOME will surely fix this critical issue, right?
Is that a blog of someone from Trolltech? Tell them their site doesn't support OS-managed dark theme switching.
— No, using custom CSS isn't "dark mode"
> No, using custom CSS isn't "dark mode"
I mean, in this case, it literally is as easy as adding an alternate CSS style and then managing the proper dark-mode switching.
...not that this is really a concern in the first place. If you read through someone's blog and the best comment you have is on their website's OS integration, I think you've got your priorities misaligned.
Easy is a comparative evaluation.
To someone it's easy to recompile Nautilus with one of the thumbnails support patches or implement thumbnails generation via an external script.
Literally.
Yes it does. I'm looking at a thumbnail in my Gnome file picker right now. I'm on Fedora 36 (Gnome 42)
Edit: It looks like the specific complaint is that the Gnome file picker does not allow icon view. That is true, but I still see two thumbnails: one next to the actual file, and one in the thumbnail pane.
A better title might be "Gnome has no file picker icon view and I create flamebait titles."
As a longtime gnome user I knew exactly what he meant. Icon view is what we want. The others are practically useless for quickly identifying a file.
A "thumbnail" that's one tenth the size of my actual thumb's nail is hardly deserving of the term.
Well written though
ls doesn't show a preview either.
When forced to use windows the first thing I do is turn this feature off. Something doesn't feel right when a tool to list files tries to process content of files (e.g. image processing did come with severe security holes in the past, and it probably still does today).
Both of my toilets are working perfectly though.
Your toilets work because you keep a jug of water next to them to pour directly into the bowl to flush it, because you disconnected the toilet tank. You've decided that a tool that tries to remove waste shouldn't also intake water. After all, intakes have failed in the past and flooded houses.
Better to do that part by hand to be on the safe side.
This is the nature of desktop UI. Your argument for purity of function is sound, but users want their desktop UI to read images for thumbnails and previews anyway because an image file means more to them, semantically, than a pile of inscrutable bits inside a file pointer. Desktops, over time, become a junk drawer of the features "most users want" for "controlling their computer" in the space between dedicated programs.
file-picker is a GUI tool whose language is visual instead of text. If ls must do text processing and formatting to output that colorful list, so too must file-picker do image processing to complete its function.
The writer seems willingly disingenuous. Not having a feature isn't the same as having a bug. The software is behaving exactly as designed. Do you say that older versions of windows develop "bugs" as soon as a newer version adds a new feature? Of course not.
I agree with the conclusion though, these little missing conveniences add up to a worse experience for converts. I understand open source apps choosing not to do things exactly the same way as proprietary solutions, but we at least need something as good.
That said, it has always been the case that if a feature didn't exist in the pile of software that was freely and openly provided to you, you would either contribute the feature yourself or just go elsewhere. So the bounty would have sufficed, there is no point in being a shithead about it.