> You would still need to link against the toolkit. Plus, if it's a syscall, that means the kernel is involved in drawing the decorations, which is probably not going to happen in Linux. Sorry. Not every OS is built the same as Windows. If you like the way Windows is built, you might want to use it and not Linux.
Again, User32 is not like GTK or even Cocoa.
I didn’t say I liked the way Windows is built, I’m just trying to explain to you how it works because you are saying things that are inaccurate to prove your point. And besides, people who like the way Windows is built would be fully allowed to impose their own feelings into such a discussion. It is, after all, the most commercially successful operating system, and its UI, for all its faults, is a hell of a lot better to use than GNOME in the opinion of many hardcore Linux users.
> I don't understand what you mean reasonable? Both ways work if you're designing a system, you only have to care about them if you're a developer because it's a minor implementation detail.
Yes. But unless GNOME is an operating system in and of itself, it cannot prescribe what the canonical toolkit of Linux is. User32 ships with Windows; it is as integral to Windows as the kernel is. GTK isn’t even close to as ubiquitous on Linux, and it’s also not nearly as integral to the operating system.
So no. It is not reasonable to ask applications to link to a canonical toolkit. There is a canonical toolkit on Windows and macOS. But if I write an app that is cross platform, as many of the apps people install today are, I want to be as agnostic as is reasonable. I don’t want my app to look like it’s running in VMWare Unity Mode on the majority of desktops, because at that point it might as well be, and why even port software to Linux?
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.
> This makes no sense to me. Libdecor will draw the fallback, if your app correctly supports xdg-decoration then it has to draw a fallback. The only thing xdg-decoration does is allow the compositor to draw fallbacks in some circumstances, so if you think the fallbacks all look like crap, then nothing you do there will ever help. There is no possible way to solve your problem.
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. 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?
> It's the same difference. Just as in X11, some window managers will never handle the window borders. There is nothing you can do about this besides patching all those window managers. But you probably don't care about that because most people don't seem to switch window managers very often.
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. xdg-decoration feels like it is in spirit with the nature of Linux and the freedom to choose; anyone can, with no centralization, just support it, and most apps can display native window borders.
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. Gee, thanks everyone.
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. Seriously. If the WM doesn’t want windows to have borders, like tiling ones, I don’t want to fuck with that. I want my app to display with no borders because that’s evidently what the user wants. This is not the same as GNOME not supporting xdg-decoration and having apps with no borders. That issue didn’t occur on X11 because that wasn’t how window management was approached.
I am totally okay with apps having the ability to draw their own borders. Discord, VSCode, Chromium and plenty of other apps do it, it’s fine. There is no serious issue with the concept of CSD. I think, though, that pushing the responsibility to draw basic native borders onto the app is still not an ideal situation. 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. On the other hand, the reality is that 10 years ago, very few apps ever did CSD, nor did any system really expect them to. And so, moving the expectation to the client is naturally a breaking change. The expectation, broadly across many systems and WMs, used to be separated from the client. 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. 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.
There is really no question regarding xdg-decoration: when you’re on the protocol level, all of these problems disappear. And when all you need is a GL or Vulkan context, like many games, which tend to run in a chroot or sandbox, it is really, terribly silly to force this bizarre conundrum on them when all Mutter had to do was not wall itself out of implementing a spec like xdg-decoration.
Well, it’s too late now. 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.
I’m very in support of Wayland, but this whole squabble was so easily avoided. Yes I know, that it would be ugly to have had essentially libdecor in the compositor. 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???