5 ms·

I hate Xlib

58 points by kick 7y ago

DonHopkins 7y ago
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.
cookiecaper 7y ago
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.
- jchw 7y ago
  I’m running Sway WM as my daily driver. Not really perfect but its very good. Very occasional stability issues aside it is far and away my best experience with Wayland. And as a bonus, the code is damn understandable, plain C. I don’t even usually write C and I think it’s nice.
- eXpl0it3r 7y ago
  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 7y ago
    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/9780937175262/ https://www.oreilly.com/library/view/xlib-reference-manual/9...
    - DonHopkins 7y ago
      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.
- Athas 7y ago
  I used Wayland with GNOME on my X250 laptop around 2016-2017. It worked indistinguishably from X11, including automatically connecting to external displays. Now I use Wayland with sway on my home desktop with a 5k display, and it also works fine. The only exception is the odd X11 program that must run through xwayland, where the hiDPI scaling is by interpolation. This is fine for games (Steam runs!), but you wouldn't want to run a very text-heavy application. Fortunately, games are the only non-Wayland programs I run regularly. There are probably things Wayland don't do well - I seem to recall people complain about screen sharing - but for my needs, it Just Works and I never think about it.
- NhanH 7y ago
  Do you remember where I can find the statement of AwesomeWM's maintainer? I used to use it a couple of years ago and it was fairly great back then.
  - cookiecaper 7y ago
    Thank you for sending me on a trip down memory lane. :) Still can't believe that most of this stuff is from +/- 10 years ago. Getting old is weird. Julien Danjou, original awesomewm author, ruminates on the X11 saga and the resistance to XCB in [0], dated 2010-06-01. While that post expresses the bleak outlook for X11 and the Freedesktop project in general, it seems the real clincher about the freeze on awesomewm comes from a LWN article from November 2011 [1], which quotes Julien thus: "The missing parts are advanced stuff like new XInput and multi-touch support, but we were blocked by XCB for those, and users seem to be able to live without them. Now, since everyone seems really happy with the 3.4 branch, I think it's enough that we just keep maintaining it." Taken together, my interpretation at the time -- and I think the general community consensus -- was that the hours and days spent rebuilding cairo to enable the XCB backend and then rebuilding anything that depended on it, which was (is?) basically every substantial Gtk application, were not going to get any easier. Venturing into the comments on that article and seeing the links to issues with users pleading for distro packagers to enable XCB out of the box brings the old days flooding right back. [0] https://julien.danjou.info/thoughts-and-rambling-on-the-x-protocol https://julien.danjou.info/thoughts-and-rambling-on-the-x-pr... [1] https://lwn.net/Articles/467559/ https://lwn.net/Articles/467559/
- alxlaz 7y ago
  The tech behind Wayland is pretty solid and reliable. I've been using it in embedded systems for at least four years now, and I've been somewhat late to the party. Whether it's going to take off on the desktop or not is a completely different matter :-). There's a lot more hardware there, with a lot more different requirements, and there are very few people still working full-time on Linux desktop technology. It doesn't help that the barrier of entry is pretty high. There's no documentation, a lot of the code is a moving target... it's pretty hard to get started with this thing when you're working in your free evenings.
- chousuke 7y ago
  I switched over from awesome to sway just a few days ago. With a bit of scripting and a Python tool that implements the screensaver inhibition dbus protocol, I have awesome-style per-monitor workspaces and swayidle won't kick in to lock my screen while I'm watching videos. I might have to implement it properly in C at some point though. I still prefer how awesome does layouting, but I can get over that. There are still a few rough edges, but if you can handle using a tiling WM, you can handle using sway. I think this time I won't have to go back to X.
sliken 7y ago
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 7y ago
  Any window compositor add UI latency to avoid screen tearing.
  - sliken 7y ago
    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 7y ago
      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-128d398ebd47#9d2d https://medium.com/@donhopkins/the-x-windows-disaster-128d39... 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.
toast0 7y ago
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 7y ago
'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 7y ago
  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 7y ago
    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.
