Then don't offer that second option? You can also offer multiple border options within the toolkit.
>If you consider the user unbinding C-q from "quit" as broken because "the HIGs won't match" then I would have to say that I disagree.
That would be one keybind. Complex apps have many keybinds, it's not really feasible to expect every user to change them all to match whatever their setup is. You could provide this as an option if you really wanted but some applications won't bother with this.
>If the user wants to make "breaking" chances to my applications they should be free, especially since I don't believe that any big issues will be caused.
Again you could provide this as an option if you really wanted but this is a sub-par experience for the user to have to mess with this. What I see really complex cross-platform apps doing: they just decide which platforms they support and then provide different sets of keybinds for each of those platforms, no need for the user to have to re-configure hundreds of keybinds to match their setup.
>I guess if I go with gtk4 I would have to use a mix of gtk4+libdecor in order to have "native" borders in all WMs, is that correct?
No, you cannot use libdecor with GTK4 at this time because of technical limitations. GTK4 technically does support the kde server decoration protocol which is an older version of xdg-decoration. So that may already work if you're using a wayland server that supports it. Otherwise you could try to patch GTK4 to support xdg-decoration.
>What do you mean by "older apps"? Motif-era, gtk2-era, or gtk3-era?
I've noticed many apps that are built around the old-style desktop concepts of menus/toolbars/panels/dialogs don't play well with the extremely squashed resolutions that tiling window managers tend to put windows into. This is the same problem with trying to run those "native" apps on a Linux phone like the Librem, they just aren't designed to run at a small resolution.
>Well, yeah, because GNOME is not a WM :p
Sorry, what I mean is that GNOME includes its own WM and shell which is the only thing that it supports, and that is the only thing that GNOME developers usually test with. They have not supported alternate WMs in quite a while, as they have no reason to.
>By "going out of their way" I meant specifically the decision to implement CSD.
Well that's not true, you can see some of the motivations for using CSD here: https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
You may not agree with these motivations, but they were not done to make you miserable. Please don't assume bad faith.
>I just wish that they would play better with the other players (and well, the users).
I'm not sure what you mean, GNOME is its own platform. If you are not a user of that app platform then I don't see why it would matter to you.
>The point is that while xdg-decoration might be an optional extension in reality it is pretty much standard except in two WMs that require special handling.
There's no special handling, everything that is needed to support xdg-decoration is also needed to support those other WMs. Even with xdg-decoration, you still need to provide a fallback. Also, I believe Weston is another one that does not support it, and the Elementary compositor is likely not going to support it either.