Xmonad Seeking Help for Wayland Port (2023)

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.

There's hope due to the recent x11 fork, xlibre. They intend to keep x11 support ongoing

See: https://gist.github.com/ThomasAdam/5377540b3025f7f04735d96ee...

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.

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

https://docs.qtile.org/en/stable/manual/ref/layouts.html#mon...

This gives you the advantage of Wayland's modern display stack and no legacy Xorg code while still running a classic X11 window manager.

The main downside is you have to run all X11-compatible apps, it's unable to manage any Wayland-native applications. But, X11 apps aren't going away any time soon, just the display server.

That doesn't mean anything. xmonad is not broken afaik, still in use everywhere and wayland, which is just a protocol, has no power over it.

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.

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

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:

  i3_bring_workspace_to_focused_output() {
    local workspace="$1"
    i3 "
      workspace $workspace 
      move workspace to output $(
        i3-msg -t get_workspaces |
        jq -r '.[]|select(.focused).output'
      )
    "
  }

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.

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

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

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.