It can never really look or behave natively on Gnome since client-side decorations are more than a boarder and window buttons. It's also about having an integrated toolbar and more draggable area.
Don't you have this completely backwards? If I want my application to have special custom decorations, then it makes sense for my application to draw the decorations. But if I want my application to have the standard decorations of the system, why should I want my application draw them?
GNOME supporting SSDs would not diminish the ability of GNOME's applications to use CSDs. So objections about the utility of CSDs imply a false dichotomy.
The solution there would be to fix gtk to support vulkan, and to fix libdecoration so it looks better.
>I consider them to be quite the jerks indeed.
Please stop, this is assuming bad faith and it's not helpful. The mutter bug tracker is an inappropriate place to give this unrelated feedback about this, when those issues you talked about are problems in libgtk and libdecoration. That's why the issue is closed. If you are just going to throw flames and don't want to discuss real technical solutions to the problem then I'm going to end the conversation.
When is it appropriate to assume bad faith? I think assuming bad faith can be very helpful if only because it tells you what to not support or depend on.
Saying "you have to use our library and also fix it for free" is a dick move regardless.
>I think assuming bad faith can be very helpful if only because it tells you what to not support or depend on.
I'm sorry I don't get what you're saying. You can decide not to support or depend on something without (incorrectly) assuming bad faith. This stuff is all open source, nobody can force you to use a library that you're not interested to use.
That's not strictly speaking true, especially when politics and money get involved. Unless you're using a very loose definition of "force" which doesn't include any kind of network effect at all.