There was a time I'd absolutely have loved something like that (and had all the window effects turned on when the first compositors started arriving) and it looks very cool, but other than translucency I've progressively stripped back everything.
I'll never try to compete with something like that on either effects or features. I might add some very minor eye candy. But that's fine - one of the things I've always loved about the Linux/Unix desktop is how you can get everything from the most minimalist to the effects-laden, and I've used wm's pretty much everywhere on that spectrum myself too over the years.
I sympathise re: drivers - that or the browsers finally abandoning X would be the only things that'd give me enough reason to switch. But I'd be more likely to switch if I get around to scratching the itch of yet another homegrown minimalist step down the stack... (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 - I'm resisting that urge for now because it'd be a massive time-suck)
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)
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.
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.
If X dies, I assume we’re going to end up with Javascript or Wasm frontends to everything.
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`"`
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...