>I’m just trying to explain to you how it works because you are saying things that are inaccurate to prove your point

I don't understand your explanation though, what you've described seems even worse, with needing to tie into the kernel to draw window decorations. So if you want different decorations, you need to install a kernel module or hack the kernel? I don't get it. Sorry if I don't get the specifics of Windows here but it's been a very long time since I did any hard-core Windows debugging and AFAIK most Windows developers are using a toolkit and are not making the raw NT kernel syscalls. But please correct me if I am still wrong here.

>for all its faults, is a hell of a lot better to use than GNOME in the opinion of many hardcore Linux users.

Honestly, I don't think anyone in the GNOME or KDE camps are interested in making a clone of Windows down to the kernel level. Sorry. I think if they wanted Windows, they would just use it.

>So no. It is not reasonable to ask applications to link to a canonical toolkit.

Yes it is because I was talking about the canonical toolkit for GNOME, not for Linux as a whole. If you don't want to support GNOME then don't link that toolkit. I really don't get what the concern here is.

>I don’t want my app to look like it’s running in VMWare Unity Mode on the majority of desktops

My experience with various Linux desktops for the last 15 years is that tons and tons of apps look like that. It's unavoidable because there are tons and tons of toolkits to choose from on Linux and none of them look or act the same. Sorry, what you want might just not be possible. At some point people who are using obscure and niche desktops have to accept that apps built for other desktops are going to look and act weird because not everyone has enough time to get everything working the right way on every obscure setup.

>This line of thinking requires Linux to be a cohesive platform like Windows or macOS, but it is not. GNOME is not an operating system. It’s not even a distribution of Linux.

I don't understand why you're saying this. I was talking about GNOME, not about Linux. Linux is obviously not a cohesive platform, if you thought of "Linux as a whole" you would also have to include Android and ChromeOS applications which would also look and act strange if you tried to run them in KDE or GNOME and vice versa.

>The problem you’re having is that you seem to have a distorted view of the ecosystem. There are tons of Wayland compositors just as there were X11 WMs — having all of them have libdecor plugins would be possible, but I fail to see how it is ideal in any way. The way I see it, a compositor that supports xdg-decoration is likely to have nice looking fallback borders, and one that does not is likely to show hideous GTK borders. It’s only a reasonable option to do the latter if the desktop environment truly prescribes nothing yet still expects window borders. However, I know of none that do this: tiling WMs don’t draw them at all, and other WMs generally have customizable window borders. The difference between libdecor and xdg-decoration is simple: one is a protocol level thing, and the other is some crap off to the side that people have to contribute to.

So I think you're confused as to what libdecor actually is and that's why it seems to you that my view is distorted. You've got it exactly backwards. You don't make a libdecor plugin for the compositor. You make a libdecor plugin for a toolkit. Libdecor is for client-side decorations, it has nothing to do with the compositor and compositor developers don't need to do anything to support it. If the compositor doesn't support xdg-decoration then it's up to the app to draw its borders. Yes a GTK app will fall back to GTK borders in that case, what else could it possibly fall back to? And BTW, GNOME has not supported user customizing the borders in quite a while. Only the app can customize the borders.

>Or you can just support xdg-decoration and get libdecor support for free. So why would anyone not unless they intentionally designed their compositor to not support this?

Again this is backwards and not how it works. What happens is that toolkits link against libdecor and get xdg-decoration for free. Xdg-decoration can be implemented by the server, and libdecor provides an implementation of it for the client that will fall back to client-side decorations if it's not there. Nothing needs to be done on the server to support libdecor.

>Maybe GNOME users never swich window managers, but I definitely switch between a few. I like SwayWM quite a bit these days, and I have my own toy Wayland compositor that I occasionally poke around with.

That's great and I'm glad you're doing that, but you are not the target user that GNOME app developers would be aiming for, sorry. They would be aiming for GNOME users.

>xdg-decoration feels like it is in spirit with the nature of Linux and the freedom to choose

This is not the spirit of Linux. I hate having to link this page often, but please read this: http://islinuxaboutchoice.com/

>Not GTK apps, even ones that request native borders, though; it seems the GTK folks are such great pals of the ecosystem that they only support an older non-standard for negotiating native borders.

Maybe they will accept a patch to update to the new standard, if you're serious about that then you should ask them. I don't think it would be much code.

>Anyways, you keep alluding to X11 WMs that don’t draw borders, but please give me an example of an X11 WM that doesn’t draw borders and expects the client to do so.

Well you already mentioned those, that would be most tiling WMs. In most tiling WMs I've seen it's a setting to configure whether to request borders or not, so it's not accurate to say that they always want windows to not have borders.

Continued in a reply because the response is too long.