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.
There is a lag when hitting <enter> and the last <down arrow> is processed out of order :/