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.
> It is the status quo on GNOME.
This is your problem, and GNOME's too: GNOME doesn't own the Linux desktop. The status quo on GNOME should not drive protocol standards that impact the entire Linux desktop ecosystem. The protocol standards should be driven by the needs of the larger ecosystem. I'm not saying the needs of GNOME are unimportant. They are just not the end of what needs to be considered when developing this kind of thing.
This point here is more important than this entire argument about CSD. The rest can be discarded. Why should GNOME's fairly isolated status quo be the burden of every application or app toolkit developer? The inverse is a burden on the compositor. There are far more apps and app developers, and even toolkits, than there will ever be Wayland compositors.
> It works fine. Why would it be a problem? It's not different from adding any other library dependency to a flatpak.
Because you will get a vendored copy of libdecor. In a runtime like the Steam runtime, you might wind up attempting to load a version of libdecor linked against an incompatible libc if you try to use the system version. This is not a problem that would occur if a protocol were used instead.
> 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.
libdecor also has the potential to create other problems. This is just pointing out that software is hard. Yes, I get that.
If GNOME cared about what experience was good for the user, they would have cared about the fact that the Wayland compositor they shipped into production runs many games with missing window borders because of their own initiatives and sway within the Wayland ecosystem. The user experience in GNOME is genuinely worse due to this strange insistence on moving a problem from one location to another.
> 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.
Not every application needs a UI toolkit. There are also a lot of UI toolkits. Now many of them struggle with the fairly unimpressive task of displaying a window with reasonable looking borders. That's not a good user experience, and it's certainly not a good developer experience.
I really do have a lot of opinions regarding what you are saying, but I'm honestly running out of steam on replying to each point blow-for-blow because it feels like I already expressed my point and the reply is just what I said but inverted.
I'm sorry I have no idea what you mean. This is not about the Linux desktop, this is about GNOME. If you don't want to support GNOME then there's no reason to discuss this, because it doesn't matter, you can keep going about your way and you don't have to care about them. Am I missing something here?
>The status quo on GNOME should not drive protocol standards that impact the entire Linux desktop ecosystem. Why should GNOME's fairly isolated status quo be the burden of every application or app toolkit developer?
They aren't, and they don't? I'm extremely confused as to what you're talking about here. This again is about what you would have to do to support GNOME. Not any other Linux desktop.
>The inverse is a burden on the compositor. There are far more apps and app developers, and even toolkits, than there will ever be Wayland compositors.
This doesn't matter because the issue here is how to make apps that aren't broken. Some things simply cannot be fixed in the compositor, they have to be fixed in the app, and this is one of them. I sympathize with your concern and I wish it wasn't the case, but sometimes app developers have to do some work that they don't want to do.
>Because you will get a vendored copy of libdecor. In a runtime like the Steam runtime, you might wind up attempting to load a version of libdecor linked against an incompatible libc if you try to use the system version. This is not a problem that would occur if a protocol were used instead.
That isn't how flatpak works at all. You don't use the system version, you only use the vendored version, and you do that specifically to avoid that linking problem you mentioned. Also libdecor does use the protocol so I have really no idea what you're talking about again here, sorry.
>libdecor also has the potential to create other problems.
Sure but the problems there would be exactly the same as they would be if you did it all in the server, so libdecor is not making it any worse. The only difference is that the code moved to the client.
>If GNOME cared about what experience was good for the user, they would have cared about the fact that the Wayland compositor they shipped into production runs many games with missing window borders because of their own initiatives and sway within the Wayland ecosystem.
Well I'm not sure if you saw this part in my previous part but those apps are broken according to the xdg-decoration spec. It has really nothing to do with GNOME at all. All Wayland apps need to provide fallback window borders if they want to work correctly in all situations, if they don't then that's a bug.
>The user experience in GNOME is genuinely worse due to this strange insistence on moving a problem from one location to another.
I don't see why that concerns you if you're not a GNOME user and you have no interest in supporting GNOME. GNOME can deal with their own problems, if that causes them to lose users then that's something only they have to care about, not you.
Continued...
Sure, but if you don't use a toolkit then you need to take care of the missing pieces on your platform, in the case of Wayland one of those missing pieces is window borders. If you're a toolkit developer and you can't implement window borders, then I would suggest not advertising your toolkit as having complete support for Wayland.
>I really do have a lot of opinions regarding what you are saying, but I'm honestly running out of steam on replying to each point blow-for-blow because it feels like I already expressed my point and the reply is just what I said but inverted.
I'm sorry if this seems rude but both your opinion and my opinion don't matter and I don't care how you feel about this. That's nothing personal towards you. We're just two people having an informal conversation, it's just not helpful for us to look at it like we're trying to sway each other's opinions, so don't feel like you have to convince me of something or rebut my opinions. If you feel you don't want to support a certain type of decorations then that's perfectly fine, I'm happy for you to carry on doing that. But the technical reality of the situation and what that means for the challenges you may face is a different discussion from what you or I feel, and clearing up the technical stuff is all I'm interested to discuss.
If you have some other technical things to present then please do that, otherwise you're right that there is nothing more to discuss here. I'm only typing here to correct some misconceptions that I saw you had about the whole situation with libdecor. I find that most people who are upset about the situation don't really understand it fully or missed some key piece of information. I usually try not to do it point-by-point but it's really hard when you list a lot of points. However it does seem that a lot of your statements are stemming from a few initial misconceptions, so I can summarize that if you want.
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.