[colanderman]

What a load of bollocks. Let's tear this apart:

> Versioning is handled per client, not per bind. So if your app supports one version of a given extension but your toolkit supports another, you can't predict which version of that extension you will get.

Easy solution: open multiple connections. Resources can be shared between connections. (You missed the actual problem with X11 here, which is its current limit of 256 clients. But that's easily fixed with an "X12".)

> III) Many years ago, someone had an idea “Mechanism, not policy.” What did that mean? It means that X has its own X-Specific drawing API,

That's not at all what that means. "Mechanism, not policy" means the X11 core protocol leaves things like window managers and clipboard selection unspecified. (The ICCCM spec takes care of this.) This is sound design.

> it is its own toolkit like GTK+ or Qt.

Wow, not at all. What do toolkits have to do with drawing primitives?

> It defined the low-level things, such as lines, wide-lines, arcs, circles, rudimentary fonts and other 'building block' pieces that are completely useless on their own.

Don't like it? Ignore it and use GLX. X11 is extensible for a reason.

> Media Coherence. Whats Media Coherence? In its simplest terms... Your browser window? That's a window. Your flash player window on youtube? The flash player itself, displaying the video, is a sub-window. What keeps them in sync? Absolutely nothing. The events are handled separately and right now you just pray that they don't get processed too far apart.

WTF? This is exactly what the Sync extension is for.

> “Please generate me a config file........Please actually USE this config file.” Why?? Eventually fixed by making the X-server only use a config file for overrides and making it know and have SANE defaults / auto-detection.

This is an argument against XFree86, not X11. Nothing about X11 dictates XFree86's strange configuration mechanism.

> Who's ever had problems with multiple monitors under Linux? OR ever had to re-setup all of your monitors after a reboot? All X's fault unless you store it in /etc/X11/xorg.conf.d/50-monitors.conf, then it DOES remember it...but you probably had to write that by hand.

Again, WTF does this have to do with X? If your distro is broken and doesn't ship with a decent configuration tool, that will be a problem with Wayland too.

> The window tree is a complete mess. Under X every input and text box was its own window which was parented by the window above it.

Why? Nothing about X11 dictates you must design programs or toolkits like this. Methinks you're confusing "X" with "Athena toolkit".

> Its a nitpick, but its also a valid concern... Under X11, the global pixel counter is 15bits. Which means, between all of your displays you can only have 32,768 pixels.

Shit, no way to fix that without designing a new windowing system from scratch.

> Everything is a window to X, there's no different window types, its just “A window.”

THIS is what "mechanism, not policy" means. X11 doesn't care about window types by design. The ICCCM and EWMH specs are where these things are – by design! – defined! There are different window types, and your window manager is aware of them, without adding needless complexity to the core protocol.

FINALLY: don't get me wrong, there are things wrong with X. However most of the things mentioned in this article are not in that set.

[rg3]

Also, I don't understand the claim "between all of your displays you can only have 32,768 pixels". A 1920x1080 screen has over 2 million pixels (2073600 to be precise). Can anybody explain that part?

[ralph]

Coordinates in the X protocol are signed 16-bit so a screen can run from 0 to 32,767 along an edge. I agree though, the initial complaint is unclear and may be about something else.

[rg3]

Thanks for clarifying. So the following complaint about DPI does not make sense, given that a 50 inches wide screen with a resolution of 600 pixels per inch has 32000 pixels.

[ralph]

OK, I've gone and read the OP's text rather than just the quoted part. It seems he's talking about combining multiple X screens into one logical coordinate space, like I expect one or more of the existing extensions do, e.g. Xinerama.

[iso8859-1]

> use GLX

Actually don't :). Eric Anholt of Intel's Open-Source Technology Center recommends stopping the use of GLX, use EGL instead. Source: http://gstconf.ubicast.tv/videos/opengl-and-mesa-development 18 minutes 50 seconds. Direct link: http://www.youtube.com/watch?v=8lwZdprMC4o#t=18m50s

[Confusion]

I think I'm going to take Daniel Stone's word over yours.

[colanderman]

Or you could, y'know, judge the arguments on their face.

[SimHacker]

"But that's easily fixed with an "X12"." -- Ha ha ha! And I would like a pony with that brilliant original idea. I wonder why nobody ever suggested that before. And if that doesn't gain any traction, then solve it with "Y".

[FooBarWidget]

Y already exists. It was written 10 years ago, but failed to gain traction and stalled.

http://developers.slashdot.org/story/04/02/19/1628204/y-wind...

http://en.wikipedia.org/wiki/Y_Window_System

[SimHacker]

My point exactly. See: http://en.wikipedia.org/wiki/Sarcasm and http://en.wikipedia.org/wiki/Wikipedia:No,_you_can't_have_a_... and http://i-want-a-pony.com

[SimHacker]

""Mechanism, not policy" means the X11 core protocol leaves things like window managers and clipboard selection unspecified. (The ICCCM spec takes care of this.) This is sound design."

XRotateProperties() XCirculateWindow() XRotateBuffers() XStoreBytes() XStoreBuffer() XFetchBytes() XFetchBuffer() and everything to do about window borders, including how they metastasized into the Shapes extension.

http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...

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 ust 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

[colanderman]

Hey, am I actually arguing with the Don Hopkins? Great!

> 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

Beside that this hasn't been true since the mid '90s, I don't buy this argument, especially from you. Uniformity in interface design begets mediocrity, the same way inbreeding begets genetic disorders. I appreciate X's configurability for the same reason I prefer Linux over Windows: I don't like the Windows GUI model. I find it slow and archaic. I don't want to use a Windows GUI clone when I'm trying to code.

