After all, a Wayland WM is not just a WM, it also has to run and handle display server including talking with HW if you want any sensible performance.
Writing a Wayland compositor from scratch means writing the whole display server. Wlroots readme describes it as "about 60,000 lines of code you were going to write anyway".
For comparison my wm is <1k lines.
So they're not equivalent - writing a Wayland compositor from scratch is more like writing the whole X server first, before even starting the WM.
I could use wlroots or another compositor as a starting point. I did look at it, but I'm still on X, and have no compelling reason to switch. Yet, anyway, and that adds to the "cost" for me in terms of disruption.
Where I could translate TinyWM into a few dozen lines of Ruby in a couple of hours and switch to actually using it and build from there, and "just" suffer some nuisance that I can slowly chip away at when I have time, even getting a basic wlroots binding + minimal compositor running seemed like a far more complex project.
I'm itching to figure out how to eat my way further down the stack, but I can't justify spending time on it unless I see a viable way of doing it (relatively) piecemeal.
E.g. I can restart my wm without exiting my X session, and so without losing any open applications. That gets far more disruptive for replacing the X server (whether by another X server or a Wayland compositor), and also allows for a far faster cycle - I can spot a problem, fix it, restart the WM and keep working without having to close everything...
I think if I was to do a Waylabd compositor, a first step would be to put things like window management beyond an IPC boundary, just like with X.
Isn't that already the case, by protocol definition? At least compositor and clients talk to each other over a pipe of some sort. It is actually a bit problematic because the way it is done put noticeable restrictions on both sides on processing things in time, because if it is full then shit hit the fan.
With Wayland the compositor serves the same function as both the X server, wm, and compositor in one. There's nothing inherent stopping the addition of extensions to allow the same split as in X (but the server/compositor split probably wouldn't be worth keeping - the WM is easier to split out because it's far less latency sensitive)
> I can restart my wm without exiting my X session
Sway also has a "reload" feature that preserves all open applications.
TinyWM for X is 50 lines.
> Sway also has a "reload" feature that preserves all open applications.
As far as I understand, sway's reload just reloads the configuration. If Sway crashes, or you kill Sway's process, there's nothing left holding the sockets to the clients open, or managing the display - that's equivalent to killing the X server, not the wm.
With an X wm, as long as your x session isn't set up to quit when the wm quits, you can brutally shut down the wm, or it can crash, and the windows stay open, and you can restart your wm - or start another wm entirely - without losing any windows.
Of course, that's a new feature they're working on, only helps QT apps, and requires the toolkit to track state (and by the same virtue, looks like it would have worked fine with X11 if they wanted to). So this is more of an interesting related tidbit rather than a disagreement.
Whether X or Wayland it would certainly make experimenting less painful. Browsers doesn't matter that much given they're reasonably decent at restoring.
(Another option there is xpra - "screen for X")
Fewer and fewer reasons not to start writing an X server ;)
The cheap version of this is just using tmux/screen, but yeah honestly I suspect a lot of programs are easy to make recreate their GUI state if you care to bother, it's just that not everyone does (or should; it's a trade off and display servers aren't usually that crashy).
Afaik river does something in that direction https://github.com/riverwm/river
> Dynamic layouts generated by external, user-written executables. A default rivertile layout generator is provided.
> Scriptable configuration and control through a custom Wayland protocol and separate riverctl binary implementing it.
E.g. one of the things I disliked about bspwm was that while I could get a feed of events and act on them, I couldn't intercept and modify or reject requests, so e.g. when a new window opened, bspwm would place it, and issue an event, and before my script could reconfigure the window it'd already be visible, so to get a floating desktop the way I wanted I ended up with windows flashing up in one location and then moving.
Put another way: The plethora of Wayland compositors is a strong demonstration of how these compositors don't give sufficient control via their external APIs, or people would write window managers for one or more of those compositors instead of writing more compositors.