Hacker News new | ask | show | jobs
by userbinator 1991 days ago
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.

1 comments

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

_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.
The problem is that neither latency nor async would explain out of order arrival of events. So even now your explanation seems nonsensical.
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'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.