24 ms·

How X Window Managers Work, and How to Write One (2014)

276 points by firefly284 5y ago

fyrn- 5y ago
Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though
- zephyr9 5y ago
  Does upstream Wayland work on any platform except for Linux? Does this display server have any form of colour management for, you know, the stuff it's displaying? Wayland is taking off like the Spruce Moose...
  - emersion 5y ago
    Feel free to continue using X11 of course, no one's forcing anybody to switch. That said: > Does upstream Wayland work on any platform except for Linux? Yes, FreeBSD. Patches welcome to make it work on other BSDs. > Does this display server have any form of colour management for, you know, the stuff it's displaying? No more than X11 right now, ie. none. But it's in the works.
    - zephyr9 5y ago
      I was under the impression Wayland on FreeBSD required a lot of patching on their end, but this has been merged upstream? If so that's pretty good news. Also good news re colour management. The last I heard about this was Drew DeVault (and I'm paraphrasing) calling it "precious horseshit". [0] https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.html https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.ht...
      - kaba0 5y ago
        There is work on HDR colors, but I haven’t followed up on it.
- linguae 5y ago
  1. The article was written in 2014. 2. While it appears that Wayland is poised to replace X11 on Linux desktops given the amount of backing Wayland has compared to X11, it is not clear whether Wayland will replace X11 in the BSD ecosystem. According to the FreeBSD Wiki, Wayland is not ready to be a daily driver (https://wiki.freebsd.org/Graphics/Wayland https://wiki.freebsd.org/Graphics/Wayland), though work has been done getting Wayland compositors and other software to work on FreeBSD. I use X11 on my FreeBSD desktop. I'm unfamiliar with the current status of Wayland on NetBSD and OpenBSD. I expect X11 to live on for quite some time in the BSD world and among more conservative Linux users, similar to the situation regarding systemd in the Linux community, which was adopted by mainstream distributions and users but faced (and still faces) opposition from some users.
  - mrweasel 5y ago
    Someone has started work on OpenBSD Wayland: https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-report/ https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-... I doubt it's something that will be ready for 7.1 next spring, but it's nice to see that it's actually working.
  - pimeys 5y ago
    I've been using Wayland and Sway with FreeBSD 13 quite successfully. Everything worked quite well, except some indicators in Waybar that were using some Linux specific things to get values for memory usage etc...
  - mcguire 5y ago
    3. Wayland has been "starting to take off" for longer than many of the readers here have been alive.
- josefx 5y ago
  That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.
  - 5e92cb50239222b 5y ago
    What "Wayland people"? You probably mean the former Xorg developers who shifted to full time Wayland development long ago. Xorg is on life support, it has been getting bug fixes and nothing else for the past several years. From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.
    - josefx 5y ago
      > Xorg is on life support, it has been getting bug fixes and nothing else for the past several years. Imagine two cars: X11 its an old one, it doesn't quite start right, the windows are chipped, the paint is peeling of and no one really wants to invest money into maintaining it, it defaults to brakes and a steering wheel from 1980 but has seen continous upgrades over time and you can generally swap in a steering wheel from 2010 with minor problems. Now imagine wayland, a brand new tesla, it doesn't have brakes or a steering wheel because history has shown that these concepts evolve and if anything it should be a third party provider that creates them. Who cares that it took ten years between the release of the car as ready for use and the first compatible steering wheel implementation? Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction. > From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves. As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs). Of course the people who wrote wayland also wrote X11 so removing themselves from the equation might have been the nicest thing they ever did, given their own opinion of their past work on X11.
      - Arnavion 5y ago
- qwerty456127 5y ago
  This is exactly why I would rather do. I see absolutely no reason to abandon X and want to learn its internals to be able to maintain it myself. To me X seems a perfect piece of software which just works and does its job flawlessly, while having all the features I ever needed (including remote execution - I used Windows apps running on a remote Linux machine with Wine over SSH over OpenVPN on a local Windows machine and that was very easy).
  - Seirdy 5y ago
    1. Wayland does support remote execution; see waypipe for an example. 2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).
    - vidarh 5y ago
      X worked just fine on early 90s hardware. Performance today is about implementation, nothing inherent about X.
      - Seirdy 5y ago
        ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.
        qwerty456127 5y ago
        What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO. I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.
- loxias 5y ago
  > replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.
  - perth 5y ago
    Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland. Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work Some relevant links for those curious about other people hitting into this: https://www.foell.org/justin/simple-hidpi-monitor-scaling-with-wayland-in-ubuntu-18-04/ https://www.foell.org/justin/simple-hidpi-monitor-scaling-wi... Gnome team: https://wiki.gnome.org/Initiatives/Wayland/XWayland https://wiki.gnome.org/Initiatives/Wayland/XWayland
    - jcelerier 5y ago
      Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt
      - perth 5y ago
        Try to set two different DPIs in that.
        AshamedCaptain 5y ago
        You certainly can, but the problem is that there is no agreed standard from the toolkits to do it. E.g. Qt has its own way.
