5 ms·

Classic rant about X's clipboard subsystem, ICCCM: http://www.call-with-current-continuation.org/rants/icccm.txt http://www.call-with-current-continuation.org/

Classic rant about X's clipboard subsystem, ICCCM: http://www.call-with-current-continuation.org/rants/icccm.txt http://www.call-with-current-continuation.org/rants/icccm.tx... (original mailing list hosting is no longer available)

lokedhs 7y ago
Having recently worked on implementing clipboard support in McCLIM, I can completely agree that this document is quite horrible. In fact, it's so bad that basic functionality such as how to choose the correct encoding for text content, is not only underspecificed, but the specification that does exist is worded in such a way that unless you read the entire document, including completely separate sections, you will inevitably use the wrong encoding. Emacs gets this completely wrong, Chrome gets it kinda wrong, and pretty much no one gets it completely right.
DonHopkins 7y ago
https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47#3f73 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... 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 7y ago
  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 7y ago
    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 7y ago
      Ah, I thought the Unix Haters Handbook was a bit earlier than that, so I wondered if it predates i18n

lokedhs 7y ago

Having recently worked on implementing clipboard support in McCLIM, I can completely agree that this document is quite horrible. In fact, it's so bad that basic functionality such as how to choose the correct encoding for text content, is not only underspecificed, but the specification that does exist is worded in such a way that unless you read the entire document, including completely separate sections, you will inevitably use the wrong encoding. Emacs gets this completely wrong, Chrome gets it kinda wrong, and pretty much no one gets it completely right.

DonHopkins 7y ago

https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47#3f73 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... 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 7y ago
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 7y ago
  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 7y ago
    Ah, I thought the Unix Haters Handbook was a bit earlier than that, so I wondered if it predates i18n