[DonHopkins]

Mid 80s hardware, actually.

Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here:

https://blog.dshr.org/2018/05/recreational-bugs.html

>"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

>The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions:

WHAT IS YOUR DISPLAY?

    display = XOpenDisplay("unix:0");

WHAT IS YOUR ROOT?

    root = RootWindow(display, DefaultScreen(display));

AND WHAT IS YOUR WINDOW?

    win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
                              BlackPixel(
                                  display,
                                  DefaultScreen(display)),
                              WhitePixel(
                                  display,
                                  DefaultScreen(display)));

OH ALL RIGHT, YOU CAN GO ON.

(the next client tries to connect to the server)

WHAT IS YOUR DISPLAY?

    display = XOpenDisplay("unix:0");

WHAT IS YOUR COLORMAP?

    cmap = DefaultColormap(display, DefaultScreen(display));

AND WHAT IS YOUR FAVORITE COLOR?

    favorite_color = 0; /* Black. */
    /* Whoops! No, I mean: */
    favorite_color = BlackPixel(display, DefaultScreen(display));
    /* AAAYYYYEEEEE!! */

(client dumps core & falls into the chasm)

WHAT IS YOUR DISPLAY?

    display = XOpenDisplay("unix:0");

WHAT IS YOUR VISUAL?

    struct XVisualInfo vinfo;
    if (XMatchVisualInfo(display, DefaultScreen(display),
                         8, PseudoColor, &vinfo) != 0)
        visual = vinfo.visual;

AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?

    /* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */

WHAT??! HOW AM I SUPPOSED TO KNOW THAT? AAAAUUUGGGHHH!!!!

(server dumps core & falls into the chasm)

[vidarh]

> Mid 80s hardware, actually.

I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :)

> WHAT IS YOUR ROOT?

A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though.

The X protocol is messy in places, but Xlib is far worse than necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value.

So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better.

There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach.

In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients.

EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.

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

[sprash]

You think this is bad? Just look at a native Wayland "Hello World" client [1]. This doesn't even print hello world. You have to do the text rendering yourself. And you need at least 500 more lines to implement the equivalent to a simple XGetImage() call.

1.: https://github.com/emersion/hello-wayland/blob/master/main.c

[bitwize]

Your toolkit should abstract all that away. We have these wonderful things called dynamic libraries, that X was designed for a world without because they didn't exist under Unix yet.

[sprash]

If toolkits can "abstract that away" they can do the same on X11 and there is even less reason for Wayland to exist. There is no reason for you to even care about X11/Wayland if you only work with toolkits. So stop participating in a discussion that doesn't concern you.

[md8z]

"they can do the same on X11 and there is even less reason for Wayland to exist."

Well actually it's the reverse: the more abstractions were put into toolkits, the more it became obvious that there was little reason to use everything in X11.