- sprash 5y ago
  > right as the replacemeant for Xorg starts to take off though It has been "taking off" for 13 years at this point. It seems like it doesn't have much thrust behind it.
  - Seirdy 5y ago
    Fedora, Ubuntu, OpenSUSE, RHEL/Rocky, and Debian all have their default desktops on Wayland. Both GNOME and KDE have already switched and will keep legacy X around for compatibility purposes for another few years. On the more minimal side to compete with X-based window managers: Sway is very mature and River is turning out nicely. All that's left is an Openbox alternative. I believe there are a few, but I'm not familiar. Wayland has already taken off; once we get XFCE to switch we should be able to move on.
    - deleted 5y ago
      [deleted]
    - sprash 5y ago
      This is not an organic transition. Major organizations seems to "push" it but there is not much "pull". Compare this to the "transition" from CVS/SVN to git. There was no need to even advertise git. People saw it and wanted it. The X11 ecosystem is more than just GNOME, KDE and i3 and porting XFCE will not be enough to "move on" (For me it is the small things like Xdotool, Xsel, Xcalib, etc. that are holding me back). Maybe X11 needs to be replaced but Wayland is not the answer. It's just not good enough and because of fundamental flaws of its philosophical concepts it will never be.
      - Seirdy 5y ago
        Xdotool and xsel have had Wayland equivalents for years: see ydotool/wtype and wl-clipboard. The reason why major orgs have had to push for Wayland is the same as the reasons they had to push for HTTPS and TLSv1.2, unique passwords, keeping software up to date, etc: using outdated and insecure software with significant attack surface has real costs even if it's convenient.
- upofadown 5y ago
  It is relatively easy to write an X based window manager that is actually usable. So the article could not exist in a Wayland context ... and it is not at all clear what framework will make Wayland usable in such a simple and straightforward way or if one is even possible.
  - kaba0 5y ago
    Wlroots would like a word with you.
    - upofadown 5y ago
      Here is a discussion of what that involves from someone who used wlroots to write a window manager other than Sway: * http://inclem.net/2021/04/17/wayland/writing_a_wayland_compositor_with_wlroots/ http://inclem.net/2021/04/17/wayland/writing_a_wayland_compo...
shadowfox 5y ago
Slightly orthogonal to this: is there a good tutorial on writing your own simple Xserver?
- loxias 5y ago
  I don't know about a tutorial, but I learned a lot from the xvfb and xvnc code.
- dfox 5y ago
  https://magcius.github.io/xplain/article/x-basics.html https://magcius.github.io/xplain/article/x-basics.html Last time I checked it was work in progress and I'm not sure how complete it is at this moment, but it includes understandable explanations of the low-level algorithms and acceleration structures involved. Edit: this shows how X works from the lazout and graphical side. One interesting thing that is not covered by this is the somewhat peculiar wire format of X11 connection (it was obviously designed by someone with LISP background).
nerdponx 5y ago
Even if you don't intend to write your own WM, I think this article is a great reference for understanding how X works in general.
thuccess129 5y ago
Plan 9's rectangle multiplexer, rio, needs an X11 mouse gesture addon for consistent Desktop Environment Application clipboard with Emacs's do/undo versatility.
low_tech_love 5y ago
Funny, yesterday someone posted an article about an Ada-based X implementation, and I thought “could be fun to write my own X”. I guess I wasn’t the only one!
- forgotpwd16 5y ago
  For anyone that may have missed it: https://news.ycombinator.com/item?id=29077750 https://news.ycombinator.com/item?id=29077750
arduinomancer 5y ago
So for someone who knows nothing about this stuff, how is Wayland different?
- 5e92cb50239222b 5y ago
  https://wayland-book.com https://wayland-book.com
- Arnavion 5y ago
  In general, wayland does not implicitly have a distinction between server and window manager. There is a server and there are clients. The server gets to decide where a particular client's windows are rendered. Wayland itself is just a spec of the protocol that the client and server use to talk to each other - the format of the messages, and a few documents that describe various such messages. What the server does is basically completely arbitrary. I don't know about GNOME and KDE's wayland servers, but with sway and river and cage the server is a single process that does the job of both server and window manager. It doesn't mean everyone has to write the equivalent of an X server, ie code that interacts with OpenGL and the kernel interfaces, themselves - there is a popular library called wlroots that can be used for that. I don't think it's impossible that someone wraps wlroots into a standalone "server" binary that then has its own protocol for talking to an arbitrary "window manager" binary at runtime. ie do the equivalent of what wlroots does with function calls and callbacks at compile time but at runtime via IPC. But I don't know anyone who's doing such a thing.
- remix2000 5y ago
  People have already mentioned wlroots as a starting point, but there is a less opinionated and more compatible (NVIDIA-ready) library that I’m really quite fond of called Mir: https://github.com/MirServer/mir https://github.com/MirServer/mir One thing to note, Wayland, unlike X, does not support server side decorations yet, so compositor’s responsibilities are mostly just placing windows.
  - Arnavion 5y ago
    SSDs are supported via xdg-decoration (unstable) https://wayland.app/protocols/xdg-decoration-unstable-v1 https://wayland.app/protocols/xdg-decoration-unstable-v1
