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