Sometimes collaboration goes nowhere: https://gitlab.gnome.org/GNOME/mutter/-/issues/217
Option B: applications can choose between GTK 3/4 (not exactly a fan favorite) and get native looking title bars only on GNOME (without extra work — also only supports an out-of-date spec for native window frames on Wayland) or they can use libdecoration (or libdecor or whatever) which appears to be persistently not ready for prime time, and will still not look native in most Wayland compositors.
Honest to goodness, apps should just force themselves into X11 mode on GNOME until the compositor is fixed. The CSD initiative is a broken idea.
This isn't true, some X11 window managers don't draw any title bars.
Anyway this isn't a problem if you link against GTK or libdecor. Yeah it's broken if you're trying to work against the system and do things in the inconsistent way that they were done in X11, so... don't do that?
And telling me all Linux apps they should link against GTK would make me angry if it wasn’t so stupid.
P.S. edit: I’d just to like to add:
- Please don’t take my harsh tone too personally. I’m not pissed off at people, I am pissed off at their initiatives sometimes though. I don’t really harbor any ill will towards individual developers. I think if you make decisions that impact an ecosystem it’s only natural that strong emotions will emerge.
- The main reason why GNOME solutions are not really landing that well is specifically because they are attacking the problem more from GNOME’s philosophical standpoint than from the standpoint of what is best for applications. KDE does not appear to be embodying the CSD initiative, which is actually Good for GNOME users, since KDE apps will likely feel a ton more native in GNOME as a result. Certainly more than GNOME apps do in KDE… but it also means that libdecor is kind of moot, because what we as app developers really want is one solution that gives us fully native basic window borders everywhere. And to do that, we need a solution that starts from the common ground (xdg-decoration) then goes into special cases (GNOME, Weston, etc.)
It does, that was the first thing added. I wouldn't suggest using xdg-decoration though as it will mostly guarantee that your apps don't match the decorations.
>And telling me all Linux apps they should link against GTK would make me angry if it wasn’t so stupid.
If you want GTK decorations, then you should link against GTK. Not sure why you would think that's stupid or would make you angry, please elaborate. If you don't want to use compile time linkage then you can use dlopen, that's what libdecor does under the hood.
>KDE does not appear to be embodying the CSD initiative
This isn't entirely true, some KDE apps have actually started to use client-side decorations.
>which is actually Good for GNOME users, since KDE apps will likely feel a ton more native in GNOME as a result
I don't think so, KDE apps will never feel native in GNOME as they're built for a different HIG. Using non-matching decorations will actually make it worse because now the application is following two separate and incompatible HIGs. That's a good way to ensure you get conflicting gestures/keybinds, inconsistent theming, and just a general lack of consistency.
>what we as app developers really want is one solution that gives us fully native basic window borders everywhere
I don't want that when I'm making apps. If I'm making a GTK app then I would expect to get the GTK borders. If I'm making a Qt app then I would expect to get the Qt borders. And so on.
>And to do that, we need a solution that starts from the common ground (xdg-decoration) then goes into special cases (GNOME, Weston, etc.)
This isn't correct, xdg-decoration is not the common ground. The common ground would be drawing your own decorations because that's the way any Wayland server works by default. Xdg-decoration is an optional extension that even with its presence doesn't guarantee you will get the borders that you want.
Consider the following: any compositor can choose to support xdg-decoration and get automatic support, apparently including for libdecor. It is definitely defacto common ground, because every other compositor becomes a special case.
I will grant you that I didn’t know libdecor supported xdg-decoration. I attempted to read the source code once and entirely missed it, possibly because I was focusing too hard on the plugins aspect.
Anyways, this is going too far off the deep end now. Yes I understand that Dolphin will never look as native under GNOME as Nautilus. However, it is not even close to how ridiculously non-native Nautilus looks under KDE; it’s simply no contest. It looks like a funny VMWare Unity Mode demo rather than interoperability.
I’m also well aware that Wayland is built to not require something like xdg-decoration, but we’re at an impasse because you view that as a feature and I view it as a bug.
No, not really. On those other platforms you would link against the toolkit.
>If someone’s X11 WM doesn’t give them window borders, that’s fine: they probably have a lot of apps with no window borders, that’s probably the point of their WM.
Same thing with Wayland, except typically apps are expected to draw the window borders there.
>Sorry, but GTK 3+ apps will look wildly out of place in any tiling WM whereas apps using xdg-decoration will be just fine.
Every time I used a tiling WM, almost every single app looked and acted wildly out of place. A tiling WM is simply not an application platform. I've honestly found that tiling WMs are only good for arranging terminal windows, they make most other GUI applications behave badly.
>Consider the following: any compositor can choose to support xdg-decoration and get automatic support, apparently including for libdecor. It is definitely defacto common ground, because every other compositor becomes a special case.
No, this isn't true, you may be confused as to what xdg-decoration actually is. If you don't implement xdg-decoration and you use libdecor then the behavior is the same as if xdg-decoration turns off the decorations, libdecor will draw its own.
>However, it is not even close to how ridiculously non-native Nautilus looks under KDE; it’s simply no contest. It looks like a funny VMWare Unity Mode demo rather than interoperability.
Yes, apps that don't follow the KDE HIG will always look non-native. Try to run windows apps in Wine and it will similarly look out-of-place. Try to run some old Motif apps and they'll look weird too. If you want to get an app that looks and acts native in KDE then you would want to use the KDE frameworks. Why complain about this when you're use an app that is intentionally designed for a different platform?
>I’m also well aware that Wayland is built to not require something like xdg-decoration, but we’re at an impasse because you view that as a feature and I view it as a bug.
So it doesn't really matter if either of us view it as a feature or bug. From the perspective of the window manager, decorations are still an optional thing just as they were in X11.
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.
macOS internals are harder for me to ascertain, but it seems similar in how responsibility is split between OS and application.
Besides that, GTK is not the canonical toolkit of Linux or Wayland. So this is not a reasonable option even if it would be on another system.
> Every time I used a tiling WM, almost every single app looked and acted wildly out of place. A tiling WM is simply not an application platform. I've honestly found that tiling WMs are only good for arranging terminal windows, they make most other GUI applications behave badly.
They make GTK apps behave badly, but most Qt stuff works pretty reasonably.
Anyways, if you dislike tiling WMs that’s fine, but I don’t and I want my apps to act decently, like apps designed to work with tiling WMs tend to work (which is not a huge ask at all, considering they don’t ask for much other than accurate window hints and no custom borders.)
> No, this isn't true, you may be confused as to what xdg-decoration actually is. If you don't implement xdg-decoration and you use libdecor then the behavior is the same as if xdg-decoration turns off the decorations, libdecor will draw its own.
That’s not a good solution. That just means my app will look like crap if the compositor doesn’t support xdg-decoration.
> So it doesn't really matter if either of us view it as a feature or bug. From the perspective of the window manager, decorations are still an optional thing just as they were in X11.
The difference is not whether or not window borders are optional. The difference is whether the app or the compositor handles window borders. And for that, this opinion is literally the crux of the issue.
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.
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???
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.
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.
Surely the choice should fall on the user.
> That's a good way to ensure you get conflicting gestures/keybinds, inconsistent theming, and just a general lack of consistency.
Which is why we would like all of these to be configurable.
> The common ground would be drawing your own decorations because that's the way any Wayland server works by default
What if I, as a user of a tiling wm don't want any decorations?
> Xdg-decoration is an optional extension
That everything supports it afaik. (except mutter?)
It does, the user can choose to use GTK or Qt apps.
>Which is why we would like all of these to be configurable.
So making it all configurable is just guaranteeing that the app is broken out of the box and needs to have all this stuff set up before it even works correctly. Not exactly a user-friendly way to ship a program.
>What if I, as a user of a tiling wm don't want any decorations?
You may have to accept that some apps are not built to work in a tiling WM. In my experience, you will have a lot of trouble with some apps for various other reasons too, not just the decorations.
>That everything supports it afaik. (except mutter?)
I'm confused, you said everything supports it, but then immediately listed something that didn't support it.
That's... not what I meant by it. I find this dangerous as it encourages duplicate work for minor differences.
I would rather not have to make both a GTK and a Qt version of my program just so my users can have the ability to do some basic customization.
> So making it all configurable is just guaranteeing that the app is broken out of the box
Not sure why you think that. You just put the existing choices as the defaults.
> You may have to accept that some apps are not built to work in a tiling WM
What about my apps then? As a programmer I want my programs to be friendly for both tiling and non-tiling WMs. This by itself excludes gtk as an option for me.
As for some apps not built to work in tiling WMs, the changes needed to make them work properly are usually extremely minor. To be honest it feels like the GNOME team is going out of their way to degrade the usability of their apps (and apps using gtk) for tiled WMs.
> In my experience, you will have a lot of trouble with some apps for various other reasons too
Some apps might have some minor issues that can usually be solved without a lot of effort, but even if they are not they don't usually pose any problem.
> I'm confused, you said everything supports it, but then immediately listed something that didn't support it.
Yes? Everything except mutter supports it as far as I know. Is there something difficult to understand here?
Edit: I heard that Enlightenment does not support it either.
Sure, but this fragmentation isn't exactly new. There have always been multiple toolkits on Linux. I don't know what else to tell you, if you don't like it then you can pick one toolkit for your own apps and just focus on that. I wouldn't exactly call this "basic customization" if it requires you to rewrite your whole app so it's fine to just use one toolkit. I understand maybe you are facing some indecision about toolkits, that's normal, you may want to take some time to research them and find which one suits your app better.
>Not sure why you think that. You just put the existing choices as the defaults.
I already explained it, that will be broken if you use it outside the recommended environment as the HIGs won't match. The defaults only make sense on the target platform.
>What about my apps then? As a programmer I want my programs to be friendly for both tiling and non-tiling WMs. This by itself excludes gtk as an option for me.
Well, no it doesn't. You can disable the decorations in GTK. Most GTK apps don't by convention but you can do it if you really want. And you don't have to use GTK, you could use another toolkit.
>As for some apps not built to work in tiling WMs, the changes needed to make them work properly are usually extremely minor.
>Some apps might have some minor issues that can usually be solved without a lot of effort, but even if they are not they don't usually pose any problem.
I disagree with this entirely, the app needs to be designed in a fully responsive fashion to do that. Most older apps aren't like this.
>To be honest it feels like the GNOME team is going out of their way to degrade the usability of their apps (and apps using gtk) for tiled WMs.
I don't know what you mean by this. GNOME is not a tiling WM, so people who make GNOME apps usually do not target tiling WMs or test there. It would actually be the opposite, supporting the tiling WM would be going out of their way.
>Yes? Everything except mutter supports it as far as I know. Is there something difficult to understand here?
The way you're phrasing is confusing. To me it's like saying "every vehicle has four wheels except bicycles". Well I guess you could say that for some subset of vehicles, but I don't understand what the distinction here is supposed to be, or why that even matters.
I think that we got a little bit sidetracked. "I want my users to be able to be able to select what borders to have" -> "the user can choose to use GTK or Qt apps" -> "it encourages duplicate work for minor differences" -> "fragmentation isn't exactly new"
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.
> that will be broken if you use it outside the recommended environment as the HIGs won't match
Depends on your definition of broken I guess. 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. 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. If some minor issues are caused at certain configurations then that's fine, after all the user could revert to the default config if they encounter an issue that breaks their use-case or makes the interaction feel inferior to the default one.
> Well, no it doesn't
Thank you for the correction, I take it back. 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?
> Most older apps aren't like this.
What do you mean by "older apps"? Motif-era, gtk2-era, or gtk3-era? I do not think that I had a big issue with any of them but I could be forgetting something.
> GNOME is not a tiling WM
Well, yeah, because GNOME is not a WM :p
By "going out of their way" I meant specifically the decision to implement CSD.
In general I think that GNOME should be able to do whatever it wants, I just wish that they would play better with the other players (and well, the users).
> The way you're phrasing is confusing. To me it's like saying "every vehicle has four wheels except bicycles". Well I guess you could say that for some subset of vehicles, but I don't understand what the distinction here is supposed to be, or why that even matters.
More like "all (relevant) C compilers except MSVC support C99 VLAs", or "all mobile phones in the EU except apple's use a standard charger". 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.
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.
> 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.
Then don't make them. Just do what every other desktop has done since 1992, give people the option to configure things the way they want, and save your "sub-par user experience" argument for setting the defaults. If corner-cutting starts to affect power users, you need to go back to the drawing board and re-think things. Luckily, this is a pretty easy situation: nothing is broken, nothing needs to be fixed. It's along the lines of GNOME deciding the remove your clipboard history because it was gauche and such an old and ugly feature.
> Well that's not true, you can see some of the motivations for using CSD here
Yeah, real motivation going on there. Of the 4 apps they mention needing CSD, only one got it. Is that really what 3 years of progress should look like for that kind of initiative?
> 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.
GNOME is not Linux, and the issue is that the GNOME developers are making too many decisions on behalf of the end user. I didn't have an issue with the mostly hands-off approach that GTK2 and 3 used. I do take issue when I can't use a desktop environment because my preference for handling packages is apparently verboten, and now they've decided to remove features that I liked. It's a regression on the level of dropping the Unity desktop, but even more user-hostile.
And even still, I have a hard time calling GNOME in it's current state much of a platform. It exhibits constant crashing issues on my Haswell devices which means I can't use it on half my devices, and it only truly functions on one or two distros. Not to go "us vs them", but KDE has no problem maintaining a stable, usable desktop even across major releases. I'm utterly dumbfounded by how the current maintainers of GNOME feel so self-righteous in their redesign, especially considering the state of their recent releases.
So your statements here aren't correct. Please avoid accusing me of being a fanboy. If you really want to know my opinion, I'll use any desktop and I'm not passionate about any of them, GNOME is just one of them. They each have their strengths and weaknesses. But if you're asking questions about GNOME and GTK then I'll give you straight answers, they are also part of the "Linux community" and it doesn't help either of us to misrepresent them. There are certain facts about that which it is not helpful for us to disagree on, because they are just that: facts, not opinions.
>Then don't make them. Just do what every other desktop has done since 1992, give people the option to configure things the way they want
Well some users may have no need to configure that. And like I was saying with complex apps, it may be that you don't need to give users a really complicated way to configure every little detail. It may be that what they really want is just a way to swap between "presets" and that will be enough for everyone. You don't know until you actually do the design work and iterate. This of course is a more complex and nuanced topic than just saying "give us an option" or "give us a default" or something like that.
>If corner-cutting starts to affect power users, you need to go back to the drawing board and re-think things.
Well no, in my experience power users are just as likely to be trying to accomplish something specific like that. When you get down to it their usage patterns are not particularly different.
>Yeah, real motivation going on there. Of the 4 apps they mention needing CSD, only one got it. Is that really what 3 years of progress should look like for that kind of initiative?
I really don't know what their progress goals are but there are many other GNOME apps not listed there that use CSD, you should look at them if you're interested to fully understand the progress.
>GNOME is not Linux, and the issue is that the GNOME developers are making too many decisions on behalf of the end user.
Yes I agree that GNOME is not Linux. But GNOME developers are making decisions on behalf of GNOME users. That's what they're supposed to do, those are the end users they support. I don't understand what your issue here is. If you don't use any GNOME software then their decisions won't affect you.
>I do take issue when I can't use a desktop environment because my preference for handling packages is apparently verboten
Which preference is this? Can you elaborate?
>and now they've decided to remove features that I liked. It's a regression on the level of dropping the Unity desktop, but even more user-hostile.
I'm sorry to hear that, but I hope you can understand that every project cannot support infinite features. If it's desired to add a new feature then sometimes an older feature that has some overlap with it will have to be removed. That's just the unfortunate reality, nobody is trying to be hostile to you. And it's not really feasible to ask software developers to stop adding new features, if they did this then everything would stagnate.
>And even still, I have a hard time calling GNOME in it's current state much of a platform. It exhibits constant crashing issues on my Haswell devices which means I can't use it on half my devices, and it only truly functions on one or two distros.
Can you please report these bugs? I've never experienced this. If those are legitimate bugs then I'm sure someone will want to have them fixed. It could possibly be a driver issue that is not strictly related to GNOME.
>Not to go "us vs them", but KDE has no problem maintaining a stable, usable desktop even across major releases. I'm utterly dumbfounded by how the current maintainers of GNOME feel so self-righteous in their redesign, especially considering the state of their recent releases.
Please understand that not every project has the resources to test with every hardware combination, it may just be that you hit some unusual and unfortunate combination of hardware and software that blows up. It's just lucky for you that KDE doesn't hit that.
If you don't want to use GNOME or Flatpak that's perfectly fine, I'm happy for you to choose whatever you want. But some of the statements you've made here are false, including the assumptions you've made about me. That's not being respectful to me or to the project when you do that. Please don't spread misinformation or make decisions based on false information, that damages the community and it also hurts both me and you. If you're not actively using/developing a certain project or in regular contact with the developers then I would suggest not making definitive statements about it or assuming that your experiences are shared by everyone. IMO it's a mistake to quit a discussion based on false information. If you ever change your mind and decide you want to report those bugs, the door is wide open for you.
Locked as expected. But really? Well-written written arguments from users and developers is considered spam?
When you see someone getting into a screaming match about why Playstation is better than XBox it may indicate narcissism. If the screamer had chosen the second best option, that would imply they aren't perfect and that isn't something a narcissist is able to process. The internet just allows for the XBox and Playstation selecting narcissists to find one another.
> I've created a new thread that hopefully is a bit more relevant. Continue the conversation here
> ['here' marked as duplicate of 'this' and closed]
I guess some people out there do like moron-friendly UI and UX.
Of course in my opinion Ubuntu isn't the same now as then but on the other hand KDE Neon is now even better.
Yes. The bug tracker is not a place to have an argument. The correct place for that would be a mailing list.