ninjin 5y ago
Talk about timing, I took my first plunge into writing code for X just a week or so ago and this was some really good reading. If someone is interested in digging into a non-toy, C codebase I can highly recommended dwm [1,2]. Yes, it is a very opinionated WM, but the code is clean, brief, and hackable – even for someone like me that has not hacked C for anything serious for over a decade – for something that can be used as a daily driver. It only took me about an hour or two to develop two patches that changed the layout to my liking. Plus, I have found the people in #suckless over at the OFTC IRC network to be very kind and helpful. [1]: https://dwm.suckless.org https://dwm.suckless.org [2]: https://git.suckless.org/dwm/files.html https://git.suckless.org/dwm/files.html
- Jasper_ 5y ago
  Keep in mind that DWM explicitly does not obey the ICCCM [0] (because they don't like it), meaning that large groups of applications might function erratically on it. This is not an idle concern -- I've had several bugs reported to me in some applications I've written were because the user wasn't running an ICCCM-compliant WM. [0] https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm.html https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm... , the standard for how X11 clients and WMs should communicate.
  - ninjin 5y ago
    Do you have a link to a bug report? I tried digging around a bit as I got curious how bugs like these would manifest, but could not find anything good to link. What I am aware of is that Java application can break without workarounds (saw it in the documentation somewhere) and that Steam needs an explicit workaround [1]. [1]: https://dwm.suckless.org/patches/steam https://dwm.suckless.org/patches/steam
    - IiydAbITMvJkqKf 5y ago
      All java applications refuse to render without said workaround, because AWT expects the WM to reparent its windows. This is IMO a bug in the JRE, because there is no requirement for the WM to reparent. I use steam on dwm without the steam patch, haven't noticed an issue so far.
liveprogramming 5y ago
This is a great article and I remember reading it numerous times while I was implementing my own window manager. For someone interested in working on a really fun and rewarding hobby project a WM is a great one to look into since there are so many resources starting from really small implementations: - https://github.com/mackstann/tinywm https://github.com/mackstann/tinywm - https://github.com/venam/2bwm https://github.com/venam/2bwm - https://github.com/dylanaraps/sowm https://github.com/dylanaraps/sowm - https://github.com/dcat/swm https://github.com/dcat/swm - https://github.com/JLErvin/berry https://github.com/JLErvin/berry Which are great at introducing the concepts and allowing you to grok the required libraries. To larger more full featured packed window managers which will introduce you to more advanced topics: - https://github.com/baskerville/bspwm https://github.com/baskerville/bspwm - https://github.com/herbstluftwm/herbstluftwm https://github.com/herbstluftwm/herbstluftwm - https://www.nongnu.org/ratpoison/ https://www.nongnu.org/ratpoison/ - https://github.com/conformal/spectrwm https://github.com/conformal/spectrwm Gradually as you get more familiar with the ecosystem a few questions will come up: Should I use X11 or XCB? - I personally used XCB and didn't find it too difficult to interface with, and there are a large number of implementations which use it (2bwm, bspwm, ratpoison, etc) so you shouldn't have an issue with learning more about it. But the documentation is pretty limited. If you are just wanting to write a toy WM than X11 is perfectly fine. X or Wayland? - If you're wanting to write your first WM as a hobby project than I would recommend X over wayland just due to the much larger amount of reference material and documentation. You will have a much easier time getting your feet wet. Ignore the comments about X dying as it doesn't really matter for a hobby project, since the whole point is to have fun. Feel free to check out my window manager which is an example of what just reading this blog post and getting inspired can result in: https://github.com/cfrank/natwm https://github.com/cfrank/natwm
- DonHopkins 5y ago
  I made an X10 window manager based on "uwm" in 1987, which had pie menus, and was extensible and scriptable in FORTH! https://donhopkins.com/home/archive/piemenu/uwm/ https://donhopkins.com/home/archive/piemenu/uwm/ https://donhopkins.com/home/archive/piemenu/uwm/Menu.c https://donhopkins.com/home/archive/piemenu/uwm/Menu.c https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f I didn't see a bright future for X (and still don't ;) ), so I switched to NeWS, and began writing pie menus and window managers in PostScript. NeWS (which was James Gosling's creation before Java and after Emacs) was architecturally similar to what is now called AJAX, except that NeWS coherently: - used PostScript code instead of JavaScript for programming. - used PostScript graphics instead of DHTML and CSS for rendering. - used PostScript data instead of XML and JSON for data representation. Pie Menus and Tab Windows for NeWS in object oriented PostScript: https://donhopkins.com/home/archive/piemenu/pieui/ https://donhopkins.com/home/archive/piemenu/pieui/ NeWS Tab Window Demo: https://www.youtube.com/watch?v=tMcmQk-q0k4 https://www.youtube.com/watch?v=tMcmQk-q0k4 At Sun, we even used the above code to write an X11 ICCCM "Open Window Manager" in PostScript for X11/NeWS, which wrapped your X11 windows in NeWS tabbed frames with pie menus, implemented in PostScript, the same as all your NeWS windows used, all running in the same address space, and easily centrally customizable and extensible. https://news.ycombinator.com/item?id=13817649 https://news.ycombinator.com/item?id=13817649 >At Sun we experimented with implementing an X11 window manager in NeWS. We didn't have transparency at the time (1992), but we did support shaped windows! >The NeWS window manager supported cool stuff (for both X11 and NeWS windows!) like rooms, virtual scrolling desktops, tabbed windows, pie menus, was easily extensible and deeply customisable in PostScript, and ran locally in the window server so it could respond instantly to input events, lock the input queue and provide feedback and manipulate windows immediately without causing any context switches or dealing with asynchronous locking, unlocking and event handling. You'd never lose a keystroke or click when switching between applications, for example. https://news.ycombinator.com/item?id=22456153 https://news.ycombinator.com/item?id=22456153 >And we had a lot of internal discussion about how NeWS fit into Sun's window system strategy. We developed a prototype X11 window manager in NeWS, to prove how much better NeWS can handle seamlessly integrated NeWS and X window management much better than X can manage its own windows. The next step we wanted to take was to write a user-extensible HyperCard-like window manager using HyperNeWS/HyperLook. But Sun management wasn't having it. They actually wanted to do the worst-possible upside-down solution and put NeWS applications inside of X-Windows managed by OLWM, precluding the possibility of arbitrarily shaped windows, tabbed windows, pie menus, all stuff we'd been doing for years with NeWS that we'd have to give up in the name of X interoperability, after we'd already proven we had a working better solution with "owm". https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://donhopkins.com/home/archive/NeWS/owm.ps.txt >% Open Window Manager /ClassX11ManagerMixin ClassWindow [/IconWindow /WidthInc /HeightInc /FirstMapping] classbegin /NewInit { % client => - /NewInit super send self /WM_STATE xdeleteproperty % The frame is not a ICCCM window } def https://www.donhopkins.com/home/archive/NeWS/sevans.txt https://www.donhopkins.com/home/archive/NeWS/sevans.txt >Don> If you don't want to dump NeWS, then why have you been caused us so much trouble? >Steve> I could ask you the same question, "If you want NeWS to be a commercial success, why has NeWSTech been so subborn in the sense of resisting trying to fit into the X environment." >Don> That's not the same question. We want NeWS to be a commercial success, but "commercial success" is not a standard defined by the X Consortium. I think OWM can do a beautiful job of fitting the X environment into NeWS. If you find that concept terrifying, then you know how we feel about the inverse, knowing that we will have to give up many goals we designed for and successfully achieved, in order to accomodate a half assed "fallback" solution to satisfy some of our customers who want to run our competitors' software (because we aren't allowed to make our software good enough for them to want to run). >We have had a great deal of trouble trying to fit into the X environment. It has taken a huge amount of PostScript code to deal with many X interoperability issues ranging from undocumented selection protocols that XView and OLIT can't even agree on, to input focus grabbing kludges to work around OLWM's incorrect focus tracking behavior, to the fullscreen.ps hack to keep X from grabbing the pointer when NeWS is tracking it. Then there are problems we could do nothing about, like the system locking up when OLWM grabs the server (grabbing the pointer after grabbing the server, and not checking the return value). Many of these problems should have been addressed by fixing X programs or the server, but they were not, instead we had to code around them in PostScript when we could. NeWS had its own problems, of course, but its biggest problems weren't technical, but political, and it wasn't free despite all the hard effort, spilled blood, and broken promises. But the consequences of that experience did help to make Java free, eventually. (But then Oracle later ruined worse than Sun ever could have.) https://news.ycombinator.com/item?id=22457490 https://news.ycombinator.com/item?id=22457490 >James Gosling fought very hard for NeWS, but in the end failed to convince Sun to do the right thing. He was optimistic when he talked me into going to Sun to work on NeWS after I'd already given up on it by 1990, saying that Sun had turned over a new leaf, and was soon going to announce their commitment to NeWS: [...] >"We'll get it out, even if I have to spill some real blood on the floor." -James Gosling, on freeing NeWS, March 6, 1990 >[...] It has been very clear for a long time that DEC explicitly targeted NeWS as something to be trashed. That was probably the major reason for giving NeWS such a ridiculously low profile. There were folks at sun who didn't want to give DEC a bigger target. The folks running the show now have more guts. >James. https://www.donhopkins.com/home/archive/NeWS/flame.txt https://www.donhopkins.com/home/archive/NeWS/flame.txt >November 11, 1990: >I have been hoping for Sun to make Open Windows free since it was called SunDew, and during that time, I've made it perform many indescribable acts (both on and off stage), worked with quite a few companies trying to make it a succeess, and drained much much more of my energy than I ever knew I had to give into that incredible piece of software. >I have been following the messages on the network in the aftermath of the OWPS "free for $1000" disaster... The big problem was not the $1000. It was the word "free".
phendrenad2 5y ago
No mention of sockets? I'm surprised. That's the real tricky part of writing an X11 server...
- emersion 5y ago
  This article is about writing an X11 window manager, which is a different piece of software. An XWM is an X11 client. Writing an X11 server is a much more involved effort (there's a reason why there's only one widely used implementation, Xorg).
- mcguire 5y ago
  Sockets? Not the whole "dealing with graphics hardware" thing?
cunidev 5y ago
Is there anything similar for Wayland? Its protocol looks considerably more complex than Xorg's, and so are most resources to learn it.
- phendrenad2 5y ago
  Most of the concepts here are the same for wayland. The only difference is, Wayland handles compositing, whereas in x11 compositing is a pluggable component.
  - yissp 5y ago
    A Wayland compositor is responsible for quite a bit more than an X11 window manager. Compositing, as you mentioned, but also display modesetting, input handling, clipboard management, and so on. Although, of course, one can use a library like wlroots or libweston to handle most of that stuff if you just want to focus on the desktop experience.
- ximm 5y ago
  I think the dwl codebase is an excellent read: https://github.com/djpohly/dwl https://github.com/djpohly/dwl
- samus 5y ago
  It's quite ardous and unfun, but the wlroots project does most of the heavy lifting. For beginners it's probably useful to create a toy WM using wlroots[0] and dig deeper from there[1]. [0]: https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master/tinywl https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master... [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Getting-started#additional-resources https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Getti...
  - wing-_-nuts 5y ago
    The last time I used wlroots, via sway, I encountered a bug where I experienced 'multicolored snow' when watching a video in firefox. I wanted to record a video of it to report a bug, but of course that wasn't possible because screen sharing / recording still isn't well supported. Back to gnome I went, and I still don't think wayland is ready for primetime on smaller window managers
DonHopkins 5y ago
https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >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 Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend): https://blog.dshr.org/2018/05/recreational-bugs.html https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.
- marcodiego 5y ago
fmakunbound 5y ago
I used to write an X11 window managers as a kick-the-tires exercise when learning a new language. The most fun one was Common Lisp with CLX. You could stay in the WM and code it live. When something went wrong you could continue after making fixes. It’s what lead me to Common Lisp being my favorite language going on decades now.
- moocowtruck 5y ago
  and we in the industry have traded all that power and flexibility for...a gigantic mess of lock-in, never ending nouns, and "needing the right language for the right job", when in reality they all become crap lisps
- hulitu 5y ago
  There was a window manager (gwm) written in a lisp dialect (wool). It was very nice.
rnd0 5y ago
I did not know I needed this until I saw this headline. I feel a new personal tangent coming on -thanks!

276 points by firefly284 5y ago

fyrn- 5y ago

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

zephyr9 5y ago
Does upstream Wayland work on any platform except for Linux? Does this display server have any form of colour management for, you know, the stuff it's displaying? Wayland is taking off like the Spruce Moose...
- emersion 5y ago
  Feel free to continue using X11 of course, no one's forcing anybody to switch. That said: > Does upstream Wayland work on any platform except for Linux? Yes, FreeBSD. Patches welcome to make it work on other BSDs. > Does this display server have any form of colour management for, you know, the stuff it's displaying? No more than X11 right now, ie. none. But it's in the works.
  - zephyr9 5y ago
    I was under the impression Wayland on FreeBSD required a lot of patching on their end, but this has been merged upstream? If so that's pretty good news. Also good news re colour management. The last I heard about this was Drew DeVault (and I'm paraphrasing) calling it "precious horseshit". [0] https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.html https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.ht...
    - kaba0 5y ago
      There is work on HDR colors, but I haven’t followed up on it.
