Wayland as a protocol was designed around CSDs, protocols for SSDs came years later
Having the client control the CSDs simplifiies things for the compositor and apps
The compositor has less things to implement and test
Modern apps tend to prefer CSDs anyway since it provides more flexibility, very common on MacOS and Windows
It’s difficult to coordinate things between the client and compositor.
Something that annoys me about KDE is that they do this headerbar look where the top part of the application will match the color of the the titlebar. However, the top part of the application is drawn by the application and the titlebar is drawn by the compositor. But when the color changes (such as going from unfocused to focused), they do not update at the same time, so for a frame or few the top part of the application is a different color than the titlebar. That wouldn’t happen under CSDs.
Wayland as a protocol was designed around CSDs, protocols for SSDs came years later
That’s not an argument for anything. The core protocol isn’t useful on its own, you always need extensions that came later to even create a window. As another example, Wayland as a protocol was designed around shared memory buffers, protocols for hardware acceleration came later. Doesn’t mean you’re supposed to leave that out.
Modern apps tend to prefer CSDs anyway since it provides more flexibility, very common on MacOS and Windows
That too is not an argument for not implementing what a ton of apps need.
MacOS and Windows don’t do the same sort of CSD as Gnome FYI, it’s more of a hybrid approach, where parts of the decoration are rendered by the system and parts by the app.
It’s difficult to coordinate things between the client and compositor.
That too isn’t relevant, libdecor doesn’t coordinate shit either. And if you want to (which is being looked into), you can absolutely sync things with SSD too.
The actual and only reason Gnome doesn’t support SSD is that they think CSD is a “better architecture”.
The point 2.1 “less to implement in the compositor” doesn’t apply, because for xwayland go work (which is intended to stay around for the foreseeable future) mutter still needs to implement SSD, it’s only skipping on implementing the Wayland SSD protocols.
Points 1 and 2.2 are not strong points. “We do <thing > because we always did before <thing 2>” is not a good point. For example, after all, we always used X10 before Wayland, and we always did implicit sync before last year. And compositor shouldn’t limit programming styles, they should support as many things as possible, and let the application decide their programming design. Plus, most modern applications on windows and macos embed a copy of chrome to display a single offline Web page, but I don’t see you suggesting we replace compositors with browsers.
Point 2.3 is also weak because most of the things a compositor does are already hard, but they implement them because it makes the experience better. If something is hard, it just means it will be worked on more. Take a look at explicit sync, it took like 4 years to be rolled out, but it was necessary and got implemented.
I’ll give you point 2.3.1… in general I think KDE looks pretty bad, and gnome is really more polished in many aspects. Unfortunately I really prefer the KDE workflow on big screens (but gnome on laptops).
“We do <thing > because we always did before <thing 2>” is not a good point
I didn’t mean it in a “this is better way”. I’m just saying that Wayland was designed around the idea of client side decorations, not server side decorations. Gnome has stuck to the more purist vision of Wayland, which makes sense since I believe they were its biggest proponent.
yeah, but the point of a platform are the applications it supports, you don’t want to be The King of Nothing. If even after buying into wayland, applications still work bad on gnome because they expect to get support for X, than gnome needs X or to give a better option (better for the applications, not just according to themselves).
The for argument is basically the following
That’s not an argument for anything. The core protocol isn’t useful on its own, you always need extensions that came later to even create a window. As another example, Wayland as a protocol was designed around shared memory buffers, protocols for hardware acceleration came later. Doesn’t mean you’re supposed to leave that out.
That too is not an argument for not implementing what a ton of apps need.
MacOS and Windows don’t do the same sort of CSD as Gnome FYI, it’s more of a hybrid approach, where parts of the decoration are rendered by the system and parts by the app.
That too isn’t relevant, libdecor doesn’t coordinate shit either. And if you want to (which is being looked into), you can absolutely sync things with SSD too.
The actual and only reason Gnome doesn’t support SSD is that they think CSD is a “better architecture”.
The point 2.1 “less to implement in the compositor” doesn’t apply, because for xwayland go work (which is intended to stay around for the foreseeable future) mutter still needs to implement SSD, it’s only skipping on implementing the Wayland SSD protocols.
Points 1 and 2.2 are not strong points. “We do <thing > because we always did before <thing 2>” is not a good point. For example, after all, we always used X10 before Wayland, and we always did implicit sync before last year. And compositor shouldn’t limit programming styles, they should support as many things as possible, and let the application decide their programming design. Plus, most modern applications on windows and macos embed a copy of chrome to display a single offline Web page, but I don’t see you suggesting we replace compositors with browsers.
Point 2.3 is also weak because most of the things a compositor does are already hard, but they implement them because it makes the experience better. If something is hard, it just means it will be worked on more. Take a look at explicit sync, it took like 4 years to be rolled out, but it was necessary and got implemented.
I’ll give you point 2.3.1… in general I think KDE looks pretty bad, and gnome is really more polished in many aspects. Unfortunately I really prefer the KDE workflow on big screens (but gnome on laptops).
That can be dropped eventually too. Compositors like Niri don’t implement Xwayland support directly, and instead use Xwayland Satellite.
PING. Commenting just for the notification. I edited to respond to the other points but in the meantime you had already answered.
I didn’t mean it in a “this is better way”. I’m just saying that Wayland was designed around the idea of client side decorations, not server side decorations. Gnome has stuck to the more purist vision of Wayland, which makes sense since I believe they were its biggest proponent.
yeah, but the point of a platform are the applications it supports, you don’t want to be The King of Nothing. If even after buying into wayland, applications still work bad on gnome because they expect to get support for X, than gnome needs X or to give a better option (better for the applications, not just according to themselves).