- cjfd 7y ago
  Presumably you will also be okay in a multi-threaded program if only one thread touches Xlib. That would be the sensible way to write a GUI anyway because multi-threading should only be used if it is necessary and not just for the heck of it. If expensive computation is used to calculate the things displayed in the GUI, this should be done by worker threads while the GUI does not need to be multi-threaded. If, on the other hand, one depends on external processes it makes more sense to use a single thread but use it asynchronously. Very few GUI benefit from multi-threading. Note that javascript is also executed single threadedly in browsers.
  - josefx 7y ago
    > Note that javascript is also executed single threadedly in browsers. Currently browsers run multiple processes for their UI and the loaded websites. Back when this wasn't the case it took just a single badly behaving site to hang everything.
self_awareness 7y ago
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
leni536 7y ago
> 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.
comex 7y ago
(2008) or so, given the mention of “7 years” since XCB’s creation in 2001.
matheusmoreira 7y ago
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.
- klodolph 7y ago
  It’s common to use e.g. GLWF or SDL if you want an OpenGL context on Linux. It uses Xlib underneath but you don’t have to touch it yourself.
  - matheusmoreira 7y ago
    But is it possible to render graphics without any libraries whatsoever?
    - therein 7y ago
      You could write to /dev/fb0 and use ioctl's on it to make some adjustments.
    - abainbridge 7y ago
      You could open your own socket to the xclient and speak xprotocol yourself.
    - klodolph 7y ago
      I think if you ask this question you had better be prepared to add some clarifying information here. Are you asking if it is technically possible? Yes, because libraries are just code + data, and you can trivially just duplicate the library functionality in your own library. Are you trying to eliminate library dependencies for some kind of demoscene competition? You could just use the framebuffer. Are you trying to write portable code that doesn’t depend on particular libraries being installed? That’s possible too, in various ways, such as dynamic linking. Are you doing a homework assignment and want to render graphics, but the rules for the homework state “no libraries”? Also possible, but I would recommend talking to the teacher to clarify things. Do you just need to display something simple to the user? You can use ASCII art and set colors by writing ANSI escape sequences, and you can also use emoji. Some people use this to make command-line applications with some simple graphics. Finally, when you say “without any libraries” do you mean to include the standard library, or is that library OK? In general I find the “without using libraries” questions that people ask a bit vague and difficult to answer.

58 points by kick 7y ago

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.

cookiecaper 7y ago

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.

jchw 7y ago
I’m running Sway WM as my daily driver. Not really perfect but its very good. Very occasional stability issues aside it is far and away my best experience with Wayland. And as a bonus, the code is damn understandable, plain C. I don’t even usually write C and I think it’s nice.
eXpl0it3r 7y ago
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 7y ago
  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/9780937175262/ https://www.oreilly.com/library/view/xlib-reference-manual/9...
  - DonHopkins 7y ago
    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.
Athas 7y ago
I used Wayland with GNOME on my X250 laptop around 2016-2017. It worked indistinguishably from X11, including automatically connecting to external displays. Now I use Wayland with sway on my home desktop with a 5k display, and it also works fine. The only exception is the odd X11 program that must run through xwayland, where the hiDPI scaling is by interpolation. This is fine for games (Steam runs!), but you wouldn't want to run a very text-heavy application. Fortunately, games are the only non-Wayland programs I run regularly. There are probably things Wayland don't do well - I seem to recall people complain about screen sharing - but for my needs, it Just Works and I never think about it.
NhanH 7y ago
Do you remember where I can find the statement of AwesomeWM's maintainer? I used to use it a couple of years ago and it was fairly great back then.
- cookiecaper 7y ago
  Thank you for sending me on a trip down memory lane. :) Still can't believe that most of this stuff is from +/- 10 years ago. Getting old is weird. Julien Danjou, original awesomewm author, ruminates on the X11 saga and the resistance to XCB in [0], dated 2010-06-01. While that post expresses the bleak outlook for X11 and the Freedesktop project in general, it seems the real clincher about the freeze on awesomewm comes from a LWN article from November 2011 [1], which quotes Julien thus: "The missing parts are advanced stuff like new XInput and multi-touch support, but we were blocked by XCB for those, and users seem to be able to live without them. Now, since everyone seems really happy with the 3.4 branch, I think it's enough that we just keep maintaining it." Taken together, my interpretation at the time -- and I think the general community consensus -- was that the hours and days spent rebuilding cairo to enable the XCB backend and then rebuilding anything that depended on it, which was (is?) basically every substantial Gtk application, were not going to get any easier. Venturing into the comments on that article and seeing the links to issues with users pleading for distro packagers to enable XCB out of the box brings the old days flooding right back. [0] https://julien.danjou.info/thoughts-and-rambling-on-the-x-protocol https://julien.danjou.info/thoughts-and-rambling-on-the-x-pr... [1] https://lwn.net/Articles/467559/ https://lwn.net/Articles/467559/