linguae 5y ago
1. The article was written in 2014. 2. While it appears that Wayland is poised to replace X11 on Linux desktops given the amount of backing Wayland has compared to X11, it is not clear whether Wayland will replace X11 in the BSD ecosystem. According to the FreeBSD Wiki, Wayland is not ready to be a daily driver (https://wiki.freebsd.org/Graphics/Wayland https://wiki.freebsd.org/Graphics/Wayland), though work has been done getting Wayland compositors and other software to work on FreeBSD. I use X11 on my FreeBSD desktop. I'm unfamiliar with the current status of Wayland on NetBSD and OpenBSD. I expect X11 to live on for quite some time in the BSD world and among more conservative Linux users, similar to the situation regarding systemd in the Linux community, which was adopted by mainstream distributions and users but faced (and still faces) opposition from some users.
- mrweasel 5y ago
  Someone has started work on OpenBSD Wayland: https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-report/ https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-... I doubt it's something that will be ready for 7.1 next spring, but it's nice to see that it's actually working.
- pimeys 5y ago
  I've been using Wayland and Sway with FreeBSD 13 quite successfully. Everything worked quite well, except some indicators in Waybar that were using some Linux specific things to get values for memory usage etc...
- mcguire 5y ago
  3. Wayland has been "starting to take off" for longer than many of the readers here have been alive.
josefx 5y ago
That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.
- 5e92cb50239222b 5y ago
  What "Wayland people"? You probably mean the former Xorg developers who shifted to full time Wayland development long ago. Xorg is on life support, it has been getting bug fixes and nothing else for the past several years. From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.
  - josefx 5y ago
    > Xorg is on life support, it has been getting bug fixes and nothing else for the past several years. Imagine two cars: X11 its an old one, it doesn't quite start right, the windows are chipped, the paint is peeling of and no one really wants to invest money into maintaining it, it defaults to brakes and a steering wheel from 1980 but has seen continous upgrades over time and you can generally swap in a steering wheel from 2010 with minor problems. Now imagine wayland, a brand new tesla, it doesn't have brakes or a steering wheel because history has shown that these concepts evolve and if anything it should be a third party provider that creates them. Who cares that it took ten years between the release of the car as ready for use and the first compatible steering wheel implementation? Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction. > From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves. As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs). Of course the people who wrote wayland also wrote X11 so removing themselves from the equation might have been the nicest thing they ever did, given their own opinion of their past work on X11.
    - Arnavion 5y ago
