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.
> 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.
Not in Wayland, no. The only boundary is between the client and compositor. With X there is a boundary between the client and server, and between the server, wm, and compositor.
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)
While it's not mandated, as I pointed out ("There's nothing inherent stopping the addition of extensions to allow the same split as in X"), I'm not aware of a single Wayland compositor for which it isn't true. If there is one, I'd love to hear about it.
Yikes. This is a great illustration of why I've steered clear of Wayland, when even with wlroots you end up with that much code to do that little.
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.
That's an interesting approach. It'd be easy enough to do for my own X apps as I'd mostly need to flush some caches and recreate windows and pixmaps. It'd generally be terminals that are most painful to use, and the terminal would be nearly trivial since they keep an buffer of the text anyway and so can trivially recreate the view once they succeed in reopening the window (the font rendering caches glyphs, and caches graphics contexts; just flushing those caches client side would make the terminal recreate them as needed)
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 ;)
> It'd generally be terminals that are most painful to use, and the terminal would be nearly trivial since they keep an buffer of the text anyway and so can trivially recreate the view once they succeed in reopening the window
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).
i3wm, bspwm, etc, and many others have provided APIs like that "forever". The problem is that they're async and sit "besides" or "after" the actual window management.
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.
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.