There's more serious reasons this file picker is broken.
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.
Picking directories has been pretty broken forever as well. Say you start in ~/Downloads/foo and want to store the file in ~/Downloads, then navigating up will have "foo" selected, with usually no blank space to un-select (so you'd need to do ctrl+click or something to that tune); clicking "Save" (or whatever) will then descend into that directory instead of saving, so just using the mouse, or not using any shortcuts, you really can't do this.
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.
Window's UI is not really an upgrade though. All the fake roots (why the heck is the Desktop the root) and the forced broken navigation therein, the removal of up so you have to navigate everything like webpages, treating some folders like databases and others with duplicate names like standard folders, hiding extensions, and the 'My Computer' naming madness.
There's "Up one folder" button and keyboard shortcut in Windows. Button is placed next to weblike Back and Forward buttons. It works according to path displayed next to it and you can even click the elements of the path to go up as many levels up as you want with single click.
That's true but annoylingly it doesn't always take you up one folder. For example If you click it from Desktop, it takes you to the whole PC instead of to your home folder.
Windows (the operating system) does the same thing. If you open your “Documents” folder from your “Quick Links” in the sidebar, going “up” takes you to your Quick Links “folder”.
It’s even worse in MacOS. No matter how much I try to use Mac, I am always so disoriented by the filesystem and the “Finder” (filesystem browsing interface).
Wow I never thought about Ctrl+Click to deselect in that situation. I've probably wasted at least an hour of my life by giving up and re-opening the window in a different way. Thanks!
(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.)
I'm a regular user of the CUA guideline's copy/paste shortcuts. Those shortcuts work in pretty much every MS OS from the early 1990s until recently. Linux has been a mess, but KDE has been pretty decent at enforcing global shortcuts.
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.
Thank you for the accurate description. and it's also broken in xfce. I personally deal with this annoying situation by ascending to the grandparent and then descending to the parent again.
I recall this being a problem, but I just tried it in Gnome+Chrome and it worked correctly and the picker 'looks native' at least. Then I tried it in GIMP (which has a different picker) and it works like you describe.
Some other Gnome apps also work correctly so I think it's fixed in Gnome but not whatever GIMP is using.
Actually, I think the intended usage in this situation is to click on the filename field, then press Save (or Enter/Return). Which is still terrible discoverability, but at least it's theoretically possible?
> Picking directories has been pretty broken forever as well. Say you start in ~/Downloads/foo and want to store the file in ~/Downloads, then navigating up will have "foo" selected, with usually no blank space to un-select (so you'd need to do ctrl+click or something to that tune); clicking "Save" (or whatever) will then descend into that directory instead of saving, so just using the mouse, or not using any shortcuts, you really can't do this.
That's a degradation from 2.10, or 2.16, from time even before the 3.0.
GUIs should effectively be finite state machines and people expect them to operate that way. People understand latency and get used to it; it happened on mainframes and other terminal applications and people memorize the state machine and can tab and type through an interface at high throughput anyway.
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 time (10 years ago?) where you could go to google webpage and start typing your search immediately. Then one day I got my typing deleted once the page finished loading. I thought Google would quickly fix this, but soon realized that this kind of annoying asynchronous behavior was becoming a new normal for a lot of GUIs. I have a rule in my GUIs to only show up something when it’s consistent and usable: the GUI should never lie or mislead.
This has started happening to me constantly in Amazon! I start searching for something, make a typo, go back, then somehow it snaps back to the typo before I hit enter and I get bad results. Super annoying, I don’t remember it being a thing before a year or so ago.
The ebay search button has been like this for ages. To the extent, that sometimes, you correct your search query, hit enter to search and it resets back to the previous search query and re-searches that!
You can thank things like auto-suggest for this as well.
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.
Google search bar also breaks the standard OS behaviour on a Mac, eg. when I am i the search bar and hit <cmd-left> it should jump cursor to the beginning of the line, which it doesn't.
is this possibly a case of "leaky abstraction"? e.g a "data oriented" ui where data flows in 1 direction, so updates to said data blows away any intermediate state?
The reflow issues as incredible in the Twitter mobile web, at least for me on Firefox for Android. When you go back from seeing a tweet's replies to the main timeline, it might take up to 5 seconds (or even more) to load some UI elements and reach a steady state. It even scrolls to a different point than where you were before!
Twitter Mobile is hands down the worst mobile website that I know. I always use nitter.net if I want to view something on mobile. Opening the browser and manually rewriting the link is more handy that clicking on it (e.g. in reddit). That should tell you something.
Yes. Twitter on mobile web seems to have some state of the art ai to reflow the page just when I'm about to press my thumb to read a subthread , like a post or such so I always end up liking the wrong one.
On Twitter for Android, I quite often open the app after a while, and the previous state is shown. Super! I start reading a tweet, and then the popup comes at the top that there are new Tweets; at the same time, that very tweet I was reading disappears from the timeline, whilst the tweets around it remain. Why??
Some folks use this fact to place ads in such way that when you want to click something by the time your finger taps the screen there is an ad underneath. So annoying.
This is the worst, a french website Leboncoin (craigslist basically) does this, makes me want to murder the people behind it
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
I’ve spent more time chasing an iPhone folder with an app I want to put into it than I care to admit.
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.
Even worse is when you know the exact file name that you want to open, and the interface fights against you writing it! For example I want to open /tmp/a.png, but there's thousands of files on /tmp and the cursor disappears while "loading" them, and and some characters of the file name are lost, or typed on different parts of the interface.
Recursive search instead of type-ahead search within one directory in the file picker is criminally terrible. I don't think there is any implementation of a file picker that behaves like this (other than Gtk's).
I use Linux, macOS, and Windows on a regular basis. I use mostly default settings, only a couple changes. Over time my settings move closer and closer to defaults. I tell people to upgrade their OS (with a couple exceptions). I was on-board with GNOME 3 when it came out (I was an Arch user at the time, but I’m in remission now).
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.
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.
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".
Holy crap. It reads like a parody written by someone who read this thread and article. I was thinking it couldn't be as bad as people we're saying, but it's worse!
> Free software development is not a democracy, and does not get driven by polls. Features and bugs are introduced by those who show up, within a community that works towards a shared goal.
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"
Please do not spread these unfounded conspiracy theories. If you are a developer and you don't agree with direction changes, you don't have to work on them, you can work in the direction of your choosing. AFAIK there are numerous forks of GNOME over the years that are still going.
The problem is that GNOME is not just a DE. By virtue of being a project that's used by RedHat and Ubuntu, it's the closest thing to the standard DE that desktop Linux has at the moment.
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.
I'm not sure what you expect can be done about that. Every desktop is going to have its own set of features and APIs that other desktops don't. That's what they mean by "platform." Should e.g. KDE developers spend less time working on their own features and start contributing more to GNOME, to make GNOME apps work better in KDE, and vice versa? Maybe, but they would have to take the initiative to do it.
Having unique features is fine, of course. It's when GNOME goes out of its way to make it impossible for DE-agnostic apps to "do the right thing" for ideological reasons, when every other DE supports some kind of lowest common denominator. Here's one famous historical example:
I don't see how that is an example of ideological reasons, or how that contradicts what I said. It seems like exactly what I was saying -- GNOME, Ubuntu and XFCE all have their own separate APIs for things. I've seen that issue posted here and on reddit so many times and I never understood why anyone considers it any more significant than all the other times a random open source project removed a deprecated API or did an incompatible version bump. Yes, I get it, it's frustrating when upstream is a moving target, but that's exactly what he's saying. You can choose to follow the moving target or you can target a platform that moves slower.
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...
Others strive to have APIs that are either compatible across DEs, or there is a way for a DE-agnostic app to feautre-detect and use it when it's available. GNOME is the only project that simply doesn't care about DE-agnostic apps, and ends up making their life more difficult than anybody else. The app indicator issue is brought up time and again, because the comments on it from the GNOME developers make their attitude crystal clear. That this particular issue has been resolved since then is not important - there have been more since, and there will inevitably be more in the future, since, again - they do not care.
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.
> If you are a developer and you don't agree with direction changes, you don't have to work on them
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.
I would advise holding off judgement on specific individuals unless you have worked with them closely and you have a deep understanding of why certain decisions were made.
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.
> I would advise holding off judgement on specific individuals unless you have worked with them closely and you have a deep understanding of why certain decisions were made.
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.
> 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
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.
What I'm talking about really has nothing to do with power. Maybe the examples I chose suggested that power dynamics are relevant to my point, but I think they aren't, so here is another example without one: Should an architect refrain from judging Frank Lloyd Wright just because they never worked together? I think certainly not. That seems completely backwards to me. Anybody is entitled to have an opinion on Frank Lloyd Wright, another architect particularly so.
Are you talking about judging his contributions and significance to architecture or his worth as a person?
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 am not talking about judging his 'worth as a person'; rather his 'worth as a developer.' Maybe in his private life he's a wonderful person, who knows? Who cares? It is his professional activities that concern people.
You are of course welcome to have an opinion, and to choose whatever product you want based on that opinion. But if the extent of your opinion is "this person is a jerk and their work is terrible and not to my taste" that is unlikely to convince that person to change course, especially if they don't know you and if the decision is already made.
Furthermore, the "this person is a jerk" part is clearly not part of some dispassionate evaluation of his professional accomplishments and is just a verbal attack couched in the language of professional criticism.
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 :)
We've banned this account. Please don't create accounts to break HN's guidelines with, no matter how strongly you feel about something or someone. We're trying for something else here because it's the only way to keep the site interesting.
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:
I just want to say that what you said here and in your other comments in this thread resonated with me in how you approached dissecting issues like ones that have been discussed here. I wish there were more people like you and it's a characteristic I hope I can be more like as well.
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.
I think people believe Linux is community driven project, while in reality it is strongly corporate backed. Just look at kernel contributions [1]. I think same applies to most of the infrastructure, someone works on FreeType, Cairo, Pango, etc.
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.
Sorry if it was not clear, by take it in another direction I generally mean find funding, get hired by someone else to work on it, or start another company to work on it if there is enough of a business opportunity there. It's very hard to make significant changes to a large codebase without a team of people.
This advice definitely applies to open source developers whose work is out completely in the open.
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”.
> if you are a developer and you disagree with someone's choices, you are free to take it in your own direction.
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.
>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.
I personally don't know the full history; you might consider looking for some old blog posts or politely contacting a GNOME developer for an explanation of the history. From what I understand, the run up to mobile was a major source of funding for GNOME 2 from several mobile companies, and that's where all the developers came from, but most of those companies were not able to keep up and failed to iOS/Android. So the funding dried up and Red Hat was one of the few companies that happened to survive because of their other business. That's what I've heard but you should talk to more people who were actually involved in the project back then if you want a more complete answer. (Please assume good faith and don't be hostile, we're all friends here, these are just developers trying to pay the bills like the rest of us)
There was a story recently, On the Graying of Gnome, comment by boudewijnrempt [1]:
> 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.
This sure seems accurate to me, from what I've personally observed, but I don't understand what motive they might have. What's the point of controlling popular software by making everybody hate it?
> What's the point of controlling popular software by making everybody hate it?
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.
Does GNOME really bring in much paid support momey? In the past I have worked at a company that did have RHEL5 workstations with GNOME by default, but everybody I knew treated that as a joke and sshed into the workstations from their (Windows) Thinkpads or Macbooks. The desktop software on those workstations was unwanted and unused.
A lot of people like it. Just because there are old timers that cannot move past gnome 2 it do not mean that Gnome 3 is bad. It faster and more polished that KDE. Workspace management and screen real estate is supierior to anything I used.
I believe the 'graying of GNOME' discussed here a few weeks ago is evidence that fewer and fewer people like GNOME each year. New developers would naturally be drawn from the ranks of enthusiastic users. (Why would a developer volunteer their labor for software they don't use and care about?) The graying of GNOME shows that the pool of enthusiastic users has been shrinking since GNOME 3. That's about when GNOME tipped over the edge and started losing developers faster than it gained new ones. The missing new developers would be new developers, not old timers. If it were only old timers who feel alienated, I wouldn't expect GNOME to have trouble recruiting new developers.
Gnome 3 is default for most popular distros (Ubuntu, Fedora, RHEL, Debian etc) If anything gnome is getting more popular thanks to Ubuntu switching.
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.
Screw Red Hat, the amound of crapware and bad attitudes coming from them is astounding. And of course, since they have big bucks, it gets shoved down everyones' throats.
The lack of typeahead in GtkFileChooser is my biggest annoyance that I've ever come across. Ever since I started using computers nearly 25 years ago I used typeahead to navigate through directories and I can't imagine doing it otherwise. The idea of removing typeahead is anti-human to me, I couldn't adapt even though I really tried to.
Which makes me think the biggest problem with the file selector as described is not that it's flawed, but that it's hard to replace.
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.
I have found a (cumbersome) solution to this using Xfce. Its Thunar file manager does implement type-ahead, so whenever I need to open a file that is saved in some deeply-nested folder, I open Thunar (using a custom shortcut, Ctrl+Alt+E) and quickly navigate to the file using type-ahead and press Ctr+L to copy its full path to the clipboard, then I switch to my app and paste the address.
For complex paths, I found that this is the quickest way to open the file I want.
MATE's based on GTK, so it inherits all the GTK "features", last but not least, the v3 file chooser, which lost along the way the create new folder key binding, and the quick search by prefix (which now has to be inconveniently performed on the address bar).
Additionally, programs may rely on different GTK versions, which also makes things confusing. For example, Visual Studio Code and Firefox use GTK3.
That one really really really pissed me off because it’s a task I expect to do tens of times a day. Also it has some serious focus loss issues in that space where you’ll have to tab or click something again.
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.
And if it goes like it did for me, that smile will turn upside down in a month and you'll format your Linux partition and move to WSL2 on Windows even if you haven't used it in 20 years. That's it, I'm done.
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.
Yeah I've got a hefty PC here too running Windows. WSL2 is wonderful until you get your first Hyper-V bugcheck, filesystem corruption or weird ass network issue to debug. It's really not very good. I used it from day one and WSL1 before that which was even more horrible (NT impedance mismatch was obvious)
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.
Mac is great, I would use it full time if Jobs and Apple hadn't decided gaming is for kids. It's my hobby, especially now that I'm locked home, and being unable to play the latest PC game is an unacceptable compromise for me. No, a console is not what I'm looking for.
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.
If I use KDE I'm still subjected to GTK and Freedesktop for stuff I use which is where all the bugs live. But then I have more inconsistencies between Qt and GTK so in fixing it that way I now have two problems.
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).
Or when you have the full path name already and want to paste it in to GtkFileChooser. It turns out this is possible, but you'd never know it from the UI.
There's been some changes and refinements since Windows 3.1. The current default file chooser dialogue shipped with Windows allows you to put in a full path into both the top file path or in the Filename dialog.
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.
This is why if you're smart, you hide that behind a short timer to pick up the pause. Tuning it just right can be a pain, but hooking natural behavior as an indicator of needing assistance increases the UI bandwidth in terms of signaling. It's the little details.
> 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.
This exact issue is actually what prompted me to switch to Kubuntu/KDE. It's still not perfect out of the box, but it's matched my expectations way better than recent versions of GNOME have.
Let's do another... Open any directory with 3+ items. As first item is highlighted, quickly hit <down arrow>, <enter>, <down arrow>. The 3rd item opens...
There is a lag when hitting <enter> and the last <down arrow> is processed out of order :/
This is bad but it's not unusual. There are similar issues in Firefox and Windows. Nobody gets UI asynchrony right. There are race conditions in everything. It's particularly noticeable with a slow computer.
I promise you people have gotten this right. I have a 198? Mac Plus on my desk that I can boot up and do this on and it will work properly. I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being 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.
>I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being processed out of order.
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.
To sound like Linus Torvalds, "that's braindead stupid!"
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.
This is an issue with X11 which I don't know exactly where it comes from and what causes it. Yes, it has to do with the async nature of it all and I agree it's stupid and it's a miracle the desktop even works. Over time, I've been wondering if Windows dodges this simply by having syscalls that interface with window procedures while Xorg deals horribly with it by being pure userland. Another issue is, there's no mapping of pid <-> X11 window. It's simply impossible with the current design of client-server.
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.
_NET_WM_PID is optional, some clients do not set it and even then afaik the server doesn't do any sanity check and the client can set it to anything, making it inherently insecure. This is not good design.
> 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.
> '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.'
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.
I'm not a Wayland user and do not plan to be. Instead, it is a criticism of the current abandonment of the Xorg project, which I toy with the code from time to time. I also do not use any DE and use X in the leanest way I can, and I still notice such input lag, whether it's playing games or some gui application seeming to register input at a different x,y position than it was clicked. This does not mean I'm a xorg hater, quite the opposite. Studying the codebase, it seems pretty well written and documented and it proved me the "X is unmaintainable" mantra is a lie. I can elaborate more on other issues of the async & client-server nature of X. I'm not spouting nonsense.
I believe the entire point of Wayland was to pull away talent from Xorg development, to keep people in a quagmire for a decade plus working on that junk instead of fixing up Xorg to be what it should be.
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.
I do agree that there's a spread of FUD regarding X11 and its code but I believe we can win this fight if we're interested in fixing X's shortcomings and making the leap to "x12" or whatever you wanna call it. Don't know anyone else who delves into the codebase though.
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.
> Whether or not that's the correct decision, it's not an inconceivable design.
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.
Because the event says "open the currently selected file", not "open this file because it is the selected one". If the event is processed asynchronously w.r.t. other events which can modify the selection, you can get buggy behaviour.
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.
I'm sure there are far more qualified hn users than I to elaborate, but basically you wouldn't have a dependency on an mutable object. Rather, the object would have to be directly passed to a function.
Having said that, I meant it more generally in the sense of their respective architecture design paradigms than details of a particular implementation.
As a rule of thumb: if you ever ask "why not", and the alternative you're proposing is more complicated - that is normally why not. Lots of UI/UX bugs can simply be attributed to the programmer taking the most simple possible design.
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.
>Whether or not that's the correct decision, it's not an inconceivable design.
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.
That Mac cannot multithread the UI interactions. It doesn't have to be a keystroke processing issue. It can be "hey window parent, I've got your result in my properties, pick it up" which doesn't get processed before the next event changes the related property.
Keyboard maybe. That same old Mac probably processes mouse events out of order: when it was being slow you could click on something then move the mouse somewhere else, and it would click the new place instead.
However, the Mac was about the only system getting this right by rigorously prioritizing UI events on the system level.
(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?)
LibreOffice had (has?) a similar strange race condition when typing. When the computer was acting slow and LibreOffice Writer was lagging, the Finnish layout's characters äöå would jump to the front of the typing queue somehow. So if I typed "menkäämme", I might get "äämenkmme" when LibreOffice finally renders the typed text. I don't know if it still occurs but it was really annoying and I always wondered how on earth it could happen.
Only if each key has its own function to process that keystroke, and some keystrokes had to do more processing and thus take more time about it. Selecting an item in a list view is a fast, simple process; what happens after that isn't up to the list view anymore.
Assuming an asynchronous UI programming model, I can only conceive this happening because they skipped having a proper Model and instead the View is accessed directly (in the Mode-View-Controller way of thinking).
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.
That's likely the fault of the GVFS and other virtual-fs-on-top-of-kernel-VFS layers. Gtk seems to be slower than others (such as KIO/KDE), but all of them are pretty slow. E.g. the KDE file picker takes about a second or so to finish listing the contents of my home directory (though it is usable while it is doing so, unlike the Gtk dialog), where the Gtk takes quite a bit longer (perhaps on the order of 3-5 seconds). Meanwhile ls is essentially instant, as you'd expect for just a few thousand files or so.
KIO is pretty fast I think. Dolphin is insanely fast at least - if you list a large directory almost everything that can't be loaded instantly is loaded asynchronously and streamed in to the UI after the UI becomes responsive. I think the KDE file picker is using other code altogether, I'm not sure why it's so much slower. GIO is horribly slow and makes everything that uses it next to useless, eg [1]
Interesting explanation at the end of the bug report:
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.
Yes, actually reading that it makes it sound like the file manager itself is just badly architechted - of course you shouldn't load mimetypes synchronously before listing a folder in the UI, that seems obvious.
So maybe I'm not right about GIO as such. But Nautilus is also excruciatingly slow despite being more fully asynchronous.
Many years ago I was a hit by a bug in the Gnome file chooser (on ubuntu) that selected a random sibling file in the same directory. Caused me to accidentally upload something I definetely didn't want to publish.
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
It's stuff like this that makes so hard to onboard new non-techie users. The proverbial mom or grandma, whose knowledge about the "filesystem" and "directory hierarchies" is already pretty weak, would probably spend 30 minutes or more with this exercise in frustration, before giving up and/or grabbing the phone to ask for help.
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)
I get this all the time with Safari windows on Macs ever since they changed the new tab view when they switched to location naming rather than big cat.
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.
KDE user here, so cannot comment on this case exactly, but in my experience the default "Windows" of Windows and Mac are also terrible.
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.
There are also multiple file pickers (Qt/GTK) and they don't share history or recent file list. Also in GTK picker if I select an existing file on Save by accident, I can't unselect it and I have to write filename again manually myself or close the picker and try again. This is annoying, time-consuming and frustrating.
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.
Given that we've seen multiple examples in both TFA and other comments in the discussion here pointing to simple bugs that have A) been open for 10+ years and/or B) locked and closed as WONTFIX, I don't know if that "plus side" is valid here.
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.