qwerty456127 5y ago
This is exactly why I would rather do. I see absolutely no reason to abandon X and want to learn its internals to be able to maintain it myself. To me X seems a perfect piece of software which just works and does its job flawlessly, while having all the features I ever needed (including remote execution - I used Windows apps running on a remote Linux machine with Wine over SSH over OpenVPN on a local Windows machine and that was very easy).
- Seirdy 5y ago
  1. Wayland does support remote execution; see waypipe for an example. 2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).
  - vidarh 5y ago
    X worked just fine on early 90s hardware. Performance today is about implementation, nothing inherent about X.
    - Seirdy 5y ago
      ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.
      - qwerty456127 5y ago
        What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO. I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.
loxias 5y ago
> replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.
- perth 5y ago
  Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland. Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work Some relevant links for those curious about other people hitting into this: https://www.foell.org/justin/simple-hidpi-monitor-scaling-with-wayland-in-ubuntu-18-04/ https://www.foell.org/justin/simple-hidpi-monitor-scaling-wi... Gnome team: https://wiki.gnome.org/Initiatives/Wayland/XWayland https://wiki.gnome.org/Initiatives/Wayland/XWayland
  - jcelerier 5y ago
    Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt
    - perth 5y ago
      Try to set two different DPIs in that.
      - AshamedCaptain 5y ago
        You certainly can, but the problem is that there is no agreed standard from the toolkits to do it. E.g. Qt has its own way.
