Could we please have a comment about why this is an X11 WM rather than a Wayland compositor? Technical issues or a stylistic choice?

Outside of any personal preferences of author, Wayland compositors are just more complex. Even with availability of libraries like wlroots.

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.

Because a window manager on X is roughly the equivalent of a Gnome extension. That’s just a design question where we draw boundaries.

It's an interesting question...

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)

That’s not true in this respect. This all is just an implementation detail, not mandated one way or another by Wayland.

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.

TinyWM for wlroots is also less than 1,000 LoC. ( https://github.com/swaywm/wlroots/blob/master/tinywl/tinywl.... )

> I can restart my wm without exiting my X session

Sway also has a "reload" feature that preserves all open applications.

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.

FWIW, there is some effort to let QT applications survive compositor crash in a way that would be even more resilient than with X11: https://www.phoronix.com/news/Qt-Wayland-Compositor-Restart

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

I wouldn't care either if I wasn't contemplating at some point getting my hands dirty with that layer too ;)

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

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.

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.

I raise with a wayland client in crystal: https://github.com/yxhuvud/wayland_client

Very basic though, you'd have to provide your own functionality to print any text..

I see C in there; that's cheating ;) (my WM uses a pure-Ruby X11 client library - there are no external C dependencies other than those of the Ruby implementation itself).

Though I sympathise - the sheer amount of effort to work with these, be it X11 or Wayland, is really annoying; the pure Ruby X11 gem I use is more lines of code than the window manager itself...

Yeah, I link against C libs because reimplementing the protocol seemed like a pain in the ass. The prevailing strategy seems to be to generate code based on XML protocol specs, and I'd prefer to avoid that crap. That would probably be less painful in Ruby as then the code could just be generated at runtime based on the XML.

Also since all the prepackaged wayland libs are heavy users of functions declared as `static inline` I have to create shims for those as they are not linkable. That part is a pain in the ass but pretty simple to resolve :)

And yeah, there is so much to set up just to get a bare minimum going. I guess that would be true in X11 too.

Parsing all those XML specs at runtime seems really slow and wasteful, surely this there’s a better way, no?

The code generation is certainly a build step. This kind of code generation is common for interfaces defined outside of a project's programming language.

Oh, I absolutely don't judge you for those. Frankly part of the reason I went for a pure Ruby version instead of xlib was that the Xlib bindings for Ruby are also in an awful state, and someone else had done enough of the job on the pure Ruby bindings that it felt like it was doable incrementally as I needed various calls and not much worse than wrapping Xlib or xcb.

I like that there are no other dependencies, but I'd have sacrificed that if it was sufficiently much easier than the route I ended up taking (e.g. my terminal did start out linking to Xlib and using a tiny C extension; it's since been ripped out in favour of the pure Ruby bindings, since why not now that it's available, but it was a perfectly ok solution to start with).