The great thing about X's separation of concerns is that I don't have to: I can run a tiling window manager until my friend comes over, at which point I can switch to GNOME or whatever he prefers, and after he's done, I can switch back.

With Wayland, well, either I have to reboot the entire display compositor (does Wayland do this gracefully?) to replace it with a new one, or I better hope I'm running one of the several compositors that have no doubt been developed which allow pluggable window managers, and that my window manager and his both run on it.

[SimHacker]

Well, I wrote that stuff in the early-to-mid 90's, but you're right that I'm actually in the camp that advocates being able to totally reconfigure the user interface. I just think there are better ways of doing that than how X works, and X only lets you change the window manager, but not anything else.

The thing is that X's configurability sucks (.XDefaults files, and the various ad-hoc syntaxes of the various window manager configuration files, which may or may not run m4 over them so you have yet another crazy macro syntax layer).

Since the user interface toolkit and window manager in NeWS was defined as PostScript classes loaded into the window server and shared by all applications, you could subclass or patch or redefine them (usually when NeWS was starting up), and as long as they still supported the same APIs (which is a big limiting factor on what you could do of course -- pie menus emulated the linear menu api, but a linear menu api is not necessarily the best api for pie menus), then ALL applications would pick up the changes.

Of course there were some things you could change on the fly (like the default menu class, except that if apps cached instances of menus instead of recreating them, they would not change), but you could not redefine the window frames on the fly since they already were created, and reparenting the clients into new frames wasn't trivial.

There was a function to change the default menu class used by the window manager, and it knew how to create new menus with the new classes based on the old menus, for the root menu, and also the window frame menus. But any applications that created menus would have to be in on that game. It would certainly be possible to make a MenuClassChanged event to tell them to recreate all their menus, but nobody ever bothered to do that, since it wasn't something that people needed very often, and would require a lot of work for application developers.

You have to weigh how much the flexibility costs in terms of complexity and efficiency against how much people really need the flexibility, and at what time they need it (immediately at any time, app startup time, server startup time).

X pays a very heavy price in terms of complexity to be able to support changing the window manager on the fly (or rather, plugging in different window managers, without providing a turing complete extension language in the server). And it's not because they necessarily badly wanted you to be able to change window managers at any time you felt like it without restarting the server (which was nice, but not something users were clamoring for), but it was because they just didn't want to dictate any "policy" about how window managers should work.

And why just the window manager, and not switch the entire user interface toolkit -- you still want to do that don't you? I'd rather have an architecture where all applications share the same user interface toolkit that runs in one address space local to the server, and have a consistent and customizable user interface, which is how NeWS worked. That's much more important to me than being able to change the user interface on the fly, in my opinion. And it has other nice side-effects like it does not suffer from network race conditions or even context switching overhead, and all the ui code lives in one place and is not duplicated, which mattered a lot in the days before SunOS supported shared libraries -- Sun actually linked all the common SunView apps together into one gigantic monolithic app that would behave like a different app depending on the name it was invoked with on the command line, so the SunView user interface libraries were shared in memory and started up faster, by virtue of the fact that all the standard SunView apps WERE the same app (SunOS did at least support multiple instances of the same app sharing read-only code).

[iso8859-1]

Why paste the link content here? Most people already read it, it's nothing new. I can go find 10 X quotes too, but a link should suffice. Quote pasting is no discussion.

[SimHacker]

I pasted just the part about ICCCM, because it directly addressed the point I was trying to make, and it doesn't have link anchors. I didn't assume everyone would want to wade through the entire document to get to the part about ICCCM. If most people already read all of that Unix-Haters chapter which I wrote in 1993, then that's news to me. Obviously the guy who repeatedly parroted the 20-some-year-old discredited "Mechanism not Policy" line hadn't read my criticism.

But don't lose any sleep over it: computer networks and storage devices are fast and large enough these days that it's not going to cause any meltdowns, so it's more important to save people time, than to conserve the bandwidth and disk space consumed by a few lines of text. Sorry to have wasted YOUR time that it took you to post a complaint.

[iso8859-1]

No need to apologize, I was just genuinely curious. Considering you wrote it yourself, that makes it more of a discussion in my eyes. Bandwidth was never the issue. No hard feelings :)

[moomin]

I loved the Unix Hater's Handbook. Still have the book, still have the barf bag. Still think it's one of the best books on operating systems design ever written.

At least no-one tries to use csh anymore...

[sp332]

Maybe moving away from X is really just a cover for moving away from ICCCM? :)

[colanderman]

You might be right! The core issue of the ICCCM though is not that it's poorly designed in and of itself, but that it is forced to worked around certain specific deficiencies in the X11 protocol (and by "specific" I mean "easily fixed in the next protocol bump", as opposed to "warrant an entire redesign"). The ICCCM authors even suggest improvements to X11 to make for a more coherent system, but sadly it seems most of them have not yet (25 yrs on…) been implemented.

My overall thesis is that the overall design of X (client/server model, mechanism not policy, extensibility) is a sound one, and that the issues cited by Wayland proponents would be better addressed by an evolution of X than a whole-sale replacement.

[SimHacker]

Maybe they should just recognize the fact that the web has won and nobody cares about X any more, and implement a window system that runs in the web browser, and run the web browser in full screen direct access mode as the only top level application. I mean, now that we have HTML and WebGL and Canvas, who needs X11's neanderthal rendering model?

I'm kinda surprised that nobody's written an X server in JavaScript yet (not that it's what I'm proposing above, just that people love to do crazy useless things like that).

[SimHacker]

Jesus christ, I was wrong about that: https://github.com/tnkd/javascript-x-server

Is there a rule 34 about things that shouldn't be written in JavaScript being written in JavaScript?