> Wayland: It's becoming increasingly clear that the days of X11 are over and some Linux distros are already switching to Wayland. We're committed to keeping xmonad on X11 stable and alive as long as necessary, but if time allows, we should explore the Wayland ecosystem and figure out what it means for xmonad. Do we go all in on waymonad? Shall we try to keep xmonad a pluggable window-management component for another Wayland compositor? Honestly, we don't know yet. This one is a bit of a stretch goal: we might need more than one person full-time to actually make this happen.
Elsewhere in this thread, I wrote about some concerns I have about waymonad and xmonad on Wayland in general: https://news.ycombinator.com/item?id=28796909 The gist of it is that I'd like to keep the compositor and WM separate, because a) xmonad is reconfigured by compiling/restarting, b) I don't think the Haskell runtime is good for handling input and presenting frames, c) I don't want to maintain a compositor :-).
Hello, long time user first time commenter. ;) Just came here to say that because of this post I went and sponsored XMonad. I want it to survive for decades to come.
Oh, that’s good news. I’ll have to follow along when there’s more progress.
I am surprised, at least somewhat (and as someone with very little Haskell experience,) to hear Haskell may not be a good fit for the compositing bits. That’s a bit disappointing because the stability of Xmonad is probably a big selling point, and even more important with a Wayland compositor, but most of the Wayland compositors have quite a lot of C code. Maybe the same will wind up being true of the compositing bits of the Wayland equivalent of Xmonad.
A slightly longer answer is in a bullet point on our fundraising page (https://github.com/sponsors/xmonad):
> Wayland: It's becoming increasingly clear that the days of X11 are over and some Linux distros are already switching to Wayland. We're committed to keeping xmonad on X11 stable and alive as long as necessary, but if time allows, we should explore the Wayland ecosystem and figure out what it means for xmonad. Do we go all in on waymonad? Shall we try to keep xmonad a pluggable window-management component for another Wayland compositor? Honestly, we don't know yet. This one is a bit of a stretch goal: we might need more than one person full-time to actually make this happen.
Elsewhere in this thread, I wrote about some concerns I have about waymonad and xmonad on Wayland in general: https://news.ycombinator.com/item?id=28796909 The gist of it is that I'd like to keep the compositor and WM separate, because a) xmonad is reconfigured by compiling/restarting, b) I don't think the Haskell runtime is good for handling input and presenting frames, c) I don't want to maintain a compositor :-).