[utborin]

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.

[ivanbakel]

>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.

[userbinator]

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.

[stelonix]

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.

[account42]

> This is an issue with X11

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...

[stelonix]

_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.

[getitstraight]

> '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.

[stelonix]

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.

[josefx]

> there's no mapping of pid <-> X11 window

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.

[thaumasiotes]

> 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.

[ivanbakel]

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.

[polynomial]

This is a great example of where OOP and FP necessarily part ways.

[FridgeSeal]

That’s a cool idea, how so?

[polynomial]

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.

[freeone3000]

Why does the enter keypress save the relative index instead of the actual target of the action? Even Windows gets this one right.

[ballenf]

Why wouldn't the <enter> key interrupt or freeze the keypress queue? I don't think you need some advanced async logic to get this right.

The only potential downside would be if people expected to be able to cancel the <enter> action. But that would be unusual, I think.

[ivanbakel]

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.

[ballenf]

Thanks that makes total sense. And a good rule of thumb for me to remember.

[toast0]

You can't do work on the UI thread, it'll block the UI! With only half a /s

[imtringued]

>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.

[viraptor]

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.

It's almost a classic TOCTOU issue.

[edoceo]

Time of check, Time of Use

https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use

[buckminster]

All old computers get it right. They are not doing UI asynchrony. It's a fairly recent problem.

[danaliv]

My new computers get this right too. This is a design flaw.

[mkl]

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.

[masswerk]

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?)