sprash 5y ago
> right as the replacemeant for Xorg starts to take off though It has been "taking off" for 13 years at this point. It seems like it doesn't have much thrust behind it.
- Seirdy 5y ago
  Fedora, Ubuntu, OpenSUSE, RHEL/Rocky, and Debian all have their default desktops on Wayland. Both GNOME and KDE have already switched and will keep legacy X around for compatibility purposes for another few years. On the more minimal side to compete with X-based window managers: Sway is very mature and River is turning out nicely. All that's left is an Openbox alternative. I believe there are a few, but I'm not familiar. Wayland has already taken off; once we get XFCE to switch we should be able to move on.
  - deleted 5y ago
    [deleted]
  - sprash 5y ago
    This is not an organic transition. Major organizations seems to "push" it but there is not much "pull". Compare this to the "transition" from CVS/SVN to git. There was no need to even advertise git. People saw it and wanted it. The X11 ecosystem is more than just GNOME, KDE and i3 and porting XFCE will not be enough to "move on" (For me it is the small things like Xdotool, Xsel, Xcalib, etc. that are holding me back). Maybe X11 needs to be replaced but Wayland is not the answer. It's just not good enough and because of fundamental flaws of its philosophical concepts it will never be.
    - Seirdy 5y ago
      Xdotool and xsel have had Wayland equivalents for years: see ydotool/wtype and wl-clipboard. The reason why major orgs have had to push for Wayland is the same as the reasons they had to push for HTTPS and TLSv1.2, unique passwords, keeping software up to date, etc: using outdated and insecure software with significant attack surface has real costs even if it's convenient.
upofadown 5y ago
It is relatively easy to write an X based window manager that is actually usable. So the article could not exist in a Wayland context ... and it is not at all clear what framework will make Wayland usable in such a simple and straightforward way or if one is even possible.
- kaba0 5y ago
  Wlroots would like a word with you.
  - upofadown 5y ago
    Here is a discussion of what that involves from someone who used wlroots to write a window manager other than Sway: * http://inclem.net/2021/04/17/wayland/writing_a_wayland_compositor_with_wlroots/ http://inclem.net/2021/04/17/wayland/writing_a_wayland_compo...

shadowfox 5y ago

Slightly orthogonal to this: is there a good tutorial on writing your own simple Xserver?

loxias 5y ago
I don't know about a tutorial, but I learned a lot from the xvfb and xvnc code.
dfox 5y ago
https://magcius.github.io/xplain/article/x-basics.html https://magcius.github.io/xplain/article/x-basics.html Last time I checked it was work in progress and I'm not sure how complete it is at this moment, but it includes understandable explanations of the low-level algorithms and acceleration structures involved. Edit: this shows how X works from the lazout and graphical side. One interesting thing that is not covered by this is the somewhat peculiar wire format of X11 connection (it was obviously designed by someone with LISP background).

nerdponx 5y ago

Even if you don't intend to write your own WM, I think this article is a great reference for understanding how X works in general.

thuccess129 5y ago

Plan 9's rectangle multiplexer, rio, needs an X11 mouse gesture addon for consistent Desktop Environment Application clipboard with Emacs's do/undo versatility.

low_tech_love 5y ago

Funny, yesterday someone posted an article about an Ada-based X implementation, and I thought “could be fun to write my own X”. I guess I wasn’t the only one!

forgotpwd16 5y ago
For anyone that may have missed it: https://news.ycombinator.com/item?id=29077750 https://news.ycombinator.com/item?id=29077750

arduinomancer 5y ago

So for someone who knows nothing about this stuff, how is Wayland different?

5e92cb50239222b 5y ago
https://wayland-book.com https://wayland-book.com
Arnavion 5y ago
In general, wayland does not implicitly have a distinction between server and window manager. There is a server and there are clients. The server gets to decide where a particular client's windows are rendered. Wayland itself is just a spec of the protocol that the client and server use to talk to each other - the format of the messages, and a few documents that describe various such messages. What the server does is basically completely arbitrary. I don't know about GNOME and KDE's wayland servers, but with sway and river and cage the server is a single process that does the job of both server and window manager. It doesn't mean everyone has to write the equivalent of an X server, ie code that interacts with OpenGL and the kernel interfaces, themselves - there is a popular library called wlroots that can be used for that. I don't think it's impossible that someone wraps wlroots into a standalone "server" binary that then has its own protocol for talking to an arbitrary "window manager" binary at runtime. ie do the equivalent of what wlroots does with function calls and callbacks at compile time but at runtime via IPC. But I don't know anyone who's doing such a thing.
remix2000 5y ago
People have already mentioned wlroots as a starting point, but there is a less opinionated and more compatible (NVIDIA-ready) library that I’m really quite fond of called Mir: https://github.com/MirServer/mir https://github.com/MirServer/mir One thing to note, Wayland, unlike X, does not support server side decorations yet, so compositor’s responsibilities are mostly just placing windows.
- Arnavion 5y ago
  SSDs are supported via xdg-decoration (unstable) https://wayland.app/protocols/xdg-decoration-unstable-v1 https://wayland.app/protocols/xdg-decoration-unstable-v1

ninjin 5y ago

Talk about timing, I took my first plunge into writing code for X just a week or so ago and this was some really good reading. If someone is interested in digging into a non-toy, C codebase I can highly recommended dwm [1,2]. Yes, it is a very opinionated WM, but the code is clean, brief, and hackable – even for someone like me that has not hacked C for anything serious for over a decade – for something that can be used as a daily driver. It only took me about an hour or two to develop two patches that changed the layout to my liking. Plus, I have found the people in #suckless over at the OFTC IRC network to be very kind and helpful. [1]: https://dwm.suckless.org https://dwm.suckless.org [2]: https://git.suckless.org/dwm/files.html https://git.suckless.org/dwm/files.html

