I am eyeing river wm. Because it has pluggable layout manager and controller via custom wayland protocols. Which means I can implement just those parts in my favourite lang to scratch the itch. Kudos to you going for the whole wm :)

An X11 wm is childs play compared to a Wayland compositor. I have been eyeing River and various other Wayland options too, in case I find myself compelled to switch to Wayland at some point, but the sheer complexity of the Wayland side has held me back.

Given that X11 is going away, the server (except for Xwayland) is unmaintained, and in a few years modern software just won't support it at all... the sooner you switch, the better.

There are plenty of Wayland compositors that supports X backends, so app support for X is moot because 1) most of the apps I run are my own - the only thing I really depend on is browsers, and 2) once Chrome and Firefox abandons X entirely, and no other browsers based on their engines supports X, there are options to run them with a Wayland compositor with an X backend in "kiosk mode" that basically gives them a single window just like before.

So that leaves how long I will have a working X server, and frankly I suspect I'll have ended up writing a display server years before that becomes an issue (whether that'll be X or Wayland or a mix, who knows, but I doubt I'll be able to resist very long).

It's just not a concern that's anywhere near the top of my list (or the top 100 of my list)

You can run an X window manager on a Wayland compositor, as you said the problem is when programs stop running on X at all.

Well, no, even that isn't a problem, because you can run a Wayland compositor on X too.

E.g. I tested, and Firefox runs fine in Weston in kiosk mode w/X as the backend.

So even when Firefox drops X, it will still run on X as long as a single compositor with an X backend is still running.

Great, my Firefox on Weston on i3 on XWayland on Gamescope idea is a go (when I get around to implementing it).

The funny thing is in theory it might work reasonably well, as Weston at least uses the DRI3 extension to get the underlying X server to just pass the DRI filedescriptors up, so if the rest also supports it you'd in theory just get a game of passing the fds through multiple layers and then the client doing direct rendering via shared memory. Though in practice there's of course plenty of things that might go wrong.

I go back and forth on this kind of thing; if the better option really is EOL, is it better to keep using it until it actually breaks, or is it better to take the pain up front? I don't have an actual answer in the general case, but on the bright side Xorg is still not dead even though the pro-Wayland crowd says so at every single opportunity; it has a nonzero number of maintainers, gets commits on a slow but regular cadence, and appears likely to continue working for the forseeable future. If we assume for a moment that the X server will really actually die when Red Hat stops maintaining it (questionable; the BSDs appear more attached to it than RH), that merely gives us until the end of RHEL 9 around 2032, which is far enough away that I feel comfortable not worrying about it.

Also, as sibling comment points out, a simple solution exists in the form of rootful xwayland; we can keep a working X11 environment and just swap out the actual rendering layer.

Or put differently: "Given that X11 is going away, the server (except for Xwayland) is unmaintained," just isn't true, and even if it was it wouldn't necessarily justify the claims you make on that basis.

A modern app needs to be able to run in datacenters and render on my GPU (whether desktop, laptop, tablet, or phone). That’s how and where our capacity is evolving.

If X dies, I assume we’re going to end up with Javascript or Wasm frontends to everything.

Maybe you'll end up with those frontends. I won't. Part of the point for me with my rewrites of essential parts of my computing experience is that I control an increasing proportion of my stack, and that proportion will keep increasing.

> It looks great, but to me this is pretty much the opposite of what I want to use - the demo video at least is so busy, and full of transitions and other distractions.

They are optional: you can make them last 100 ms, or just remove them.

Such "eyecandy" enable new uses: for example, all my windows are full screen, on they own desktop. No titlebar, no nothing because that's a waste of space. A quick animation when I change desktop helps me keep a mental map.

Also, hyprland great strength is it makes it not just possible but very easy to have a keyboard-centric workflow: you mix the tiling window manager strength with the traditional "windows" you can move with your mouse. F1 gets me to desktop 1 where my terminals live, Shift+F1 can send whatever window I'm using on desktop 1 to share it with the terminal for a while, Win + Left lets me adjust the tiling and Win + J lets me change from horizontal to vertical tiling

Last year was my year of Linux on the desktop, and I think I'll stay on Linux if only for hyprland.

> I have a weird urge to write a Frankencompositor that supports Wayland clients and enough to support an out-of-band X11 style window manager and the brutally insecure X11 style event snooping and injection; partly because it'd really irritate some Wayland purists

Check hyprctl: you can get a list of windows. With hyprland key bindings + basic shell scripts using hyprctl and ydotool to send key or mouse events, it's already possible!

From one of my simple scripts: `hyprctl dispatch focuswindow $WINDOW_ID | wl-paste | wl-copy -c` replaced `ydotool type "`wl-paste`"`

> They are optional: you can make them last 100 ms, or just remove them.

I'd rather have a codebase that doesn't have them so that I can work on a codebase that is tiny and focused on what I want when I want to change something. And I would need to make changes to the code base for it to suit me - see below.

> Also, hyprland great strength is it makes it not just possible but very easy to have a keyboard-centric workflow:

I already have a keyboard-centric workflow that does the things you list. There's nothing new in any of that. I have a floating desktop; I can move and resize them with the keyboard. I can move the tiling windows with the keyboard. I can swap individual windows, or swap entire subtrees, or flip their direction. All of that is trivial on almost any tiling wm.

> Check hyprctl: you can get a list of windows. With hyprland key bindings + basic shell scripts using hyprctl and ydotool to send key or mouse events, it's already possible!

This has the same flaw that was one of the reasons why I ditched bspwm - it allows getting events from it's 2nd socket - but not to intercept requests and being able to rewrite and choose whether to honor the requests or not. It does not have the flexibility I had in mind.

It has a lot of great functionality, but none of the things that I care about provide more than I already have, and some would set me back to the point I'd have to rewrite stuff again - and frankly just the build process for hyprland makes me break out in hives...