>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
>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");
root = RootWindow(display, DefaultScreen(display));
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
>(the next client tries to connect to the server)
cmap = DefaultColormap(display, DefaultScreen(display));
favorite_color = 0; /* Black. */
/* Whoops! No, I mean: */
favorite_color = BlackPixel(display, DefaultScreen(display));
/* AAAYYYYEEEEE!! */
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display),
8, PseudoColor, &vinfo) != 0)
visual = vinfo.visual;
/* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */
>(server dumps core & falls into the chasm)
>X-Windows: Even your dog won't like it.
>X-Windows: Complex non-solutions to simple non-problems.
>X-Windows: The First Fully Modular Software Disaster
If not for this glaring design disaster, it would be possible for a program to attempt re-connecting to a new display server after the previous one crashed. No X11 program has ever done this only because Xlib made it impossible.
As a proxy, it could improve error handling across all X applications without any application code changes.
I'm glad I haven't used this site in years and I don't plan to change that today.