File picker meme

>This is factually incorrect. On Win32, window borders are drawn out-of-process by the OS. You do need to link to CreateWindow in user32, but that’s only vaguely a “UI toolkit” as CreateWindow is closer to a syscall than a library function.

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.

>Besides that, GTK is not the canonical toolkit of Linux or Wayland.

Right, but that doesn't change it. If you want GTK decorations, you link against GTK. If you want other decorations then you link against another toolkit. If you don't care about the decorations and just want whatever then you could use xdg-decoration or libdecor, but not all app developers will want that.

>So this is not a reasonable option even if it would be on another system.

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.

>They make GTK apps behave badly, but most Qt stuff works pretty reasonably.

My experience is actually the opposite, Qt apps are even more likely to have odd sizing issues or inconsistent behavior. But I probably used a different set of apps than you did.

>considering they don’t ask for much other than accurate window hints and no custom borders

Maybe the window manager developers don't ask for anything but the apps are still broken. A lot of desktop apps cannot be placed into 1/6th of the corner of the screen and still work correctly but that's what tiling WMs try to do. Especially on a laptop with a small screen I find this behavior to be completely unusable. The window hints and borders are really not significant compared to all the other issues, so I honestly have no idea why some people seem to be so focused on that.

>That just means my app will look like crap if the compositor doesn’t support xdg-decoration.

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 difference is not whether or not window borders are optional. The difference is whether the app or the compositor handles window borders.

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.

> 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???

>Fragmentation might not be new but I would really rather not re-write my UI in another toolkit just to offer a second border option.

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.

>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.

From the app developer perspective it is the same though. A GNOME user will want their apps to have client-side GTK decorations because this is the way GNOME apps are built. It's the same as if that user was using a tiling WM and turned the client-side decoration setting to always on. You have to handle this if you are an app developer and want to support those platforms.

>I think, though, that pushing the responsibility to draw basic native borders onto the app is still not an ideal situation.

Well that's not what's happening, usually the responsibility falls on the toolkit. Libdecor exists to simplify the task for toolkits, apps should really not be linking against it directly unless they're something big like Blender that has enough resources to implement and maintain its own toolkit.

>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.

Ok that's fine for you if you feel that way, GNOME designers seemingly do not feel that way as it has become a central part of their design language.

>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.

It is the status quo on GNOME.

>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.

It works fine. Why would it be a problem? It's not different from adding any other library dependency to a flatpak.

>There is really no question regarding xdg-decoration: when you’re on the protocol level, all of these problems disappear.

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.

>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.

Those apps were totally broken on Wayland to begin with, Wayland did not even support borders at all before the KDE protocol and subsequent xdg-decoration which only happened a few years ago. So yes you could say is the app developer's fault, or more accurately it is the toolkit developer's fault for advertising Wayland support and yet having incomplete support for it. GNOME cannot fix app developer's apps for them, nor can KDE. And let me illustrate this again: even with xdg-decoration, even under KDE, all apps still have to implement fall-back decorations to be compliant with the spec. If your app is supposed to have borders and there is ever a situation when it has no borders then that app is broken as per the spec, you need to handle that case inside the app, not in the compositor.

>I’m very in support of Wayland, but this whole squabble was so easily avoided.

I disagree, there are real technical reasons why this wasn't done. KDE's implementation of this is also pretty complex and not suitable for all desktops to copy.

>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???

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.

Well why doesn't the GNOME project offer a way for people to pay for specific features and bugfixes? I would contribute money if I knew it would go towards paying someone to fix the file-chooser dialog. So would a lot of other people, if there was an announcement. I know for a fact I am not the only person who would do this:

https://jayfax.neocities.org/mediocrity/gnome-has-no-thumbna...

> One may say, "quit complaining, the GNOME developers are doing for free!" Okay. Well, how much money should I pay for someone to fix this then? I’m legit offering a bounty here. Conditions are that this fix makes it into the master branch.