So I realize this is an issue that seems to be somewhat contested. I’ve heard people are upset that Wayland will have client-side window decoration, and I happen to agree. It doesn’t sound like a good idea at all. But isn’t one of the benefits of switching to Wayland that it is more flexible? I don’t see why a Wayland compositor couldn’t do the window decorations itself? For example, compiz does it’s own window decorations already (albeit in a different process). If compiz will be “ported” to work with Wayland, which I understand it will, then we still haven’t lost window decoration, right?
Share
Wayland could do decorations in the compositor, sure. But the compositor and the app’s UI toolkit have to agree on who’s doing decorations (or else you get double-decorated), and I think people just prefer to have the toolkit do it in order to get more design flexibility. Changing window system is an opportunity to change this decision.
If you have everything drawn in the same codebase then you can mix-and-match visual and functional details more easily instead of having some details inherently belong in an “outer frame” and others inside the window. That allows a Google Chrome type of look or allows a theme with a continuous gradient including titlebar and app background or whatever, things like that.
You could, I think, still support UI implemented by the compositor for forcing an app to move, such as Alt+click, forcing an app to close, etc.
Anyway there are definitely some threads on the net hashing out the pros and cons in more detail, I guess that’s a tangent.