Hacker News new | ask | show | jobs
by djsumdog 2063 days ago
There are tiling window managers for Wayland. Sway is one that is meant to maintain configuration file comparability with i3. But yes, obscure tiling managers will need to be rewritten for Wayland.
2 comments

I'm looking at sway and it looks promising (although I wonder how it deals with the many weird corner cases that X11 tiling WMs have had decades to fix and work around) but Sway's home page linked to the wlroots project which is:

>[...] a modular basis for Sway and other Wayland compositors to build upon

I was curious to see what that looked like so I went on the github and the first sentence on the README is:

>Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 50,000 lines of code you were going to write anyway.

My jaw literally dropped when I read this. It seemed so wild that I actually cloned the repository and ran sloccount myself to check if there was a catch (there isn't, master is at 53k lines). My DWM is 3k lines and it's fully featured as far as I'm concerned.

I realize that it just pushes a lot of that functionality (and code) into X but at least it separates the concerns, my WM doesn't ship with half of the X11 source code as a hard dependency. Also X11 has been battle tested for literally decades by now, it's not a fast moving project (well, arguably it's quite the opposite, hence the very existence of this discussion).

I haven't looked very deeply at Wayland so I won't say that they're doing it wrong, maybe I'm just missing an important aspect, but the more I learn about it the more it feels like they've thrown the baby out with the bath water.

X11 can be hugely hacky at times and some of it is seriously outdated at the conceptual level, but it also does many things amazingly well, arguably better than any other mainstream desktop environment out there. It's an incredibly flexible, if a bit idiosyncratic system. Wayland seems to fix some of its flaws by introducing a brand new system that comes with its own set of drawbacks.

The more I learn about this, the more I start to think that there needs to be some kind of middleware library implementing all these missing features from Wayland that all Wayland compositors are going to to need anyway.

Then the compositors could just use this library instead of every one of them duplicating effort and coming up with their own mutually incompatible ways of doing things.

In fact, this library could even be protocol-agnostic, and be able to talk to both Wayland and X.

>The more I learn about this, the more I start to think that there needs to be some kind of middleware library implementing all these missing features from Wayland that all Wayland compositors are going to to need anyway.

>Then the compositors could just use this library instead of every one of them duplicating effort and coming up with their own mutually incompatible ways of doing things.

That's what wlroots is, except for...

>In fact, this library could even be protocol-agnostic, and be able to talk to both Wayland and X.

... because that's outside its scope. The point of the middleware is to interface with the wayland protocol. It's not "protocol-agnostic".

Wlroots is the middleware library. Other wayland tilling wm use it as well.
> dwl - dwm for Wayland

> dwl.c, 2000 LOC

https://github.com/djpohly/dwl

wlroots should be compared with X.Org Server, 370000 LOC

https://github.com/freedesktop/xorg-xserver

> My DWM is 3k lines and it's fully featured as far as I'm concerned.

For fairness, you should count the hundreds of thousands of LOC in Xorg as well. From that PoV, 50k might actually be pretty lean.

Rewritten and add compositor functionality.