5 ms·

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

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.

SimHacker 13y ago
"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 13y ago
  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-window-system-project-started http://developers.slashdot.org/story/04/02/19/1628204/y-wind... http://en.wikipedia.org/wiki/Y_Window_System http://en.wikipedia.org/wiki/Y_Window_System
  - SimHacker 13y ago
    My point exactly. See: http://en.wikipedia.org/wiki/Sarcasm http://en.wikipedia.org/wiki/Sarcasm and http://en.wikipedia.org/wiki/Wikipedia:No,_you_can't_have_a_pony http://en.wikipedia.org/wiki/Wikipedia:No,_you_can't_have_a_... and http://i-want-a-pony.com http://i-want-a-pony.com
SimHacker 13y ago
""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/disaster.html 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

SimHacker 13y ago

"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 13y ago
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-window-system-project-started http://developers.slashdot.org/story/04/02/19/1628204/y-wind... http://en.wikipedia.org/wiki/Y_Window_System http://en.wikipedia.org/wiki/Y_Window_System
- SimHacker 13y ago
  My point exactly. See: http://en.wikipedia.org/wiki/Sarcasm http://en.wikipedia.org/wiki/Sarcasm and http://en.wikipedia.org/wiki/Wikipedia:No,_you_can't_have_a_pony http://en.wikipedia.org/wiki/Wikipedia:No,_you_can't_have_a_... and http://i-want-a-pony.com http://i-want-a-pony.com

SimHacker 13y ago

""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/disaster.html 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