It was/is mostly the same practice except for the cases where it really counts. Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly. And there the possibilities are almost limitless. And thanks to the xcb library it's actually somewhat convenient to use.
Also certain types of power tools for mac probably need use Quartz directly as well.
> Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly.
Honestly I think this is a pretty fair approximation of "no one". How many people are writing tools like this vs. the number of people writing regular applications? A very small number, I'd say.
And after working extensively with both libX11/libxcb and libwayland-client directly, I can say that none of them are particularly pleasant to work with. Actually, no, that's not true: libwayland-client wins, easily. Every single Wayland protocol has code generated for it that works exactly the same way. I suppose the same is (more or less) true of libxcb, but libX11 (and all the other libraries you might have to use, like libXrender, libXrandr, libXext...) are a complete mess.
And even then, libwayland-client has a much lower number of concepts you have to understand than libxcb does, simply because the Wayland protocol has a small number of concepts you need to understand. libxcb is definitely an improvement over libX11, but it can't magically make all the underlying X11 protocol concepts become unified.
Having written a new gtk program recently I had to implement Wayland and X -isms in the code. Off the top of my head X prefers using W_Class and Wayland prefers app-id with each window having a role set. Both are fine. I honestly think Wayland is nicer but realistically you code for both. To get a global hot key you register it with the compositor and it works. But you can run a background daemon to catch all keys if you really want.
And why should we optimize for "how many locs can I write a screenshot tool in"? I would prefer to having 1-2 decent ones that have all the necessary features and call it a day. They can then have a simple API so you can script whatever you want.
Why would I want to add more complexity to a display server?
It means that Wayland is the worst and most idiotic graphics API ever conceived. Talking to Wayland's "asynchronous object oriented protocol" directly is a fucking disaster [1]. Secondary and partly duplicated infrastructure in form of a dbus infested maze of "Desktop-Portals" is necessary to do things as simple as taking screenshots.
As such it essentially cements the GTK/Qt duopoly. Both are extremely subpar low-quality bloated toolkits that are also responsible for the fact that the Linux desktop is still not a thing in 2026.
Wayland isn't really a graphics API, it's just a protocol for clients to communicate with the compositor. Sure, there's a lot of boilerplate to get a window on the screen, but you also aren't supposed to use it directly if you want something super simple. It's really meant to be a low level interface for toolkits to be built on top of. Here are two disagreements I have with the linked article:
1. Comparison with raylib
This is imo comparing apples with oranges. Raylib sits at a much higher level than wayland, and it in fact supports using wayland as a backend.
2. Wayland is littered with callbacks because it's an object oriented protocol
It's more due to wayland being an asynchronous protocol. When you send a request to the compositor, chances are that you wont hear back from it immediately. But it's also likely that the app can do other things while waiting for the response. X11 is also in fact an asynchronous protocol, it's just that XLib creates a synchronous API on top of it (and as a result suffers from unnecessary roundtrip delays). In comparison, the newer XCB library is a lot more faithful in terms of preserving the asynchronous nature of the protocol and is used by, for example, Qt's X11 backend and even XLib itself. Of course that also makes it more difficult to use, not unlike libwayland, but the main takeaway here is that you can build a sync API on top of an async one if you wish and not vice versa.
I think some parts of the author's frustration is misplaced because they see libwayland as a toolkit, and in that case yeah it's pretty painful. But I really don't agree with the conclusion that this somehow makes it a bad foundation to build upon. As an analogy, making raw syscalls to the kernel is also painful, but that's why libraries exist.
I agree the portals thing is a horrid mess, but you don't need them to take a screenshot unless you're a sandboxed application. Which is probably a good thing.
You can write a simple Wayland screenshot app with a few hundred lines of code[0], and a compositor that supports the ext-image-capture source and ext-image-copy-capture extensions implemented. (Or the older wlr-screencopy.)
I have plenty of criticism for Wayland and its ecosystem, but if you're going to criticize, don't spread FUD.
(I don't like being the guy who has to assert his credentials, but: I've implemented all three of those screenshot/screencast protocols in a Wayland compositor, just a month or so ago, and know how they work, and what it takes to talk to them from a client.)
Also I read through the link you posted. There's a lot of truth to many of those frustrations, but a lot of it is based on misunderstandings of what Wayland actually is. Yes, most people should be using a toolkit. No, it's not great that the main choices are GTK and Qt. I think there's absolutely room for a mid-level toolkit that lets you do the basics without requiring all the Wayland boilerplate. smithay-client-toolkit is one such effort, and I think it's a good start, though something even higher-level on top of it would be nice.
I also don't get the callback hate. I much prefer registering callbacks over a ginormous switch statement that has to dispatch every event under the sun. Toolkits use callbacks too; does the author hate all toolkits as well? You actually could talk to a Wayland compositor with a big switch statement if you wanted, though you'd need to modify libwayland-client to return events as you iterate its event queue rather than dispatch things to callbacks. That could be a fun project for someone who wanted to make Wayland event handling just like libX11 event handling. (See: just a fundamental misunderstanding of what Wayland is.)
And comparing raylib to libwayland-client is silly; they're fundamentally different things. And you can use raylib to talk to a Wayland compositor. It's just a bad-faith argument.
If you want to compare libwayland-client to something, you have to compare it to libX11 or libxcb. And while yes, getting a simple window on-screen is indeed simpler with libX11/libxcb, doing anything more complicated than that is on par with what you'd end up doing with libwayland-client.
[0] Not counting the protocol code that wayland-scanner will generate for you, because that's like saying you have to count the lines of code in libX11 to write an X11 screenshot app.
Yes but the Nvidia NV-1 preceding the Vooodoo was much more impressive. Using NURBS you could display perfectly round objects. Also it had forward texture mapping which significantly improves cache utilization and would be beneficial even today.
It was just way harder to program for. Triangles are much simpler to understand than bezier curves after all. And after Microsoft declared that DirectX only supports triangles the NV-1 was immediately dead.
> Also it had forward texture mapping which significantly improves cache utilization and would be beneficial even today.
Not really. Forward texture mapping simplifies texture access by making framebuffer access non-linear, reverse texture mapping has the opposite tradeoff. But that is assuming rectangular textures without UV mapping, like the Sega Saturn did; the moment you use UV mapping texture access will be non-linear no matter what. Besides that, forward texture mapping has serious difficulties the moment texture and screen sampling ratios don't match, which is pretty much always.
There is a reason why only the Saturn and the NV-1 used forward texture mapping, and the technology was abandoned afterwards.
The original rc-style sysvinit scripts of arch were neither brittle nor buggy. Everything could be configured with "rc.conf" and writing own services was dead simple. All of this was possible with many orders of magnitudes of less complexity.
This also means low-performing clients can make the whole Desktop stutter/freeze and it is one of the many reasons the Wayland architecture is beyond idiotic. High responsiveness is obviously far more important than avoiding the occasional artifact.
Clients (apps) should still be async in Wayland; it's just the window manager that's tightly integrated. Wayland compositors should probably use some kind of fair queuing to prevent misbehaving apps from spamming the event loop but they probably don't.
Example: Windows can only be resized when the client finished drawing the new resized window. Otherwise you would get "visual artifacts". So typical operations dealing with window management can not be async when the insistence on the nonsensical "every frame is perfect" mantra is upheld.
Graceful degradation is a thing. If you don't get a response from a client that you are redrawing, you may just put a translucent shader on the window, show the user the changing borders immediately, and then resume whenever it's ready.
Tcl/Tk to this day is the best tool to make GUI frontends for CLI applications. Besides that, in the past I used it in production for intranet database entry applications. It has since been replaced by Flask. In my opinion the higher complexity of the Flask version is no way justified and we should have kept the much simpler ~2k LOC Tcl/Tk solution.
CLI applications typically read text from stdin and write text to stdout. The tcl model of "everything is a string" makes exactly the right abstraction to create GUI frontends for CLI applications rapidly and keep them simple at the same time.
Tk's GUI object model is sitting at a reasonable maxima between trivial to make use of vs. triggering the events necessary to make the GUI active.
Small example. You want a button on your GUI that triggers a procedure called "process" when it is clicked, this is the code you need (if you are fine with the remaining defaults) (and assuming you used 'pack' as the geometry manager):
button .process -text "Process Entries" -command process
pack .process -side top
And a fully active GUI button will now appear at the bottom of your Tk window, with a label of "Process Entries" and when you click it, a Tcl procedure named "process" will be executed.
For jimtcl (the production-ready minimalistic tcl implementation which antires started (with full closures & gc'able lambdas) - probably an outgrowth of picol), you can get static "(some) batteries included" binaries at:
It is obviously not dead but it should be dead: Almost all of the technical and economic progress made in the last century was achieved with macroscopic quantum effects. Particle physics spends a lot of energy and material resources to measure microscopic effects. The priorities are esentially inverted. At this point it is not even about discovery. Experiments are relegated to precision measurements. What practical use will it be if we know the mass/charge distribution/polarizability of some particles more precicely by a few percent? About nothing.
Playing around with 68k assembly is actually much more fun. These days all the logic is absolutely dwarfed by caches in terms of chip area. This means using RISC does not really make as much sense today as it did in the 80s. That's why the most popular architectures are still CISC (assuming ARM64 can not really be called RISC).
Personally I would be more interested in a fully orthogonal instruction set like 68k but without the insane addressing modes and a better binary format.
It is already possible today. There are access control hooks provided via XACE. Nobody uses them because the attack scenario is basically non-existent. If you run untrusted malicious apps having full access to your home directory you have big problems anyways. Not giving them access to e.g. the screen coordinates of their windows won't help you much then.
Also certain types of power tools for mac probably need use Quartz directly as well.