XMonad is an an amazing window manager (WM) made by a bunch of nerds who care a whole lot about a niche problem. Software by caring nerds is my favorite software as a user.
I really hope it makes the jump to Wayland. I've used XMonad for more than a decade and it's still my favorite WM.
XMonad really let me forget about managing windows---I never have to resize a window or remember where I put a window. XMonad handles the arranging and resizing and floating for me. There's a nice layout for small screens that will zoom your active window[0]. You can cobble your desktop together into whatever makes you happiest: Active corners. ScratchPads. So much in XMonad Contrib[1].
Since I'm not the right person to help with porting to Wayland, I'm giving money via the GitHub sponsorship page[2].
I check in on discourse from time to time: progress looks slow. The person/people they need are hard to come by.
> paying someone to work on a port of XMonad to Wayland, since none of us is up to the task
This is such a crazy mentality to me, coming from game development, where you can just go to a random 22yo kid's desk, ask them "do you want to port this game to the Nintendo Switch?" and they'll go "hell yeah" and do it in a few months, despite never having programmed for the device before.
You can just learn to do new things. By all accounts the Wayland protocol is simpler than X11, and you've already done the majority of the work. It's just a matter of adding a new backend. People do that all the time when they port a program to the web, a game to a new platform, or when they add a new architecture to a compiler.
One of the reasons why Wayland is "simpler" than X is that it doesn't include the APIs that window managers like Xmonad need. Instead, window managers have to implement a lot of the complex low-level graphics details themselves. This is why Wayland window managers are called "compositors" -- they include a lot of the code that used to be provided by the X server.
So the game development analogy here is, like, someone has just made their first Unity game and it's pretty good, but they don't feel like they'd be able to write their own game engine that's as good as Unity.
(The article mentions wlroots, which was an attempt to write a more general-purpose helper library for Wayland compositors. In practice this didn't work out; every major compositor other than Sway writes their own implementation of the stuff wlroots does.)
Is this you volunteering to do the port? I'm guessing you're not going to learn how to do this new thing. The real irony here is that they are actually implementing your suggestion - they're potentially going to hire some random 22yo who's response to porting XMonad to Wayland is "hell yeah!". Although realistically they'll probably get someone a bit more experienced.
They don't seem to be saying they can't do this or that it is some insurmountable technical challenge. They're saying that they aren't going to do it themselves and aren't giving reasons.
You're comparing a full-time salaried employee with a "few months" to spare vs. a bunch of people spending their spare time. Obviously not the same at all. There is a difference between "able to do the task, given enough time" vs. "wanting to invest the time". In a volunteer context "I don't have the (time|skill)" usually means "I don't want to invest the time".
In addition, making a WM in libX11 is surprisingly easy, almost trivial. With Wayland: not so much. Maybe the protocol is simpler for some meaning of "simpler", but actually doing stuff with it is often more complex, certainly if you want to write a WM (or compositor in Wayland-speak). I managed to write my own X11 WM without any real experience doing this sort of thing that has served me quite well for the last ten years. I also tried duplicating that in Wayland because I've been told that's the future, but I found that a lot harder to the point where I kind of just gave up. While I'm sure I could figure it out given enough time, I also don't really want to as I have other stuff to do, and also have a perfectly working X11 WM already.
Realistically, the future for small/custom window managers on Wayland is probably to write them as plugins for GNOME or KWin or Hyprland or something. That's kind of the closest equivalent we have to the X world where you could listen for events and move windows around on the screen, and the X server would handle everything else.
While an X11 window manager just manages windows, a Wayland "window manager" has to also do everything an X11 server does (including X11). It doesn't just manage windows.
There are display-server-as-a-library libraries you can link with, so that you can focus on writing the window management code you actually wanted to write, but you're still responsible for everything you link with, so it's far from trivial.
Also, xmonad re-execs itself to reload its configuration. Good luck with that when it's also your display server...
That is the thing with Wayland, it is much harder to create a window manager for Wayland. IIRC, fvwm decided not to create a Wayland version due to the difficulty.
When Wayland replacing X, lots of cool window managers and mini applications will be gone.
As a FVWM daily driver, it's amazing to see it's has gone from "it's the niftier-than-twm baseline that's installed by default in your 2.0-kernel Slackware or RedHat distro, but you'll probably install something trendy like AfterStep/WindowMaker/Enlightenment" to "It Has Powers That Cannot Be Recreated In The New Magic."
For me, the winning feature is FvwmButtons. Long before we had system trays and notification busses, if you wanted to put a media player, a clock, some stat counters, or a full-blown xterm, in a little desktop dock, you just captured a regular window. You didn't have to invent an entirely new category of "software designed to live as an icon inside someone else's ecosystem." I'm not aware of any compositor that offers anything like it-- it seems like the best we get now are ugly bars with a limited vocabulary of "we can integrate over some signaling bus with these three specific programmes and that's it".
I'll also lament the loss of bold, opinionated design. "Modern" compositors are either minimal to the point of nothingness, or insipid and generic. They don't look like the awesome UIs you'd see in old hacker movies, or the classic systems that were backed by 500 page HCI standards guides, they just look like the sort of UI you'd use in an textbook where you wanted to imply a GUI without anything specifically branded.
> I'll also lament the loss of bold, opinionated design. "Modern" compositors are either minimal to the point of nothingness, or insipid and generic. They don't look like the awesome UIs you'd see in old hacker movies, or the classic systems that were backed by 500 page HCI standards guides, they just look like the sort of UI you'd use in an textbook where you wanted to imply a GUI without anything specifically branded.
On Mastodon I follow a bot that posts screenshots of old Mac Kaleidoscope schemes and the creativity on display both leaves me in awe and makes me sad that no modern windowing system can hold a candle to it. With Kaleidoscope there were no rules. You could do a hacker OS[0], or game UI[1], or titlebars on the left[2] or underneath[3], or non-rectangular and chrome[4], or made of denim[5], and those are just a few of the thousands of wildly different themes[6].
Nothing on modern Linux comes close. Even if you seek out third party themes all you find are dozens of minor permutations on popular flat themes like Material and Nord. It's so dull.
True -- but then, FvwmButtons was never meant to compete with systray stuff, the original spec came via EWMH for that. and didn't really affect FvwmButtons' raison d'être.
Yeah, I’ve long had fantasies of writing a little desktop for myself next time I get a long stretch of time off, but that became much more daunting with the advent of Wayland, even when factoring in the existence of wlroots and such. It’s like going from building a bicycle to building a modern fuel injected car with an automatic transmission.
Application toolkits will eventually drop support for X11. GTK will remove it in GTK5. Not sure what Qt's plans are, but I'd have to think X11 support is long for this world there as well.
It's a shame about all the political bullshit they injected into the project, which already resulted in it being removed from several package repositories. I hope someone makes another fork in the vein of xlibre, but without political bullshit.
We also got a lot of new little niche window managers. hyprland, niri, cosmic, sway, river, labwc, dwl, wayfire and vivarium which is xnomad inspired...
Even still, they are very hard to work with when compared to X11.
Fvwm people are very smart and have been developing fvwm for longer than Linux have been around. From what I understand and have read, bring fvwm or creating a fvwm clone on Wayland is near impossible. Far too much work.
So we will really end up with "pigs" like Gnome3, KDE or a slew of tiling environments. None of the cool WMs like Windowmaker, fvwm, dluxbox, twm, ctwm, vtwm ....
This isn't wayland's fault. It's the compositor implementing wayland's fault for not exposing a window manager API. Nothing about wayland prohibits the creation of a window manager API.
I’ve heard the same thing about Wayland and NVidia’s drivers. To me, it seems like Wayland was designed to push all the hard work onto everybody else. That way Wayland never gets blamed for anything!
For practical purposes, the problem with Wayland from the WM-dev's PoV is that you're either implementing a huge project or you're depending on wlroots, and wlroots still isn't where it would need to be for implementing a simple window manager to be as easy as it was with X11.
From the Wayland devs' PoV, mainstreaming Wayland successfully shifted responsibility for doing most of the heavy lifting in the graphics layer from the neglected X-Windows project to the well-established KDE and GNOME. The state of wlroots and the ecosystem of personal WM projects is unavoidable collateral damage.
For an individual developer, perhaps the thing to do is take a page out of bbLean's [1] bag of tricks and implement your WM on top of one of the big two desktop environments.
Nothing stopped the adopters from waiting until that existed before pushing Wayland into their software and breaking many people's workflow either, yet here we are
However the radically different architecture of Wayland may necessitate a rewrite well beyond what the maintainers of a window manager feel is easy.
Even accounting for wlroots, you're not exactly just running sed on a glob. And unfortunately, wayland didn't actually fix X's complexity problem. Arcan did, but we're not allowed to have nice things because Redhat has no taste.
What about wayback? Assuming running X by itself becomes real bad and undesirable, would wayback+Xwayland cover all those "can't Wayland" use cases? What remains (besides better stability and wider availability of wayback) to be done?
I'm surprised that the Xmonad project is/was willing to pay someone. Does anyone know whether there was a single benefactor, or where the money was coming from, and why?
(Incidentally, I love the way that my Xmonad setup works, even though I don't know Haskell. I tried using an i3wm setup at work for maybe a year, but every evening coming back to Xmonad on my personal laptop felt like a boost of agility. I guess, if I were wealthy and wanted to move to Wayland, I would seriously consider either doing the work myself or paying someone to.)
Does anyone know of a Wayland WM/compositor that does multi-screen like XMonad? Preferably out of the box but I'll take configurable.
For those unaware, though I doubt you're reading this thread if so, I want n desktops that are shared between all screens, not desktops _assigned_ to particular screens. If I summon a desktop on screen 1 and it's currently displayed on screen 2, they should swap.
Ideally also does layouts kind of like xmonad too, not "here's a tiling tree structure and a bunch of commands to manually manage it".
> If I summon a desktop on screen 1 and it's currently displayed on screen 2, they should swap.
At least i3's (and I imagine sway's) config is sufficiently flexible for that. Here's a shell function that brings the workspace you specify to your current output:
> If I summon a desktop on screen 1 and it's currently displayed on screen 2, they should swap.
This is due to a limitation of X11 where a window can't be in two places at once. In theory, Wayland compositors can duplicate the desktop (at the cost of, like, not letting applications know their own window coordinates which seems pretty bad).
Yeah, I switched from XMonad (which I used for over a decade) to Sway a few years back. Spent some time trying to duplicate the XMonad behaviour but eventually just realized that spending a few hours getting used to the Sway approach and slightly changing my workflow was a lot easier.
I'm a long-time Xmonad user. Currently, I'm using Ubuntu 25.04, having upgraded to new non-LTS releases every six months, on two computers running Xmonad. I haven't run into any problems.
I used to be on XMonad years ago but the community seemed to be pigheaded about NEVER porting to Wayland so I abandoned it for Sway and never looked back. Was fun learning Haskell to write config but otherwise life is way easier with other WMs.
Readit News
I really hope it makes the jump to Wayland. I've used XMonad for more than a decade and it's still my favorite WM.
XMonad really let me forget about managing windows---I never have to resize a window or remember where I put a window. XMonad handles the arranging and resizing and floating for me. There's a nice layout for small screens that will zoom your active window[0]. You can cobble your desktop together into whatever makes you happiest: Active corners. ScratchPads. So much in XMonad Contrib[1].
Since I'm not the right person to help with porting to Wayland, I'm giving money via the GitHub sponsorship page[2].
I check in on discourse from time to time: progress looks slow. The person/people they need are hard to come by.
[0]: <https://xmonad.github.io/xmonad-docs/xmonad-contrib/XMonad-L...>
[1]: <https://hackage.haskell.org/package/xmonad-contrib>
[2]: <https://github.com/sponsors/xmonad>
This is such a crazy mentality to me, coming from game development, where you can just go to a random 22yo kid's desk, ask them "do you want to port this game to the Nintendo Switch?" and they'll go "hell yeah" and do it in a few months, despite never having programmed for the device before.
You can just learn to do new things. By all accounts the Wayland protocol is simpler than X11, and you've already done the majority of the work. It's just a matter of adding a new backend. People do that all the time when they port a program to the web, a game to a new platform, or when they add a new architecture to a compiler.
So the game development analogy here is, like, someone has just made their first Unity game and it's pretty good, but they don't feel like they'd be able to write their own game engine that's as good as Unity.
(The article mentions wlroots, which was an attempt to write a more general-purpose helper library for Wayland compositors. In practice this didn't work out; every major compositor other than Sway writes their own implementation of the stuff wlroots does.)
They don't seem to be saying they can't do this or that it is some insurmountable technical challenge. They're saying that they aren't going to do it themselves and aren't giving reasons.
Deleted Comment
In addition, making a WM in libX11 is surprisingly easy, almost trivial. With Wayland: not so much. Maybe the protocol is simpler for some meaning of "simpler", but actually doing stuff with it is often more complex, certainly if you want to write a WM (or compositor in Wayland-speak). I managed to write my own X11 WM without any real experience doing this sort of thing that has served me quite well for the last ten years. I also tried duplicating that in Wayland because I've been told that's the future, but I found that a lot harder to the point where I kind of just gave up. While I'm sure I could figure it out given enough time, I also don't really want to as I have other stuff to do, and also have a perfectly working X11 WM already.
Remember that many open-source contributors do it on their free time, with whatever energy they have left after their job.
Plenty of 22 year old and younger kids willing to grind for the lottery possibility to actually be part of the team.
There are display-server-as-a-library libraries you can link with, so that you can focus on writing the window management code you actually wanted to write, but you're still responsible for everything you link with, so it's far from trivial.
Also, xmonad re-execs itself to reload its configuration. Good luck with that when it's also your display server...
When Wayland replacing X, lots of cool window managers and mini applications will be gone.
IMO Ganeti died because of such a choice. There aren't enough programmers that are willing to invest into that niche.
I have nothing against that language per se, still such a choice can easily develop into a dead end.
For me, the winning feature is FvwmButtons. Long before we had system trays and notification busses, if you wanted to put a media player, a clock, some stat counters, or a full-blown xterm, in a little desktop dock, you just captured a regular window. You didn't have to invent an entirely new category of "software designed to live as an icon inside someone else's ecosystem." I'm not aware of any compositor that offers anything like it-- it seems like the best we get now are ugly bars with a limited vocabulary of "we can integrate over some signaling bus with these three specific programmes and that's it".
I'll also lament the loss of bold, opinionated design. "Modern" compositors are either minimal to the point of nothingness, or insipid and generic. They don't look like the awesome UIs you'd see in old hacker movies, or the classic systems that were backed by 500 page HCI standards guides, they just look like the sort of UI you'd use in an textbook where you wanted to imply a GUI without anything specifically branded.
On Mastodon I follow a bot that posts screenshots of old Mac Kaleidoscope schemes and the creativity on display both leaves me in awe and makes me sad that no modern windowing system can hold a candle to it. With Kaleidoscope there were no rules. You could do a hacker OS[0], or game UI[1], or titlebars on the left[2] or underneath[3], or non-rectangular and chrome[4], or made of denim[5], and those are just a few of the thousands of wildly different themes[6].
Nothing on modern Linux comes close. Even if you seek out third party themes all you find are dozens of minor permutations on popular flat themes like Material and Nord. It's so dull.
[0]: https://macthemes.garden/themes/24c0f39f11eb-net-ghost/ [1]: https://macthemes.garden/themes/8f7b145a33f3-Millenniac [2]: https://macthemes.garden/themes/95203ae3bfe0-my-sidewyas-os/ [3]: https://macthemes.garden/themes/6da656d65263-modulus/ [4]: https://macthemes.garden/themes/7e008718df3c-dt-chromxium-tw... [5]: https://macthemes.garden/themes/0305d1075f5e-dt-denim/ [6]: https://macthemes.garden/
See: https://gist.github.com/ThomasAdam/5377540b3025f7f04735d96ee...
There's hope due to the recent x11 fork, xlibre. They intend to keep x11 support ongoing
Fvwm people are very smart and have been developing fvwm for longer than Linux have been around. From what I understand and have read, bring fvwm or creating a fvwm clone on Wayland is near impossible. Far too much work.
So we will really end up with "pigs" like Gnome3, KDE or a slew of tiling environments. None of the cool WMs like Windowmaker, fvwm, dluxbox, twm, ctwm, vtwm ....
From the Wayland devs' PoV, mainstreaming Wayland successfully shifted responsibility for doing most of the heavy lifting in the graphics layer from the neglected X-Windows project to the well-established KDE and GNOME. The state of wlroots and the ecosystem of personal WM projects is unavoidable collateral damage.
For an individual developer, perhaps the thing to do is take a page out of bbLean's [1] bag of tricks and implement your WM on top of one of the big two desktop environments.
https://bb4win.sourceforge.net/bblean/
Deleted Comment
Even accounting for wlroots, you're not exactly just running sed on a glob. And unfortunately, wayland didn't actually fix X's complexity problem. Arcan did, but we're not allowed to have nice things because Redhat has no taste.
(Incidentally, I love the way that my Xmonad setup works, even though I don't know Haskell. I tried using an i3wm setup at work for maybe a year, but every evening coming back to Xmonad on my personal laptop felt like a boost of agility. I guess, if I were wealthy and wanted to move to Wayland, I would seriously consider either doing the work myself or paying someone to.)
For those unaware, though I doubt you're reading this thread if so, I want n desktops that are shared between all screens, not desktops _assigned_ to particular screens. If I summon a desktop on screen 1 and it's currently displayed on screen 2, they should swap.
Ideally also does layouts kind of like xmonad too, not "here's a tiling tree structure and a bunch of commands to manually manage it".
https://docs.qtile.org/en/stable/manual/ref/layouts.html#mon...
At least i3's (and I imagine sway's) config is sufficiently flexible for that. Here's a shell function that brings the workspace you specify to your current output:
You can turn that into an executable and have it be called through a keybinding.This is due to a limitation of X11 where a window can't be in two places at once. In theory, Wayland compositors can duplicate the desktop (at the cost of, like, not letting applications know their own window coordinates which seems pretty bad).
I'm pretty sure Wayland applications already don't know their coordinates.
I haven't managed to get it quite right though. For example Sway doesn't seem to be willing to move a workspace to a different monitor if it is empty.
Deleted Comment
I think the closest thing that could get most of the way there is https://github.com/domferr/tilingshell/
https://docs.qtile.org/en/stable/manual/ref/layouts.html#mon...
The packages I install are: xmonad libghc-xmonad-extras-dev gnome-flashback gnome-panel
(plus suckless-tools and xmobar)
That should give you a login option for "GNOME Flashback (Xmonad)"
I recall there were a couple of hacks necessary to show the Gnome Panel:
gsettings set org.gnome.gnome-flashback root-background true
gsettings set org.gnome.gnome-flashback desktop false
and then the panels you can hide or remove per your preference
I'm a long-time Xmonad user. Currently, I'm using Ubuntu 25.04, having upgraded to new non-LTS releases every six months, on two computers running Xmonad. I haven't run into any problems.