[vidarh]

I think my issue is that there shouldn't be a need for this proliferation of compositors. Wlroots is making that slightly less ridiculous, but wlroots itself is mostly necessary because nobody has bothered creating a WM extension for the Wayland protocol.

I'm not excited. There's no reason we should need dozens of compositors that are mostly identical apart from code that could easily live in a separate process.

That wlroots is getting better at making it easier to build a compositor is a poor bandaid from just removing the need to build a compositor at all.

It's one of many examples of Wayland throwing the baby out with the bath water.

[42jd]

I’m not sure I follow. Is your issue with Wayland that it’s not like x11 with a separate server and window manager? Someone can come along and write that in the future if that’s your preference.

As Wayland is just a protocol itself, the client doesn’t care how it’s implemented. Thus I see Wayland providing the extreme flexibility to implement its protocols how you see fit. Right now wlroots makes it easiest but if in a few years another implementation proves to be better, all those client programs aren’t going to stop working. For now the scene graph allows a whole bunch of compositors/window managers to be easily written that replace x11 ones. And better designs can be further iterated.

[vidarh]

Yes. My point above is that one of the barriers to replacing X is that the barrier to writing a compositor for Wayland is far higher than the barrier to writing a window manager for X. And while wlroots is slowly addressing that you're still stuck with the issue that wlroots requires far larger bindings to other languages for example, than what is required to write a WM for X, and is becoming a larger and larger dependency, even as most wm's only want to customise a tiny portion of the functionality of other compositors.

Until there is a compositor offering the same ease, either a bunch of WM's people use and care about won't get an equivalent for Wayland, or it will take a lot more time and effort.

As it is, for example, I'm not moving to Wayland before there's a drop-in replacement for bspwm. River seems to be close-ish to being able to offer something like that, but the benefits of Wayland do not really matter to me and so I have no interest in investing time in replacing bspwm for minimal gain.

> As Wayland is just a protocol itself, the client doesn’t care how it’s implemented. Thus I see Wayland providing the extreme flexibility to implement its protocols how you see fit.

This is true for X11 as well. X11 is just a protocol. But in practice we ended up with a small set of implementations exactly because the pain of implementation was too high, and even most separate servers (e.g. Xephyr for example, or, in fact Xwayland) were often based on Xorg the way many Wayland compositors are based on wlroots.

But that is with the APIs allowing out of process WMs. For Wayland the lack of a WM protocol means you can't avoid a higher proliferation of compositors until someone adds such an API, and it'll hold back development by making a lot of people spend time duplicating compositor code for no good reason.

> For now the scene graph allows a whole bunch of compositors/window managers to be easily written that replace x11 ones. And better designs can be further iterated.

It's great that it's getting easier, but the point is this is the "wrong order" - if you have even a fairly basic WM API very few WMs will care about the scene graph at all. It's like people are intent on ignoring the lessons of what actually worked well with X.

It's really not my problem - I'll stay on Xorg until Wayland is more suitable, however many years that might take. But anyone who cares about Wayland ought to take seriously that the proliferation of compositors will become a nightmare, whether or not more and more of them depend on wlroots, as it means more and more packages to rebuild, test and distribute whenever there are wlroot fixes, for example, for very little gain vs. simply moving the bits that will differ between wm's out of process.