82 karma · joined September 19, 2021
You're correct that XWayland is likely not going away any time soon but I would suggest avoiding it if you can, it's only for compatibility with legacy apps. It still has some of the same security issues as Xorg but they're confined only to other concurrently-run XWayland apps.
(And to be honest, none of this stuff is exciting or new to me. It's just a re-packaging of the technology behind Docker but for desktop apps)
Edit: For LibreOffice it's likely that the project is popular enough that different people all contributed all those packaging options, so I don't think it's like a burden on them or anything. If something stops being maintained they'll just drop it.
>Nothing is less attractive to a user than opening an app to find the ugly Adwaita interface instead of their distro's choice
This is by design and is not fixable in any distro with any packaging system and highlights an underlying problem with any theming. Avoiding flatpak sadly will not fix it :( The only choices really are to disable themes, or patch/remove the package when it breaks with some theme. The first is what flatpak apps will do because they want to work on any distro regardless if the user has a broken theme, the second it seems is what distributions usually do.
>Does your app use MPRIS? Good luck getting it working!
This should be really easy to fix, all you have to do is white list the d-bus path for it. You should consider reporting that as a bug to the flatpak packager also.
>You want configuration files in sane locations? How about we make it a pain in the ass to access your own files instead.
Huh? The config files are just stored in ~/.var/app/. It's not a pain in the ass to access them at all.
It's not just this but it's also the lying and attempting to pass off various myths, mysticism, dogma, theology and fairy tales as being true with no evidence, and the promotion of "faith" and "belief" as justifications for doing so. And before someone says it, yes, there are other groups besides religious groups that fall into these same self-reinforcing traps. For example a significant number of people still believe in witches and ghosts: https://news.gallup.com/poll/2380/One-Third-Americans-Believ...
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.
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.
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.
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.
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.
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.
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.
>its default is to send all your OpenGL operations to the X server so that the X server can do the actual OpenGL things
This isn't the case with any modern GLX applications and also hasn't been the default on the Xorg server in many years: https://gitlab.freedesktop.org/xorg/xserver/-/commit/d0da0e9...
>On Unix, EGL is implemented in Mesa
Confusingly, GLX is also currently implemented in Mesa.
>I suspect that EGL on X is not in any way network transparent
It's not, but modern GLX is not "network transparent" either. The only way you get indirect rendering with GLX is with extremely old applications (OpenGL 1.4 and earlier) and if you explicitly configure the server to use it with a flag.
>I don't know how an application using EGL and OpenGL on top of a Zink backed would interact with a Vulkan WSI, but I assume that Zink plumbs it all through somehow.
Zink is a Gallium driver so the WSI doesn't get used. You just use EGL and then Zink passes the Vulkan buffer back to it.
>There is no conspiracy that there are a bunch of people out there that want to give you a bunch of work to do just to mess with you. 100% of these people are honestly affected by the issue and would like it resolved.
I don't know if you noticed, but the wiki article appears to include instructions for 4chan users on how to use this issue to troll and rile up Linux users. If you include whoever wrote that article and whichever 4chan users have read it then it's probably a good deal less than 100%. And honestly I've seen this trolling on reddit and hacker news pop up before several times before, almost every time the file chooser gets mentioned it seems to be a result of some 4chan trolling. Of course the issue is going to get locked if it's getting brigaded by 4chan trolls. If people honestly wanted to get it resolved, they would have written a merge request for it.
Again, maybe you're trying to be forgiving when you say "we can't just deny people access to jobs and public life" but we absolutely can do that when they become a detriment to everybody else involved in those jobs and public life. It's sad but it's true. For people who are particularly detrimental to the point where they commit hate crimes, we send them to prison.
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.
Yes. The bug tracker is not a place to have an argument. The correct place for that would be a mailing list.
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?
>GIMP is free software, its lack of funding, that (allegedly) those tools are irrelevant
If you have a specific feature request, you might consider checking the bug tracker for an existing issue. If there is one, then it's not helpful to mention it any further. The developers already know what the request is. From that point on the only helpful thing you can do is to contribute code, designs, etc towards getting the feature done.
To illustrate, have you ever had somebody sitting behind you while you work who keeps repeatedly saying things like "are you working on that thing for me yet? are you done yet? when will you be done?" until you finish? It's kind of like that. Doing that doesn't help the person go any faster.
Please remember: GNOME is a loosely connected group of volunteers all working on what they want to work on. If one person says they're prioritizing something and another person says they're going to do something else, that's not hypocrisy, that's just a difference of opinion. I know it may be confusing when one person says one thing and another person says something different but this is something you have to get used to in open source, it's not like a company where the CEO tells everyone what to do. Some developers may choose to listen to certain community members and may choose to ignore other community members, sadly that has to happen in any project where the wider community outnumbers the developers. Every interested person can't get their way all the time because resources are limited.
>They claim to respect your freedom, but force you to use Flatpaks and obfuscate their own code to prevent you from getting consistent app theming
This statement doesn't make sense to me. Flathub lists the license of the program and most packages are open source. And I have no idea what you mean by "obfuscate their own code" or "consistent app theming", could you elaborate? The suggested way to get consistent app theming is to stick with the Adwaita theme, if you're installing custom themes then that's guaranteed to be inconsistent.
>Here's hoping they can iron out all of the (many, many) issues before the next major release.
If there are issues that you want to see fixed, the best way to help that would be to contribute.