> It is the status quo on GNOME.
This is your problem, and GNOME's too: GNOME doesn't own the Linux desktop. The status quo on GNOME should not drive protocol standards that impact the entire Linux desktop ecosystem. The protocol standards should be driven by the needs of the larger ecosystem. I'm not saying the needs of GNOME are unimportant. They are just not the end of what needs to be considered when developing this kind of thing.
This point here is more important than this entire argument about CSD. The rest can be discarded. Why should GNOME's fairly isolated status quo be the burden of every application or app toolkit developer? The inverse is a burden on the compositor. There are far more apps and app developers, and even toolkits, than there will ever be Wayland compositors.
> It works fine. Why would it be a problem? It's not different from adding any other library dependency to a flatpak.
Because you will get a vendored copy of libdecor. In a runtime like the Steam runtime, you might wind up attempting to load a version of libdecor linked against an incompatible libc if you try to use the system version. This is not a problem that would occur if a protocol were used instead.
> 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.
libdecor also has the potential to create other problems. This is just pointing out that software is hard. Yes, I get that.
If GNOME cared about what experience was good for the user, they would have cared about the fact that the Wayland compositor they shipped into production runs many games with missing window borders because of their own initiatives and sway within the Wayland ecosystem. The user experience in GNOME is genuinely worse due to this strange insistence on moving a problem from one location to another.
> 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.
Not every application needs a UI toolkit. There are also a lot of UI toolkits. Now many of them struggle with the fairly unimpressive task of displaying a window with reasonable looking borders. That's not a good user experience, and it's certainly not a good developer experience.
I really do have a lot of opinions regarding what you are saying, but I'm honestly running out of steam on replying to each point blow-for-blow because it feels like I already expressed my point and the reply is just what I said but inverted.