This, other UX and even performance (!) issues that have been mentioned in siblings as well as TFA makes the Gtk file pickers easily one of the TOP10 reasons to avoid Gtk and Gnome for anything.
The interaction design of these dialogs is simply shit. Windows (and also KDE, which has been using a copy of the Windows dialog for about 20 years) show how to do it correctly.
KDE is the best desktop experience available.
I agree that KDE still feels better though.
(I actually asked someone more knowledgable about this once and was told that it's my fault for using the file picker incorrectly and I simply need to stop doing that.)
The past 5 years though have been a nightmare, MS has really messed their UI up, and various applications/toolkits or whatever the problem no longer properly support the CUA guidelines which in the past were the one assured way of doing an operation cross applications and various OSs (windows+linux/kde).
Maybe its time to start going to a few developer conferences and giving talks about how useful system wide shortcuts that work across multiple OSs really are.
Control click seems to work.
Some other Gnome apps also work correctly so I think it's fixed in Gnome but not whatever GIMP is using.
That's a degradation from 2.10, or 2.16, from time even before the 3.0.
One of the most frustrating experiences is related to the OP; reflow in browsers as new elements load making it impossible to click on the right thing until the whole page finishes loading. Popups are also nearly as bad but maybe less avoidable.
I remember the first time I encountered the epiphany that "woah, typing too fast can break my textbox/inputs" and coming to the realization that in order to accommodate the faster users you often have to be very careful thinking out your UI flow.
Hence why I hate UI's. Sometimes feels like they are nothing more than a fight between me and another developer.
When you click next page nothing happens long enough to make you think your click hasn't been registered, then right as you click again the page loads with ads right where the button was
That websites and volunteer ui projects get it wrong is understandable- the problem domain is huge. But dragging an app onto a folder is a rather constrained problem that should be easier to solve.
Yet...
The GTK file chooser dialog is easily the most garbage piece of fucking shit. Honestly, sometimes, if I want to post something online I just copy the file to my Mac first just to avoid dealing with the fucking piece of shit GTK file chooser. If I need to sort through a bunch of files, easier to run Samba and sort through them on my Mac, because Nautilus was scooped out of the same fucking pile of shit than the GTK file chooser was scooped from.
As far as I can tell, the last time that browsing files on macOS really changed was 2007, when 10.5 came out and had Quick Look. Since then, browsing files on Linux has somehow gotten worse. Do you know what it’s like on macOS? Every once in a while, Apple quietly adds support for previewing a couple more formats.
Here's the thing that convinced me, a while back: https://wiki.gnome.org/Attic/GnomeScreensaver/FrequentlyAske...
I'm sure there's people here who are long-time contributors and/or supporters. Just ignore me, I'm not your target audience. ... I'm really not sure who your target audience is, though.
We should ask Havoc Pennington about this, he must have names for all the personas that he came up with, after reading "The Inmates Are Running the Asylum": https://mail.gnome.org/archives/desktop-devel-list/2002-Dece...
I actually have a copy of the book, and it is indeed a good book. The problem is that it somehow empowers GNOME developers to keep creating/maintaining/rewriting broken software, all in the name of "usability".
And it is exactly to let themselves yell that, they work hard to alienate few normal devs left in the project.
I understood now that Gnome 3.0 was from the start Redhat's fully intentional attempt to appropriate the project, and is not dissimilar to Microsoft's embrace, extend, extinguish.
1. Get command of some more abandoned parts of the project.
2. Push a series of guaranteedly unpopular sharp direction changes which will lead to loss of devs.
3. As devs leave, you get more reinforcement to your casus belli, saying that "nobody maintains this pile of garbage, so now I am taking it over too"
4. Rinse, and repeat.
Worse yet, its developers consciously make design decisions that make it hard to write applications that play well with GNOME without taking a dependency on it - their take on it seems to be that GNOME is a platform, and their main interest is supporting "GNOME apps", even to the detriment of all the rest.
Between these two things, deficiencies in GNOME affect a lot of people who didn't necessarily choose to be affected.
https://trac.transmissionbt.com/ticket/3685
"I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately ... It is my hope that you are a GNOME app."
And because I have to keep saying this, that is a non-issue now anyway. XFCE supports the new app indicator protocol, and since Ubuntu dropped unity their support for it is available as a standard GNOME extension: https://extensions.gnome.org/extension/615/appindicator-supp...
If you sincerely believe that it's okay to have a single DE be a self-contained app platform with no interop, that's up to you - but do understand that this is a very debatable premise, and people who don't agree with it have very good reasons to be annoyed with GNOME.
I would tell the same to Poettering, Clasen, and co.
There is really nobody who obligates them to work on their "innovations" in GNOME with religious zeal if the rest of the project showed no interest, speaking lightly.
If nobody wants to work on their stuff, they can't claim "victimhood" as if that happens as a result of somebody's ill intents.
I have to reference Torvalds vs. SystemD here as an example how Sievers, Poettering, and co. instantly drew up a picture of kernel community being some kind of a bullying ring when the only thing they did to them was to ignore their (bad quality) patches.
Again, if you are a developer and you disagree with someone's choices, you are free to take it in your own direction. You do not have to work on anybody else's stuff if you don't want.
Is this advice meant to be applied against all people, or just other developers? I certainly wouldn't apply this standard to RIAA lawyers suing kids. I judge them to be worms even though I never worked with them. And don't even get me started on politicians, I've never worked with one but I certainly feel entitled to have harsh opinions about some of them.
If the advice is limited in scope to professional peers, then I have to disagree with it; having double standards for people like yourself isn't great advice.
These developers do not wield power over anyone and they are not filing lawsuits. They are developing code, either as their job, or as volunteers. And in either case, contributing their work as open source.
It might help to take a little perspective before publicly passing judgement on _individuals_ and what you imagine their intentions to be rather than merely judging the merit of their contributions. Those are completely different things.
I get that the two things have some overlap and aren't cleanly divisible. What we do is a major part of who we are.
But I mean, it's one thing to say "I think it [his architecture] is awful", or even "I think his architecture had a negative impact on people/society/cherished values/whatever" but quite another to say "I think he sought the ruination of everything good and decent because he was a demented and feeble mind." Because, yes, I do think the last one would only be appropriate if you actually knew something about the guy...
Edit: And yeah, of course, I'm not trying to censor anyone's opinions. Of course you can _have_ the opinion, you can even express it. I just think that it's not what engaging in productive/civil discourse looks like and, depending on the venue, people may call that out or whatever.
I suspect that, in many instances, people who do that are not trying to convince anybody of anything. If they expected to be greeted everywhere with agreement then they would not go around saying things which they know perfectly well are not likely to result in a vigorous and healthy debate if they were said to strangers in the street :)
From some of your other comments I gather that you've been around this material for a long time and you know a lot about it. Why not share some of what you know, so others can learn? and make your substantive points thoughtfully? Then you'll be making this place more interesting, and your points will have some persuasive power. Just venting only adds energy and credibility to the views you disagree with.
I get that there's a low probability this argument will work with you but I think it's worth trying to persuade people that it's in their own interest to follow the rules, which are designed to try to keep a community that's interesting for everybody:
If we are trying to be good open source citizens and avoid unnecessary fights, you can apply it just to that.
I respect that you are willing to admit you don't know the full history and implore others to understand why for example, certain decisions were made. It seems as if many people love to theorize about what these are, making correlations which are usually driven more by their feelings than reality.
I feel like character assassination was a phrase that I feel aptly describes how I've seen a lot of people treat people like Lennart Poettering. I feel as if some people are unable to separate person from their opinions. Not considering that person like they are more likely to do so if they were in person.
I sometimes feel like this attitude is more strongly felt by some people in a community where there is freedom to take a project in another direction if they desired (I know that not everyone has this option).
I do think however that the article of this thread expresses their opinion on an issue in a way that it explains how it effects them without resorting to emotional attacks towards the project and it's something I really liked about reading it.
In such case disjoint between users and developers is even further. I am professional developer, yet I have zero contributions to my framework and just a few contributions to libraries. After 10 years my contributions to Linux community limited to bug reports, few patches and manuals.
In reality there is not enough community support to maintain existing systems. "Freedom to take a project in another direction if they desired" by individual is overrated, that's TempleOS.
EDITED: Some bragging about making a difference
There are a lot of projects with less corporate influence. No systemd on BSD, but hardware support is not as good. Generic distributions is something that works for most of the users. There are a lot of niche distributions and projects (Void Linux runit!). Current state is just a reflection of users priorities.
You can literally take millions of lines of code that they may have written wholesale, and change a single word in it that you don’t like.
In open source, they have nowhere to hide. If you disagree with a certain decision they have made, you are welcome to take the effort they have put in to implement the hundreds and thousands of other decisions they have made that you do agree with, with a simple “git clone”.
That would be best said to persons named above.
They were free to fork GNOME into their touchscreen based imaginary future, and experiment with it even more freely as a minority group, rather than trying to hijack the project, and getting stalled half-way because of popular pushback.
Again, please do not spread these unfounded conspiracy theories. I can explain more what I mean by this, but it seems unlikely you are willing to hear what I have to say. I can tell you if you're trying to convince me to be hostile towards any specific developers for any specific project, I will have to decline to get involved with that. You don't have to resort to character assassination, if you have some ideas on a good technical direction for a project, just make the argument and write the code: people will listen if your arguments are sound and your code works.
GNOME 2 was a project of 100+ developers.
TOPAZ was a half-baked tablet UI tech demo from a dozen Red Hat employed devs, later dropping to 7-9 regularly active ones.
Tell me what is more to explain about this?
> The reason is simple: Nokia. Nokia (and to a much lesser extent, Intel) built up a lot for Maemo and Meego. Just for KOffice/Calligra, at least twenty people were paid to work on the documents application. For all of Maemo/Meego, the total number of people Nokia funded was enormous.
> And then Elop, and the burning platform, and Windows, and well, that was 2012.
> By 2014, my company was dead, amongst others, and, yeah, the peak had peaked, and the big chance for free software had gone.
I think, in their view, all comes after taking hold of the project. But here, they got that, and now what? Now, all lofty plans have to meet the cold reality.
It's like a mutunineers on a ship throwing officers overboard, just to realise hours later that they are in the middle of an ocean, and they have no idea how to sail a ship without skilled crew.
I saw that happening in public companies: a single asshole activist with puny few percents of the company keeps throwing big radical decisions onto every shareholder meeting, until he gets everybody so discombobulated, or the company so disfunctional that others either leave the company to him for taking, or he gets a legal casus belli to sue the company to try to wreck it further, and then seize it.
For such people, it doesn't matter if the company in question dies, as long as they come out with gain. Some are plainly idiots with too much legal education, and some are genuine degenerates doing it with full knowledge of consequences.
they'd be the only left able to offer (paid) support?
There fewer people contributing because programming in C is no longer fun or hip. It is not Gnome problem but the whole Linux ecosystem. Gnome is slowly adopting rust but the core framework is still C. There is plenty of active forks of Gnome2 people can contribute there.
Nautilus is pretty, and for the most part fairly nice. But lacking typeahead just makes it unusable.
One of the thing I loved about the Amiga was that because of how the API was structured, it was easy to replace things like this, as you could patch every API endpoint. As a result, it took very little time before more advanced replacements for the standard file requester appeared. You "just" had to patch (via OS-provided functions) a couple of library calls.
For complex paths, I found that this is the quickest way to open the file I want.
If it is so, then I must consider switching! (At the moment I am using Xfce.)
Additionally, programs may rely on different GTK versions, which also makes things confusing. For example, Visual Studio Code and Firefox use GTK3.
edit: extended with programs explanation
I actually like background textures for my file manager, so i'm happy this stayed.
But there is also tabbed and two pane view which got axed from Nautilus too.
I must have installed a Linux distribution 100 times with the intent of using it as a desktop and lasted less than a day every time. I’ve been doing it since 1998. Literally something that horrible punches me in the face every time.
I refer back to my comment here: https://news.ycombinator.com/item?id=25678434
I bought a Mac now. I’m too old for the fight.
Everything I do server side is on Linux but the desktop is vile and I want no part of it any more.
I said the same a decade ago. As of last week, I'm back on X11... chipping away at configs for hours and hours and hours.
But I have libnotify popups now. :D
At least now I only have to put up with a slightly dated and crufty interface but I can use my PC to full potential - gaming AND work AND working bluetooth. Crazy huh?
In my case, I also managed to notice that my computer is much faster than it ever was on Linux, which is nice. If I had an old Core 2 Duo Linux would make it fly, but alas, I can afford a modern PC.
The compromise for me before migrating to Mac was using Windows on the desktop with Ubuntu VMs in Virtualbox. I had whole clusters running on my desktop.
Windows 10 is fairly decent on most hardware I have found. If they finished off all the little quality issues, had a decently integrated mobile ecosystem and stopped all the telemetry bullshit I'd be there now. I had some hope back in 2015ish when I was full time windows desktop dev with WP handset etc. Alas the world moved on so I dug the old Unix hat out.
So in that case, Windows is the best compromise. And while I'm still in the proprietary world, I'm outside the walled garden.
In any case, I haven't hit any WSL2 bug or corruption in these 6 months (nor blue screen), so fingers crossed.
I wish you continued fortune with WSL2.
You are not allowed to complain about "Linux" when your beef is really about Gnome.
Linux itself is fine. It's the layers of shit smeared on top that are not.
So many times I would go to a folder, start typing the name of a file/sub folder that I knew was there and it was like “nope! Let’s instead search whatever default directory instead. Apparently this behaviour is by design and alternatives won’t be considered. (This was when I was using Ubuntu 18/19?) at some point they changed a bunch of default things in the UI interface (including getting rid of what I considered was the far superior previous lock screen manager).
pFileOpen->SetOptions(FOS_PICKFOLDERS | FOS_PATHMUSTEXIST | FOS_ALLOWMULTISELECT);
Reference photo: https://en.wikipedia.org/wiki/File_dialog#/media/File:An_%22...
In this, a full path can be pasted in to both the top bar where it says "This PC > WINDOWS (C:)" and also into the blank "File name: | |" box.
I'm pretty sure I remember this dialogue being available since NT days. It seems fairly discoverable to me, clicking in the empty space of the current working directory path changes it to show the text path of the directory. The "File name" box offers autocomplete if you did something like "C:" as a file name, or started typing a folder name of the current working directory.
You could type /tmp/a. and it would autocomplete it to /tmp/a.png
It is a good idea, but I type too fast. So I would write /tmp/a.png and then the autocompletion triggered and replace it with /tmp/a.pngpng
This is so sad.
Autocompletion of filenames should work perfectly no matter the conditions. If "ls" can list tens of thousands of files in a fraction of a second, there's no reason that autocomplete has some delay. I can see why this happens, maybe you have a thousand images in /tmp and the file picker is opening them all to compute their thumbnails (which in my opinion is useless, but whatever). Then it uses quite a few kernel threads and it clogs the system, making the completion to fail. But it sounds like this problem should was already solved many years ago, and that modern "improvements" of the file picker made it fail.
There is a lag when hitting <enter> and the last <down arrow> is processed out of order :/
Edit: Alright, alright, forget the old computer. My new ones get it right too. All of which is a red herring, because the point is this behavior is ridiculous and never should’ve shipped.
It's relatively simple: the picker executes file-opening asynchronously, and only checks which file was selected at some indeterminate point after enter is pressed. In the meantime, the down arrow input in the main GUI changes the selection. The keypresses are always in order.
Whether or not that's the correct decision, it's not an inconceivable design. That example is probably one of the only times it would matter, since you would need async code that cares about some part of the file picker state.
I have never looked at the code in question, but it almost sounds like the developers went out of their way to create these ridiculous bugs, because the simplest solution definitely would not have something like that happen: The handler for Enter gets the current selection (which will definitely be the correct one) and opens it.
The actual opening can be slow, so that can be done asynchronously. But to interpret "Enter opens the current selection" as anything other than the current selection at the time the Enter key event was received is definitely in the realm of rookie mistake if not worse.
If getting the current selection of a UI control somehow needs to be done asynchronously, then something is seriously wrong.
As a long-time Win32 programmer, the manifestations of these bugs are definitely hard to conceive.
What makes you think this is the case? X11 has an ordered event queue and there is no reason an application can't process the keystrokes in the correct order.
> Another issue is, there's no mapping of pid <-> X11 window. It's simply impossible with the current design of client-server.
What do you need this for? There is _NET_WM_PID [0] which can be set by clients.
[0] https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.h...
> What makes you think this is the case? Many other ways in which async behavior happens on X11, on any machine I've tried, with the mouse cursor lagging to register a click event, for example.
Frankly, it is completely fucking unacceptable for software to miss keystrokes or read them out of order. This is basic programming 101. Any code which exhibits such a problem has a shit design and needs to be rebuilt from scratch.
This sort of thing is exactly what drove me away from the mainstream Linux distros, to create my own from scratch. If and when I ever happen to boot up something like Linux Mint and use it, (shudder,) the sluggishness of gnome3/cinnamon/whatever and all the other bloatware running on the system is readily apparent. My system is always FAST and snappy. Input lag or missed keystrokes? Not on your life.
Reading through the HN comments on articles having to do with speed, snappiness, responsivness of a UI, and excessive bloat of software, it occurred to me one day that these kids (here's the root of the problem) don't actually have a clue that things could be any different than they are. And that's why we're stuck here.
They have literally grown up with slow, bloated shitware for their entire lives, so they actually think all the bloat and slowness is normal and necessary.
Notice how the GP blames X11? They grasp for excuses rather than exercising deep thought, while demonstrating low standards, complacency, and laziness. This is what happens when the common masses take over anything. Shallow thinking and low standards prevail.
These kids have a false conception that doing away with the bloat would mean losing a bunch of features. But in reality we could indeed have fast, responsive, light weight systems, with all of the same features and even more, if only programmers cared enough, or were talented enough to write good software.
Just like how the entire purpose of a certain very Gimped graphics editor was probably to occupy and exploit people who could have worked on some better project. It seems to have worked for a long time; only now after many years do we finally have Krita, but it's KDE only.
It's obvious microcomputer UNIX has been under assault for a long time by those who don't want the dream of a free, open desktop to be realized.
There is a standard window property that anyone can set and that any halfway sane UI framework sets. I ran into maybe one that didn't and even then it was five lines of copy/paste code to add it.
I'm having trouble with the part of the design where we recognize that a file is selected (such that pressing <enter> causes a file to open), see the <enter> keypress, and then fire an event saying "open any file, whichever one you feel like" as opposed to "open this file right here, the one we can see is selected".
If, as you maintain, the keystrokes are processed in order, then at the time <enter> is processed, we specifically take notice of which file is selected. (Because, as I said above, we only know that <enter> should open a file at all because we see that a file is selected.) We fire the file-opening event after that. This isn't a mistake we can make by accident; we'd have to be making it on purpose.
I can see where the assumption that the keystrokes are being reordered comes from; it's much less insane than what you're proposing.
I don't find such a design that surprising. If you like simplicity, you would be tempted to go for it, because it doesn't involve duplicating data (namely, the selected filepath) between the main GUI state and the event handler for opening the selected file. If you're writing in a memory-managing language like C, it's even more tempting - by not copying data, you don't risk forgetting to free it later.
Having said that, I meant it more generally in the sense of their respective architecture design paradigms than details of a particular implementation.
The only potential downside would be if people expected to be able to cancel the <enter> action. But that would be unusual, I think.
In this case, the async logic is not advanced. In fact, I'm willing to bet that this is what happened: at first, the file-opening was synchronous in the GUI. People complained that opening certain files locked up the file picker, so a developer sticks the file-opening code in a background thread. This produces the above bug, without complicating the input design - in fact, preventing the bug requires making additional changes to the code in some way.
It's easy to imagine. Someone kept a variable for the current selection and instead of copying it during the enter event they just read it when the delayed action happens. It often takes time for a second window to open or a page to load. If that new window references the current selection you are going to run into bugs.
It's a design that has caused many video game exploits. You can do impossible things like disassemble a Fat man barrel and put it on a pistol in Fallout. You will get a rocket launcher that has the fire rate of a pistol except it shoots nukes and only uses bullets as ammo.
It's almost a classic TOCTOU issue.
https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use
(Which is also, why applications like Photoshop on Windows weren't a viable option for professional users for some time, until hardware became faster. How do you draw or paint, if the events representing your gestures are not synchronized, as they are subject to system load?)
However the most disturbing thing is that events might get to be processed our of order. Even if you stored current state in a proper Model, there is nothing you can do if your event queue ends up being "<down>, <down>, <enter>".
I guess that's why Qt prefers to do all UI event processing exclusively in a single thread. The event queue will always be serviced in order.
The slowness is only caused by the GIO's G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE and g_file_info_get_content_type. Wherever they are used, there will be a slowdown because the contents of files, that lack extensions, should be read for finding their mimetypes. Almost all the time is taken by that; the other operations are done pretty fast — particularly, the Qt GUI takes no time in comparison.
So maybe I'm not right about GIO as such. But Nautilus is also excruciatingly slow despite being more fully asynchronous.
In fact I have never since directly uploaded anything from my own personal file directories, instead I make a copy of it under /tmp for the upload process.
Not sure if this is the same bug you are talking about
When you're past the stage of first impressions, it's a death by a thousand cuts.
Windows is not better in lots of these details, but at least users already know its tricks due to Microsoft's years of desktop dominance. I'd argue the effort of changing platforms should be about improving the experience, not about swapping a list of UX issues with a set of different ones, otherwise the change isn't really worth it for most users.
EDIT: oops I meant to write this comment as a reply to the sibling that talks about how difficult it is to select a parent directory in the file picker dialog (https://news.ycombinator.com/item?id=25721368)
1. System boots up and starts some apps which are creating windows. This may take some time.
2. While all of that loading, I am seeing some of the apps of no use, I am quickly switching to one, capturing focus, and pressing the quit shortcut.
3. Between my reaction and actual button press, some other app loads, and focus is switched to its window.
4. My keypress goes into another focused window, which gets closed instead of original one. Tada.
Why OS focus has a priority over user focus?
Hit cmd+new window pops up with search highlighted, start typing after a split second the window pops behind the other and all the key presses are then fed into the previous window.
Try to split a window pane on Windows, or right-click and create a file in Mac. In either, try to open an SFTP folder as if it is local, or integrate Git status icons into finder (all easy to do on KDE and Gnome). Good Luck.
The number of copy+paste bugs and QuickLook hanging issues on Mac is not even funny.
Just look at all the enhancers like Norton Commander and Path Finder, and you can see that even calling the OS Windows didn't make MS put too much effort into their windows.
File pickers are one of the things I don't like on GNU/Linux unfortunatelly, saying that as someone who daily uses it as a primary platform.
MacOS and Windows file pickers work better.
On the plus side it should be an easy fix?
Here's a trivial to reproduce and obvious issue that's been there for several years now:
1. Open a directory that loads slowly (e.g. one with thousands of files on a smb3 mount)
2. While the list is loading, select a file (but do not open it)
3. Wait for the whole list to load
Once the list finishes loading, the file on the very top of the list gets automatically selected (discarding your selection).
Thus, if you select a file and click open, in the time between you select and click open, the selection can auto-change and you'll end up opening something else than what you've selected.
It is this bad.