Jasper_ 5y ago
Keep in mind that DWM explicitly does not obey the ICCCM [0] (because they don't like it), meaning that large groups of applications might function erratically on it. This is not an idle concern -- I've had several bugs reported to me in some applications I've written were because the user wasn't running an ICCCM-compliant WM. [0] https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm.html https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm... , the standard for how X11 clients and WMs should communicate.
- ninjin 5y ago
  Do you have a link to a bug report? I tried digging around a bit as I got curious how bugs like these would manifest, but could not find anything good to link. What I am aware of is that Java application can break without workarounds (saw it in the documentation somewhere) and that Steam needs an explicit workaround [1]. [1]: https://dwm.suckless.org/patches/steam https://dwm.suckless.org/patches/steam
  - IiydAbITMvJkqKf 5y ago
    All java applications refuse to render without said workaround, because AWT expects the WM to reparent its windows. This is IMO a bug in the JRE, because there is no requirement for the WM to reparent. I use steam on dwm without the steam patch, haven't noticed an issue so far.

liveprogramming 5y ago

This is a great article and I remember reading it numerous times while I was implementing my own window manager. For someone interested in working on a really fun and rewarding hobby project a WM is a great one to look into since there are so many resources starting from really small implementations: - https://github.com/mackstann/tinywm https://github.com/mackstann/tinywm - https://github.com/venam/2bwm https://github.com/venam/2bwm - https://github.com/dylanaraps/sowm https://github.com/dylanaraps/sowm - https://github.com/dcat/swm https://github.com/dcat/swm - https://github.com/JLErvin/berry https://github.com/JLErvin/berry Which are great at introducing the concepts and allowing you to grok the required libraries. To larger more full featured packed window managers which will introduce you to more advanced topics: - https://github.com/baskerville/bspwm https://github.com/baskerville/bspwm - https://github.com/herbstluftwm/herbstluftwm https://github.com/herbstluftwm/herbstluftwm - https://www.nongnu.org/ratpoison/ https://www.nongnu.org/ratpoison/ - https://github.com/conformal/spectrwm https://github.com/conformal/spectrwm Gradually as you get more familiar with the ecosystem a few questions will come up: Should I use X11 or XCB? - I personally used XCB and didn't find it too difficult to interface with, and there are a large number of implementations which use it (2bwm, bspwm, ratpoison, etc) so you shouldn't have an issue with learning more about it. But the documentation is pretty limited. If you are just wanting to write a toy WM than X11 is perfectly fine. X or Wayland? - If you're wanting to write your first WM as a hobby project than I would recommend X over wayland just due to the much larger amount of reference material and documentation. You will have a much easier time getting your feet wet. Ignore the comments about X dying as it doesn't really matter for a hobby project, since the whole point is to have fun. Feel free to check out my window manager which is an example of what just reading this blog post and getting inspired can result in: https://github.com/cfrank/natwm https://github.com/cfrank/natwm

DonHopkins 5y ago
I made an X10 window manager based on "uwm" in 1987, which had pie menus, and was extensible and scriptable in FORTH! https://donhopkins.com/home/archive/piemenu/uwm/ https://donhopkins.com/home/archive/piemenu/uwm/ https://donhopkins.com/home/archive/piemenu/uwm/Menu.c https://donhopkins.com/home/archive/piemenu/uwm/Menu.c https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f I didn't see a bright future for X (and still don't ;) ), so I switched to NeWS, and began writing pie menus and window managers in PostScript. NeWS (which was James Gosling's creation before Java and after Emacs) was architecturally similar to what is now called AJAX, except that NeWS coherently: - used PostScript code instead of JavaScript for programming. - used PostScript graphics instead of DHTML and CSS for rendering. - used PostScript data instead of XML and JSON for data representation. Pie Menus and Tab Windows for NeWS in object oriented PostScript: https://donhopkins.com/home/archive/piemenu/pieui/ https://donhopkins.com/home/archive/piemenu/pieui/ NeWS Tab Window Demo: https://www.youtube.com/watch?v=tMcmQk-q0k4 https://www.youtube.com/watch?v=tMcmQk-q0k4 At Sun, we even used the above code to write an X11 ICCCM "Open Window Manager" in PostScript for X11/NeWS, which wrapped your X11 windows in NeWS tabbed frames with pie menus, implemented in PostScript, the same as all your NeWS windows used, all running in the same address space, and easily centrally customizable and extensible. https://news.ycombinator.com/item?id=13817649 https://news.ycombinator.com/item?id=13817649 >At Sun we experimented with implementing an X11 window manager in NeWS. We didn't have transparency at the time (1992), but we did support shaped windows! >The NeWS window manager supported cool stuff (for both X11 and NeWS windows!) like rooms, virtual scrolling desktops, tabbed windows, pie menus, was easily extensible and deeply customisable in PostScript, and ran locally in the window server so it could respond instantly to input events, lock the input queue and provide feedback and manipulate windows immediately without causing any context switches or dealing with asynchronous locking, unlocking and event handling. You'd never lose a keystroke or click when switching between applications, for example. https://news.ycombinator.com/item?id=22456153 https://news.ycombinator.com/item?id=22456153 >And we had a lot of internal discussion about how NeWS fit into Sun's window system strategy. We developed a prototype X11 window manager in NeWS, to prove how much better NeWS can handle seamlessly integrated NeWS and X window management much better than X can manage its own windows. The next step we wanted to take was to write a user-extensible HyperCard-like window manager using HyperNeWS/HyperLook. But Sun management wasn't having it. They actually wanted to do the worst-possible upside-down solution and put NeWS applications inside of X-Windows managed by OLWM, precluding the possibility of arbitrarily shaped windows, tabbed windows, pie menus, all stuff we'd been doing for years with NeWS that we'd have to give up in the name of X interoperability, after we'd already proven we had a working better solution with "owm". https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://donhopkins.com/home/archive/NeWS/owm.ps.txt >% Open Window Manager /ClassX11ManagerMixin ClassWindow [/IconWindow /WidthInc /HeightInc /FirstMapping] classbegin /NewInit { % client => - /NewInit super send self /WM_STATE xdeleteproperty % The frame is not a ICCCM window } def https://www.donhopkins.com/home/archive/NeWS/sevans.txt https://www.donhopkins.com/home/archive/NeWS/sevans.txt >Don> If you don't want to dump NeWS, then why have you been caused us so much trouble? >Steve> I could ask you the same question, "If you want NeWS to be a commercial success, why has NeWSTech been so subborn in the sense of resisting trying to fit into the X environment." >Don> That's not the same question. We want NeWS to be a commercial success, but "commercial success" is not a standard defined by the X Consortium. I think OWM can do a beautiful job of fitting the X environment into NeWS. If you find that concept terrifying, then you know how we feel about the inverse, knowing that we will have to give up many goals we designed for and successfully achieved, in order to accomodate a half assed "fallback" solution to satisfy some of our customers who want to run our competitors' software (because we aren't allowed to make our software good enough for them to want to run). >We have had a great deal of trouble trying to fit into the X environment. It has taken a huge amount of PostScript code to deal with many X interoperability issues ranging from undocumented selection protocols that XView and OLIT can't even agree on, to input focus grabbing kludges to work around OLWM's incorrect focus tracking behavior, to the fullscreen.ps hack to keep X from grabbing the pointer when NeWS is tracking it. Then there are problems we could do nothing about, like the system locking up when OLWM grabs the server (grabbing the pointer after grabbing the server, and not checking the return value). Many of these problems should have been addressed by fixing X programs or the server, but they were not, instead we had to code around them in PostScript when we could. NeWS had its own problems, of course, but its biggest problems weren't technical, but political, and it wasn't free despite all the hard effort, spilled blood, and broken promises. But the consequences of that experience did help to make Java free, eventually. (But then Oracle later ruined worse than Sun ever could have.) https://news.ycombinator.com/item?id=22457490 https://news.ycombinator.com/item?id=22457490 >James Gosling fought very hard for NeWS, but in the end failed to convince Sun to do the right thing. He was optimistic when he talked me into going to Sun to work on NeWS after I'd already given up on it by 1990, saying that Sun had turned over a new leaf, and was soon going to announce their commitment to NeWS: [...] >"We'll get it out, even if I have to spill some real blood on the floor." -James Gosling, on freeing NeWS, March 6, 1990 >[...] It has been very clear for a long time that DEC explicitly targeted NeWS as something to be trashed. That was probably the major reason for giving NeWS such a ridiculously low profile. There were folks at sun who didn't want to give DEC a bigger target. The folks running the show now have more guts. >James. https://www.donhopkins.com/home/archive/NeWS/flame.txt https://www.donhopkins.com/home/archive/NeWS/flame.txt >November 11, 1990: >I have been hoping for Sun to make Open Windows free since it was called SunDew, and during that time, I've made it perform many indescribable acts (both on and off stage), worked with quite a few companies trying to make it a succeess, and drained much much more of my energy than I ever knew I had to give into that incredible piece of software. >I have been following the messages on the network in the aftermath of the OWPS "free for $1000" disaster... The big problem was not the $1000. It was the word "free".

phendrenad2 5y ago

No mention of sockets? I'm surprised. That's the real tricky part of writing an X11 server...

emersion 5y ago
This article is about writing an X11 window manager, which is a different piece of software. An XWM is an X11 client. Writing an X11 server is a much more involved effort (there's a reason why there's only one widely used implementation, Xorg).
mcguire 5y ago
Sockets? Not the whole "dealing with graphics hardware" thing?

cunidev 5y ago

Is there anything similar for Wayland? Its protocol looks considerably more complex than Xorg's, and so are most resources to learn it.

phendrenad2 5y ago
Most of the concepts here are the same for wayland. The only difference is, Wayland handles compositing, whereas in x11 compositing is a pluggable component.
- yissp 5y ago
  A Wayland compositor is responsible for quite a bit more than an X11 window manager. Compositing, as you mentioned, but also display modesetting, input handling, clipboard management, and so on. Although, of course, one can use a library like wlroots or libweston to handle most of that stuff if you just want to focus on the desktop experience.
ximm 5y ago
I think the dwl codebase is an excellent read: https://github.com/djpohly/dwl https://github.com/djpohly/dwl
samus 5y ago
It's quite ardous and unfun, but the wlroots project does most of the heavy lifting. For beginners it's probably useful to create a toy WM using wlroots[0] and dig deeper from there[1]. [0]: https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master/tinywl https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master... [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Getting-started#additional-resources https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Getti...
- wing-_-nuts 5y ago
  The last time I used wlroots, via sway, I encountered a bug where I experienced 'multicolored snow' when watching a video in firefox. I wanted to record a video of it to report a bug, but of course that wasn't possible because screen sharing / recording still isn't well supported. Back to gnome I went, and I still don't think wayland is ready for primetime on smaller window managers

DonHopkins 5y ago

https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >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 Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend): https://blog.dshr.org/2018/05/recreational-bugs.html https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.

marcodiego 5y ago

fmakunbound 5y ago

I used to write an X11 window managers as a kick-the-tires exercise when learning a new language. The most fun one was Common Lisp with CLX. You could stay in the WM and code it live. When something went wrong you could continue after making fixes. It’s what lead me to Common Lisp being my favorite language going on decades now.

moocowtruck 5y ago
and we in the industry have traded all that power and flexibility for...a gigantic mess of lock-in, never ending nouns, and "needing the right language for the right job", when in reality they all become crap lisps
hulitu 5y ago
There was a window manager (gwm) written in a lisp dialect (wool). It was very nice.

rnd0 5y ago

I did not know I needed this until I saw this headline. I feel a new personal tangent coming on -thanks!