Hot take: X11's separation of the window manager and the display server is really good and Wayland is taking a step backward by combining the two.
If KWin crashes or I need to restart it, I shouldn't lose EVERYTHING.
And yes, this does happen.
@IceWolf linux has had a few things in recent years that have just been "we must replace this because it's old. works perfectly fine, but it's old"
@patterfloof Honestly we have no strong opinions on systemd. Like it as a service manager like Mac's launchd, don't like how it's trying to do /everything/ (systemd-boot? systemd-resolved?).
@IceWolf In fairness, the WM + display server can be separated in Wayland. There's nothing intrinsic to wayland to prevent that.
Wayland is just a protocol, not an application. It's down to the compositor implementor's decision whether the WM and display server run as separate process. It just happens to be simpler to implement them together.
@j Oh huh, had no clue you /could/ separate them like that!
Someone should write a display server everyone can plug window managers into. 3
@IceWolf The trouble there is that you now have to decide on a protocol that those WM's speak with the display server, and then need to get people to implement it.
@squeakypancakes Ready for general usage or not! My issue is with the /design/.
(We've never tried KWayland, but don't want to run into this situation seeing as we sometimes have to restart kwin on X.)
@IceWolf Another huge issue with wayland is that you can't implement something for all of wayland (for instance, a screenshot/screen recording tool), you have to implement it for each and every windowing kit (GTK, QT, wlroots, whatever). It seems like the entirely wrong method of doing things, isn't the point of a display server to create these sort of abstractions? At that point you might as well have separate “QT Display Server” and “GTK Display Server” since stuff for a QT-based DE is incompatible with a GTK-based DE under Wayland anyways.