However the radically different architecture of Wayland may necessitate a rewrite well beyond what the maintainers of a window manager feel is easy.
Even accounting for wlroots, you're not exactly just running sed on a glob. And unfortunately, wayland didn't actually fix X's complexity problem. Arcan did, but we're not allowed to have nice things because Redhat has no taste.
They're suggesting that every Wayland window manager has to implement its own compositor. Because that is how Wayland works. There are no window managers, only compositors, and if you want custom window management, you write your own compositor.
Comments
There are libraries like wlroots (C) and Smithay (Rust) to be able to more easily create your own wayland compositor
However the radically different architecture of Wayland may necessitate a rewrite well beyond what the maintainers of a window manager feel is easy.
Even accounting for wlroots, you're not exactly just running sed on a glob. And unfortunately, wayland didn't actually fix X's complexity problem. Arcan did, but we're not allowed to have nice things because Redhat has no taste.
The libraries help, but it's still a bigger job than a window manager was
Are you suggesting every application should implement its own compositor?
This style of engagement is so off-putting.
Help me out then. What value, to a window manager developer, is there in making it easier to create your own wayland compositor?
To use wayland?
They're suggesting that every Wayland window manager has to implement its own compositor. Because that is how Wayland works. There are no window managers, only compositors, and if you want custom window management, you write your own compositor.
And what value to window manager developers get from being able to implement its own compositor?