
I hate Xlib - kick
https://www.remlab.net/op/xlib.shtml
======
cookiecaper
XCB was great for a while, but like so much else in the open-source ecosystem,
people knocked it down and dragged it to the "good ^w acceptable ^w tolerable
is the enemy of perfect" camp, while political operatives gobbled up another
decade in the interest of securing their employers' control over the platform.

AwesomeWM started as a tiling WM built for the new frontier, before xcb
crumbled around it. After about four years with scant updates, the
maintainer's statement that he didn't see a future for it with the community
abandoning its central technology, and a precipitous increase in "I just want
this dumb thing to build so I can use my computer" keyboard-smashing sessions,
I switched back to KDE. These days, a Windows 10 VM with passthru'd sound,
USB, and GPU is my primary workstation environment.

I hear Wayland will be ready for the big time any day now. Been hearing that
for the last three years or so. Maybe we can have a Year of the Wayland
Desktop before a Year of the Linux Desktop.

~~~
eXpl0it3r
We tried to use XCB with a cross-platform windowing/input library, but very
quickly we ran into a lot of small issues, where XCB was even less documented
than Xlib, so you had to resort to reading the source code, or where
functionality was just missing, so we had to fallback to Xlib. In the end we
reverted the XCB changes and just went with Xlib again. It's a pain, but at
least you can make it do anything you need to and it's somewhat documented or
enough knowledge aggregated over time.

~~~
newnewpdro
Xlib isn't just somewhat documented, it's exceptionally well documented.

I'm no fan of X, but the books documenting it were from an era when the UNIX
industry was flush with cash and printed technical writing was at its peak.

It pains me to flip through my volumes of printed O'Reilly X books, knowing
how much time and care was put into documentation for such a technical
abomination.

[https://www.oreilly.com/library/view/xlib-reference-
manual/9...](https://www.oreilly.com/library/view/xlib-reference-
manual/9780937175262/)

~~~
DonHopkins
Sun's OpenWindows documentation had a man page for every OPEN LOOK cursor! How
you'd figure out the name of the cursor you see on the screen to look it up in
the manual, I have no idea.

------
DonHopkins
X extensions come with their own libraries, and those libraries always use and
depend on Xlib, so you're stuck with Xlib if you want to use any non-trivial X
extensions.

XCB wasn't the first non-Xlib way to talking to an X11 server that had this
problem. We had the same problem in the 90's when we wanted to use Display
PostScript with Common Lisp which was talking to X with CLX, an alternative to
Xlib written in Lisp.

------
toast0
I did a smidge of work with X11 and it was amazing how far from the underlying
network protocol Xlib feels, and not in a way that seems helpful.

------
jonny383
'If XInitThreads() is not called anywhere in a multi-tasked program, the
program will usually work. But weird crashes and other race conditions are
bound to happen over time, as Xlib maintains some global data that is shared
across all threads and all "displays".'

Is there a reason you can't catch this with static analysis tests? Also, I
don't really see this as an issue with xlib any more than I see it as an issue
with a careless developer who didn't read documentation or check or examples.

~~~
bluecmd
Hostile APIs are a problem. If you require a dance for the correct outcome,
people will fail. Make it easy to do the right thing.

~~~
josefx
Multi threading usually involves a dance to get the correct outcome. Xlib does
that for you with a single call at the start of the program or you can do it
yourself with every function call you want to make.

------
self_awareness
Classic rant about X's clipboard subsystem, ICCCM:

[http://www.call-with-current-
continuation.org/rants/icccm.tx...](http://www.call-with-current-
continuation.org/rants/icccm.txt)

(original mailing list hosting is no longer available)

~~~
DonHopkins
[https://medium.com/@donhopkins/the-x-windows-
disaster-128d39...](https://medium.com/@donhopkins/the-x-windows-
disaster-128d398ebd47#3f73)

Ice Cube: The Lethal Weapon

One of the fundamental design goals of X was to separate the window manager
from the window server. “Mechanism, not policy” was the mantra. That is, the X
server provided a mechanism for drawing on the screen and managing windows,
but did not implement a particular policy for human-computer interaction.
While this might have seemed like a good idea at the time (especially if you
are in a research community, experimenting with different approaches for
solving the human-computer interaction problem), it can create a veritable
user interface Tower of Babel.

If you sit down at a friend’s Macintosh, with its single mouse button, you can
use it with no problems. If you sit down at a friend’s Windows box, with two
buttons, you can use it, again with no problems. But just try making sense of
a friend’s X terminal: three buttons, each one programmed a different way to
perform a different function on each different day of the week — and that’s
before you consider combinations like control-left-button, shift-right-button,
control-shift-meta-middle-button, and so on. Things are not much better from
the programmer’s point of view.

As a result, one of the most amazing pieces of literature to come out of the X
Consortium is the “Inter Client Communication Conventions Manual,” more fondly
known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”).
It describes protocols that X clients must use to communicate with each other
via the X server, including diverse topics like window management, selections,
keyboard and colormap focus, and session management. In short, it tries to
cover everything the X designers forgot and tries to fix everything they got
wrong. But it was too late — by the time ICCCM was published, people were
already writing window managers and toolkits, so each new version of the ICCCM
was forced to bend over backwards to be backward compatible with the mistakes
of the past.

