[DonHopkins]

The problem with pure reimplementations of XLib in other languages is that there's no way they can use the client side X extension libraries that are based on XLib.

I learned that the hard way when trying to figure out how to use Display PostScript with CLX in 1992, which is an X client library written in Common Lisp.

https://www.cliki.net/clx

Few people still write applications directly to XLib, but many do write applications directly to toolkits and libraries that DO depend on XLib.

So we're all stuck with XLib from now until eternity. If you replace it, you lose the entire ecosystem of client side extension libraries, so you have to reimplement them all from scratch.

At the time, that was a no-go if you wanted to use Adobe's proprietary Display PostScript extension, which was quite popular and included with most commercial X11 servers of the era. Even if most important X extensions are open source, how about about them NVIDIA drivers?

Display PostScript is simply an old example from 1992 of what I mean, that I wanted to use from Common Lisp via CLX, but couldn't. But it shows how this problem has been around for a long time, and is never going away. The only viable solution was to dump CLX and call XLib and the Display PostScript extension libraries directly from Lisp through a wrapper layer.

But now the problem with clients and toolkits depending on X11 extensions is much more entrenched, not just limited to high-end exotic graphics-rich apps that want to use Display PostScript to draw a nice pie chart.

That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries -- just to measure the display, shape windows, listen for input, memory map pixmaps, and composite the first pixel on the screen -- because they've long since abandoned X11's horrible old built-in pixel-based rendering API, broken font model, leaky input system, etc, and switched to using full stacks of X11 extensions (via their XLib based libraries) instead.

[yjftsjthsd-h]

> That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries

Then Wayland will be more a nightmare still, since they moved everything but core rendering into extensions and say "just use wlroots" to deal with it.

[md8z]

No, you have it mixed up. Wlroots is on the server, the Xlib problem is explicitly with client libraries.

[vidarh]

Absolutely agree that a general purpose replacement for Xlib would be a massive pain, but providing sufficient support for the core protocol to let you add whichever request types you need is quite simple (and I lifted that from a decade old starting point and made it work).

And for my use I only need to support about a dozen requests types, and no third party libs, so it's not that bad. My starting point only linked with Xlib anyway, nothing else, and I verified which requests Xlib actually sent via xtruss before I started.

But of course, that's because I only want to actually use it for something very simple. If I wanted to do something more complex I'd wrap a higher level library instead.