alxlaz 7y ago
The tech behind Wayland is pretty solid and reliable. I've been using it in embedded systems for at least four years now, and I've been somewhat late to the party. Whether it's going to take off on the desktop or not is a completely different matter :-). There's a lot more hardware there, with a lot more different requirements, and there are very few people still working full-time on Linux desktop technology. It doesn't help that the barrier of entry is pretty high. There's no documentation, a lot of the code is a moving target... it's pretty hard to get started with this thing when you're working in your free evenings.
chousuke 7y ago
I switched over from awesome to sway just a few days ago. With a bit of scripting and a Python tool that implements the screensaver inhibition dbus protocol, I have awesome-style per-monitor workspaces and swayidle won't kick in to lock my screen while I'm watching videos. I might have to implement it properly in C at some point though. I still prefer how awesome does layouting, but I can get over that. There are still a few rough edges, but if you can handle using a tiling WM, you can handle using sway. I think this time I won't have to go back to X.

sliken 7y ago

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 7y ago
Any window compositor add UI latency to avoid screen tearing.
- sliken 7y ago
  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 7y ago
    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-128d398ebd47#9d2d https://medium.com/@donhopkins/the-x-windows-disaster-128d39... 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.

toast0 7y ago

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 7y ago

'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 7y ago
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 7y ago
  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.
cjfd 7y ago
Presumably you will also be okay in a multi-threaded program if only one thread touches Xlib. That would be the sensible way to write a GUI anyway because multi-threading should only be used if it is necessary and not just for the heck of it. If expensive computation is used to calculate the things displayed in the GUI, this should be done by worker threads while the GUI does not need to be multi-threaded. If, on the other hand, one depends on external processes it makes more sense to use a single thread but use it asynchronously. Very few GUI benefit from multi-threading. Note that javascript is also executed single threadedly in browsers.
- josefx 7y ago
  > Note that javascript is also executed single threadedly in browsers. Currently browsers run multiple processes for their UI and the loaded websites. Back when this wasn't the case it took just a single badly behaving site to hang everything.

self_awareness 7y ago

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

leni536 7y ago

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

comex 7y ago

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

matheusmoreira 7y ago

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.

klodolph 7y ago
It’s common to use e.g. GLWF or SDL if you want an OpenGL context on Linux. It uses Xlib underneath but you don’t have to touch it yourself.
- matheusmoreira 7y ago
  But is it possible to render graphics without any libraries whatsoever?
  - therein 7y ago
    You could write to /dev/fb0 and use ioctl's on it to make some adjustments.
  - abainbridge 7y ago
    You could open your own socket to the xclient and speak xprotocol yourself.
  - klodolph 7y ago
    I think if you ask this question you had better be prepared to add some clarifying information here. Are you asking if it is technically possible? Yes, because libraries are just code + data, and you can trivially just duplicate the library functionality in your own library. Are you trying to eliminate library dependencies for some kind of demoscene competition? You could just use the framebuffer. Are you trying to write portable code that doesn’t depend on particular libraries being installed? That’s possible too, in various ways, such as dynamic linking. Are you doing a homework assignment and want to render graphics, but the rules for the homework state “no libraries”? Also possible, but I would recommend talking to the teacher to clarify things. Do you just need to display something simple to the user? You can use ASCII art and set colors by writing ANSI escape sequences, and you can also use emoji. Some people use this to make command-line applications with some simple graphics. Finally, when you say “without any libraries” do you mean to include the standard library, or is that library OK? In general I find the “without using libraries” questions that people ask a bit vague and difficult to answer.