The ICCCM is unbelievably dense, it must be followed to the last letter, and
it still doesn’t work. ICCCM compliance is one of the most complex ordeals of
implementing X toolkits, window managers, and even simple applications. It’s
so difficult, that many of the benefits just aren’t worth the hassle of
compliance. And when one program doesn’t comply, it screws up other programs.
This is the reason cut-and-paste never works properly with X (unless you are
cutting and pasting straight ASCII text), drag-and-drop locks up the system,
colormaps flash wildly and are never installed at the right time, keyboard
focus lags behind the cursor, keys go to the wrong window, and deleting a
popup window can quit the whole application. If you want to write an
interoperable ICCCM compliant application, you have to crossbar test it with
every other application, and with all possible window managers, and then plead
with the vendors to fix their problems in the next release.

In summary, ICCCM is a technological disaster: a toxic waste dump of broken
protocols, backward compatibility nightmares, complex nonsolutions to obsolete
nonproblems, a twisted mass of scabs and scar tissue intended to cover up the
moral and intellectual depravity of the industry’s standard naked emperor.

Using these toolkits is like trying to make a bookshelf out of mashed
potatoes. \- Jamie Zawinski

~~~
fanf2
I am laughing at all the horribleness here :-)

I39L caught my eye, I think it’s one of the earliest abbreviations of that
form that I have seen. Do you know where it came from?

~~~
DonHopkins
Thanks! ("X11: It gets worse.") I just made it up (around 1992), based in I18N
(which was in use at the time, but not as widely known as today), to make fun
of how long the full title of the ICCCM was. It's also a nice way to censor
short naughty words like "F2K Y1U"!

~~~
fanf2
Ah, I thought the Unix Haters Handbook was a bit earlier than that, so I
wondered if it predates i18n

------
comex
(2008) or so, given the mention of “7 years” since XCB’s creation in 2001.

------
matheusmoreira
I wish there was an easier way to do graphics on Linux. Xlib is really hard to
use and OpenGL depends on the Xlib extension GLX. I've read that Wayland
creates OpenGL ES contexts using nothing but the kernel's generic buffer
management and direct rendering manager. Not sure how that works. Not sure if
Vulcan is usable without dependencies either.

~~~
vetinari
Wayland _compositors_ have to use lower-level APIs like libdrm, in order to be
handle clients using OpenGL, OpenGL ES, Vulkan, libva and other hw-related
APIs, all at once.

Wayland _clients_ don't have to. For OpenGL, OpenGL ES there's EGL, for
Vulkan, it's the other way and Vulkan provides extensions for WSI (window
system integration).

~~~
matheusmoreira
Thanks for clarifying this for me. I didn't know about libdrm. I'm going to
read the source code now to learn more.

------
leni536
> _However, most real-life programs access Xlib through higher-level
> libraries, and the libraries do not initialize Xlib threading on their
> behalf._

Do these libraries assume that XInitThreads() was called? If they do they
could all link against an "libxinitthreads" library where XInitThreads() is
called in a constructor function.

------
sliken
I do wonder how much of Chrome OS (which uses the linux kernel) owes it's
performance, low latency UI, and memory efficiency to ditching X11.

~~~
pmarin
Any window compositor add UI latency to avoid screen tearing.

~~~
sliken
Sure, but things have progressed quite a bit since XLIB. After all it's
designed for high latency/low bandwidth network connections using an ancient
protocol with all kinds of caching, complexity, and vector oriented UIs out of
tech with today's mostly bitmapped UIs.

There's something crazy like 64 ways to join to vectors. 100s of dot/dash
combinations for drawing a line, caching of color maps, etc. etc. etc.

~~~
DonHopkins
X11 is hardly vector oriented. You can draw lines and ovals, but the graphics
model itself is totally pixel oriented.

See the 'X-Windows Disaster' section 'Myth: X is "Device Independent"':

[https://medium.com/@donhopkins/the-x-windows-
disaster-128d39...](https://medium.com/@donhopkins/the-x-windows-
disaster-128d398ebd47#9d2d)

Myth: X is “Device Independent”

X is extremely device dependent because all X graphics are specified in pixel
coordinates. Graphics drawn on different resolution screens come out at
different sizes, so you have to scale all the coordinates yourself if you want
to draw at a certain size. Not all screens even have square pixels: unless you
don’t mind rectangular squares and oval circles, you also have to adjust all
coordinates according to the pixel aspect ratio.

A task as simple as filing and stroking shapes is quite complicated because of
X’s bizarre pixel-oriented imaging rules. When you fill a 10x10 square with
XFillRectangle, it fills the 100 pixels you expect. But you get extra “bonus
pixels” when you pass the same arguments to XDrawRectangle, because it
actually draws an 11x11 square, hanging out one pixel below and to the
right!!! If you find this hard to believe, look it up in the X manual
yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy
it is to add 1 to the x and y position of the filled rectangle, while
subtracting 1 from the width and height to compensate, so it fits neatly
inside the outline. Then it points out that “in the case of arcs, however,
this is a much more difficult proposition (probably impossible in a portable
fashion).” This means that portably filling and stroking an arbitrarily scaled
arc without overlapping or leaving gaps is an intractable problem when using
the X Window System. Think about that. You can’t even draw a proper rectangle
with a thick outline, since the line width is specified in unscaled pixel
units, so if your display has rectangular pixels, the vertical and horizontal
lines will have different thicknesses even though you scaled the rectangle
corner coordinates to compensate for the aspect ratio.

