From the app developer perspective it is the same though. A GNOME user will want their apps to have client-side GTK decorations because this is the way GNOME apps are built. It's the same as if that user was using a tiling WM and turned the client-side decoration setting to always on. You have to handle this if you are an app developer and want to support those platforms.
>I think, though, that pushing the responsibility to draw basic native borders onto the app is still not an ideal situation.
Well that's not what's happening, usually the responsibility falls on the toolkit. Libdecor exists to simplify the task for toolkits, apps should really not be linking against it directly unless they're something big like Blender that has enough resources to implement and maintain its own toolkit.
>I view CSD as a fad. I do not think it makes for better UIs, either from an aesthetic standpoint or a usability standpoint. Now that is just an opinion.
Ok that's fine for you if you feel that way, GNOME designers seemingly do not feel that way as it has become a central part of their design language.
>It’s kind of crazy that I have to even argue this, since if this wasn’t the case, there would have been absolutely no reason to have the CSD initiative since clearly it was the status quo. It was not. And the protocol standards be damned, it really still isn’t.
It is the status quo on GNOME.
>I still am not convinced linking to system libdecor is even a good idea, and I wonder how well this plays with containerized systems like flatpak.
It works fine. Why would it be a problem? It's not different from adding any other library dependency to a flatpak.
>There is really no question regarding xdg-decoration: when you’re on the protocol level, all of these problems disappear.
This isn't true, and it also has the potential to create other problems. What you are missing is that the protocol doesn't really matter, what matters is having a good experience for the user.
>But we are now years out from the CSD initiative and still today there are issues with apps and games that have no or broken borders in GNOME. GNOME developers, of course, blame the apps, and the app devs are all scratching their heads at why they have to deal with this new concern from a thing that doesn’t run well on their GPU anyways.
Those apps were totally broken on Wayland to begin with, Wayland did not even support borders at all before the KDE protocol and subsequent xdg-decoration which only happened a few years ago. So yes you could say is the app developer's fault, or more accurately it is the toolkit developer's fault for advertising Wayland support and yet having incomplete support for it. GNOME cannot fix app developer's apps for them, nor can KDE. And let me illustrate this again: even with xdg-decoration, even under KDE, all apps still have to implement fall-back decorations to be compliant with the spec. If your app is supposed to have borders and there is ever a situation when it has no borders then that app is broken as per the spec, you need to handle that case inside the app, not in the compositor.
>I’m very in support of Wayland, but this whole squabble was so easily avoided.
I disagree, there are real technical reasons why this wasn't done. KDE's implementation of this is also pretty complex and not suitable for all desktops to copy.
>I am not convinced, however, that this change has resulted in a better system overall. It just moved a bunch of complexity and ugliness over to app developers. So… thanks???
I don't agree with this either, the complexity and ugliness has moved to libdecor which gets used by the toolkit. App developers don't have to bother with the details, they just use a toolkit.