>Say what you will about GTK and Gnome... for beginners on an operating system such as Ubuntu, having a consistent application concept is very important.
Consistency is important but is not like the majority of the apps are GTK3 (or whatever is latest) with the GNOME styles even if those GNOME designers pretend nothing else exists and nobody should remove the GNOME branding from the GNOME apps.
Just want to mention that GNOME are the bad guys, KDE distributions will provide GNOME integration with packages and themes that attempt to keep Qt and GTK application consistent in look and feel but I never seen GNOME distros attempt to integrate with the non-GNOME apps.
They're making their desktop environment and apps into a walled garden on a platform like Linux. Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
They also engage in carefully crafted doublespeak when it comes to things like extensions and user choice regarding configuration.
Call it what you want but they certainly don't intend to play nice with anyone and have adopted the approach of "my way or the highway". Perhaps they're emboldened by all the corporate backing they have from Red Hat and SUSE. They also have the advantage of being the default DE on most distros. Hell, even distros like NixOS encourage users to use GNOME, which is absolutely insane when you think about it.
> Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
There have always been apps more heavily integrated with GNOME vs GTK apps.
Gtk4 is easier to port to other platforms, if anything it should be less painful than it has been before.
> Gtk4 is easier to port to other platforms, if anything it should be less painful than it has been before.
Oh, how desperately I wish this were true. My evidence is purely anecdotal, but I've found GTK4 to be almost completely unusable in my time working with it, so much so that I've basically decided to skip this release altogether and just stick with GTK3 for all intents and purposes. It started when I wanted to pull my Glade projects in to the new framework so I can build my apps with XML instead of writing it by hand... oops, that method has been unsupported. But don't worry! There's a replacement app right around the corner that's... not finished yet. Okay, I guess that's not a big deal, I'll just re-write everything by hand! Now it's compiling and doesn't look the least bit native on my system. And there are compositor issues. And the text looks ass-ugly too.
Asking around on IRC, I was told everything from "use Flatpak" to "stop trolling" to "your workflow is unhealthy/insane/unsupported". It would appear that GTK4 is only intended for GNOME extremists, unfortunately. If there are any portability improvements I won't likely see them.
If you depend on having a GUI builder then I agree it makes sense to wait for that to be stable before switching to GTK4. It's being worked on but progress is slow because of a severe lack of contributors. I don't know anything about compositor issues but it's aimed to give the text a substantial fix in GTK 4.6.
>I was told everything from "use Flatpak" to "stop trolling" to "your workflow is unhealthy/insane/unsupported". It would appear that GTK4 is only intended for GNOME extremists,
I don't see how that has anything to do with "extremists". The GNOME IRC is probably a bad place to ask for help with distro packaging, the focus is on Flatpak because that's realistically the only distro-agnostic packaging that upstream can support. For help with packaging apps for your distro you'd have better luck asking on your distro's IRC.
> If you depend on having a GUI builder then I agree it makes sense to wait for that to be stable before switching to GTK4.
Correction: traditional XML stylesheets were removed with the release of GTK4 so they could introduce a new paradigm, one that was not ready to replace it. I really don't know what to tell you here, because it's such a vast departure that it's going to make the porting process to GTK4 nearly impossible for most people. It's such a braindead, no-holds-barred move that it simply feels disgusting to me. Here we had this perfectly functional feature, and the GNOME devs, being the impractical idealists they are, said "let's get rid of it, offer a replacement and not develop the replacement". Same thing happened with LibAdwaita, GNOME 40 and pretty much everything else they seek to """improve""".
> It's being worked on but progress is slow because of a severe lack of contributors.
Who's fault is that? Is it the aggressive, unfriendly leadership? Or maybe it's the GNOME superstar celebrities, who make completely bonkers changes and expect the rest of the community to follow their lead without question? Maybe it's the lack of directive in their issue trackers, where their lead contributors decide to waffle on major issues instead of taking the directive to just shave the damn yak?
I don't care that they lack contributors. I really don't. That's a grave they've dug for themselves by ostracizing the rest of the community, and it's one they're going to have to deal with for years to come. They had opportunities to build bridges, and they tore them down. They harassed other distribution maintainers when they tried offering help of their own. They've shot themselves in the foot here, plain and simple. GTK2 and 3 weren't remotely this bad or unusable at launch, and it just makes me sad to see people clinging to elitism instead of pragmatism when building an inclusive, accessible desktop. If their ship is sinking, I'm perfectly contented to stay onboard GTK3 and watch as they sink beneath the surface. Several people said this was a bad idea, but it was their hubris that ultimately ruined GTK4. If they need "extra contributors" to fix that, then they should have thought about that before telling everyone else to screw off.
> The GNOME IRC is probably a bad place to ask for help with distro packaging
1. I was in freenode.
2. I wasn't asking about packaging.
My concern was getting my app to look right on every desktop that it ran on, which it most clearly did not. The text was distorted and completely unacceptable for distribution, there were black bars drawn around the window on half the desktops I tried it on, and the look-and-feel was inconsistent across systems. Utterly unbelievable for a toolkit that was trying to pride itself on accessibility.
> the focus is on Flatpak because that's realistically the only distro-agnostic packaging that upstream can support
The issue is that they don't even support that. Flatpak has over 600 open issues of it's own, and implementing it can oftentimes lead to more work, nonfunctional features (like distro-native features in Bottles, for example) and infinite bikeshedding. Every argument I've seen for using Flatpak is bogus. Every one. You can cry "it needs more maintainers!" and I'll probably agree with you, but it's become such a politicized and broken mess that, once again, very few people see the value to contributing to it anymore. Mark my words (and you're welcome to call me out when I'm inevitably wrong here): Flatpak will never get "finished". It has too many esoteric features, unfixable bugs and ideological missteps to compete with package managers that existed just fine 20 years ago.
>Correction: traditional XML stylesheets were removed with the release of GTK4 so they could introduce a new paradigm, one that was not ready to replace it.
Not really, the XML format is pretty similar. In my experience it works very well, even better than the GTK3 XML, but yes it's lacking a good GUI builder.
>I really don't know what to tell you here, because it's such a vast departure that it's going to make the porting process to GTK4 nearly impossible for most people.
I can't agree, I've talked to some GNOME developers and they don't have much of a problem with it. Glade on GTK3 is not very popular among GNOME developers anyway because it causes some other issues, hopefully those will be fixed with the new GUI builder too.
>said "let's get rid of it, offer a replacement and not develop the replacement". Same thing happened with LibAdwaita, GNOME 40 and pretty much everything else they seek to """improve""".
I'm very confused to what you're saying, there are replacements for all that being developed, but it takes time to do it.
>Who's fault is that? Is it the aggressive, unfriendly leadership? Or maybe it's the GNOME superstar celebrities, who make completely bonkers changes and expect the rest of the community to follow their lead without question?
I'm also very confused what you're talking about, I've talked to the Juan (the person working on the new GUI builder) and he's a pretty nice guy working as hard as he can. I've never seen him harass or ostracize anyone or refuse questions. You're generalizing and I wish you wouldn't do that, it's rude to the people who work hard on this and offer no ill will. I've never seen any aggressive leadership or superstar celebrities there either, this is mostly self-directed volunteers working in their area of interest.
>If their ship is sinking, I'm perfectly contented to stay onboard GTK3 and watch as they sink beneath the surface. Several people said this was a bad idea, but it was their hubris that ultimately ruined GTK4.
Well you lose some other improvements in GTK4 if you do this. Those improvements are very unlikely to be brought to GTK3 because they needed an API change. That's why it's a bad idea. Of course you can continue to use GTK3 if you want but you'll continue to miss out on those improvements. It's up to you to say how long you'll be OK with that, but you should know upstream has said that GTK3 will not gain any new features anymore.
>If they need "extra contributors" to fix that, then they should have thought about that before telling everyone else to screw off.
I don't know who was told to screw off, there are open calls for contributors in all these areas.
>I was in freenode.
Well Freenode is not the GNOME IRC so I have no idea what this has to do with GNOME or GTK. Yes there are trolls and unhelpful people in random freenode channels, I never used freenode much myself for that reason. GNOME has its own IRC server, and actually I think they switched to Matrix recently.
>The issue is that they don't even support that. Flatpak has over 600 open issues of it's own, and implementing it can oftentimes lead to more work, nonfunctional features (like distro-native features in Bottles, for example) and infinite bikeshedding.
I know about some of these issues and I'm personally affected by them but what you're missing is that there is actually no other option. Getting rid of Flatpak would leave them with no real way to deploy these apps at all. It's a choice between something buggy that's being worked on (slowly) and leaving app developers out in the cold with nothing. Distro package managers don't solve the problem, they created the whole problem that Flatpak exists to solve.
I'm not going to stop you from pretending like nothing is wrong if that's your prerogative. I'm letting you know here and now that there is an expanding sentiment among developers that GTK4 is a regression from GTK3, and if there are any improvements coming down the pipeline I have yet to see them. I'm not going to argue with you about this when my app is irreparably broken right now, though. Every attempt I've made to reach out to developers has either gone cold or been rejected. I fully intended to start contributing to GTK back in the v3 days, but now? The current leadership has made it clear that they don't have my best interests at mind. They'd rather scrap everything I used and promise a replacement instead of iterating on it or fixing it, which is unacceptable for a toolkit that is currently in active use. I refuse to donate my time or effort to people who disrespect me like that.
I'm a pragmatist, not an idealist. Promises mean very little, especially coming from the modern GTK team.
>I'm not going to stop you from pretending like nothing is wrong if that's your prerogative.
Please don't jump to this conclusion, I'm not doing that. If some GTK3 users want to continue developing GTK3 or use some other toolkit then that's absolutely fine with me. I said that before, I could even recommend some other toolkits for you to use. But I think it's a bad idea to view GTK3 as some kind of resistance against GTK4 because that's missing out on many years of improvements that would be very difficult to backport. Yes there are bugs in GTK4, but I've also talked to the developers and they are aware of them and are working on solving the issues even if progress seems slow. You can read some of the GTK4 blogs to see some of the enhancements that were made in GTK4 and decide if they're worth it to you or not: https://blog.gtk.org/2020/12/16/gtk-4-0/
>I'm letting you know here and now that there is an expanding sentiment among developers that GTK4 is a regression from GTK3
This is not really surprising or new or that much of a big deal, people complained when GTK2 was released because it changed stuff from GTK1, then they complained when GTK3 was released because it changed stuff from GTK2. It's totally understandable and normal for some to want to avoid or delay making the switch, but many others have been willing to make it for the improvements.
>Every attempt I've made to reach out to developers has either gone cold or been rejected. The current leadership has made it clear that they don't have my best interests at mind.
Well if you were on freenode then those probably weren't the upstream developers or any of the current project leadership so I think you might have a wrong impression; you're saying a whole lot of negative things but the underlying logic just doesn't really add up to me. I'm not interested to argue with you either, if you can just mention what the issue is with your app I might be able to help you.
>They'd rather scrap everything I used and promise a replacement instead of iterating on it or fixing it, which is unacceptable for a toolkit that is currently in active use.
This statement is also confusing to me, the replacement is the iteration and fixing. It's being worked on. It can't really be any other way, Glade is a very old application from the GNOME 1 days that's been continuously ported and it still inherits some old design flaws from that. To finally fix the design flaws the program needs some major breakage or a rewrite, so they decided to go with the rewrite because it's actually easier than hacking apart all the internals of Glade and breaking the whole program. And by "they" I mean the one person who has been working on Glade for the last few years and is now working on the replacement. I don't know what "promise" you're talking about either, I think it's a bad situation that only one person is working on this. He could stop working on it at any time and then you'd have no GUI builder at all, the "bus factor" on these projects is a concern right now.
>I refuse to donate my time or effort to people who disrespect me like that.
I'm not suggesting you do that, it seems more like you were asking about taking time or effort to fix your own application.
>There have always been apps more heavily integrated with GNOME vs GTK apps.
From my experience GTK2 apps were not "GNOME" apps, like there were many apps that did not installed the entire GNOME dependencies to work, I don't know if this changed lately since I so far only had the need for qt or GTK2 apps.
That's more because GNOME has completely dropped GTK2 while other projects continue to use it. In the past that wasn't true, GNOME 2 apps depended on a separate library called libgnomeui that had widgets specific to GNOME 2. All the actively-developed GNOME apps ported to GTK3 long ago and so they dropped that dependency which is why you don't see it anymore. The only apps left using GTK2 are non-GNOME apps and so they never depended on that in the first place.
>They're making their desktop environment and apps into a walled garden on a platform like Linux.
This is a rather empty statement as all these apps and the whole platform still continue to be open source.
>Call it what you want but they certainly don't intend to play nice with anyone and have adopted the approach of "my way or the highway"
I don't see how this is any different from how it was before. I've also found that KDE apps don't really work well outside of KDE, XFCE apps don't really work well outside of XFCE, etc. There is a clear line where an app developer has to decide if they're making a cross platform app (like LibreOffice, Blender, etc) or if they're making an app that integrates with a specific platform. Every single desktop I've ever seen has drawn this line somewhere because this is what users want, a KDE user prefers to use the KDE file manager and finds the GNOME file manager not so usable, a GNOME user prefers to use the GNOME file manager and finds the KDE file manager not so usable, etc.
>Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
I think you're confusing GTK4 with libadwaita, libadwaita is the library for GNOME apps that are only tested with GNOME and don't intend to be used outside it. GTK4 itself is not tied to any environment. And even then a developer could likely get libadwaita apps to work reasonably well in other environments with some porting work, similarly to how Krita depends on some KDE widgets and libraries but has been ported to other platforms.
>They also engage in carefully crafted doublespeak when it comes to things like extensions and user choice regarding configuration.
I don't understand, the stance on extensions has always been pretty obvious to me. Extensions are a third-party customization, they can work well and can do pretty much anything but because of that it's the user's responsibility to ensure their configuration is a working one.
> as all these apps and the whole platform still continue to be open source.
I mean, what is that even meant to convey? Do you mean to say that one can always create hard forks of non-trivial packages like GTK or develop extensions for GNOME shell the change the way it works like the PopOS guys did? We all know how well that turned out.
> I've also found that KDE apps don't really work well outside of KDE
Funny, because I use i3wm on an old NAS and KDE apps like Spectacle, Gwenview, and Dolphin work fine and use whatever theme and font I tell them to use and don't make decisions for me by assuming I'm incapable of making them. Can't say the same for GTK4 GNOME apps. They're not built to be used outside GNOME because GNOME is now a "platform", which is just doublespeak for a walled garden.
> the stance on extensions has always been pretty obvious to me.
It's obvious to me as well — we don't care about GNOME extensions[^1]. It's rather unfortunate that the extension system exists at all. People waste so much time and resources on making elaborate extensions like the Pop Shell or Dash to Dock under the impression that their extensions are somehow welcome but then they have to keep fixing them after every new GNOME release. What's even worse is that unsuspecting users use these extensions.
I'm conveying that no party can actually restrict this, GNOME/KDE apps might look ugly and bad on the other desktop but that's different from a business/legal restriction stopping you from running it or even trying to improve the ugliness.
>Do you mean to say that one can always create hard forks of non-trivial packages like GTK or develop extensions for GNOME shell the change the way it works like the PopOS guys did?
Well they don't have to make a hard fork, downstreams can just apply a few modifications here and there like Ubuntu currently does. I think Pop!_OS was trying to do too much with a small team and that was where they ran into trouble, I'd expect their progress to be even slower if they try to develop their own desktop.
>Funny, because I use i3wm on an old NAS and KDE apps like Spectacle, Gwenview, and Dolphin work fine and use whatever theme and font I tell them to use
I've also had KDE apps break quite badly with certain themes so I don't really know what you mean they work fine. In my experience KDE apps only work flawlessly when using Breeze, some themes like Kvantum make heavy modifications to the apps and so can cause pretty bad breakage.
>Can't say the same for GTK4 GNOME apps. They're not built to be used outside GNOME because GNOME is now a "platform", which is just doublespeak for a walled garden.
No, KDE and GNOME were both platforms for some time. What that means is they provide certain services and APIs for app developers that you can't get without using those APIs. There is little overlap between them, but that doesn't make them a walled garden. Historically I don't think KDE/GNOME developers have ever spent much time testing KDE/GNOME programs outside their respective desktops. You can try to get them to work in something else like i3wm but it's always been on users of those other window managers to figure out how to integrate it. Why would they bother making a KDE or GNOME app if they don't intend for it to be used with that desktop? You're confusing a walled garden with a simple case of developer intent. A walled garden would be if the app developers were forced to use these APIs, but they are not; it's actually the opposite of that, app developers can use whatever they want and that's why you're having trouble getting something to integrate with another environment. Not every API can integrate with all potential environments.
>It's obvious to me as well — we don't care about GNOME extensions
It's worth noting that blog is one developer's opinion. Tobias is also not a shell developer and does not make decisions for shell developers on what to do about extensions. He is of course free to give his opinion on extensions, as are you.
>It's rather unfortunate that the extension system exists at all.
No, I think it would be worse if there would be no extensions. Then you'd have no way to modify the shell.
>People waste so much time and resources on making elaborate extensions under the impression that their extensions are somehow welcome but then they have to keep fixing them
This is a misconception. Some more complex extensions that modify the shell in complex ways do need to be fixed every release. But a large number of extensions don't need anything more than some minor changes or some testing and a version bump. There is also some efforts to reduce the amount of work needed by extension developers, you can read about it here: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-...
> Your use case seems to be unusual, an old FAQ entry suggests that i3wm users prefer text-based file managers:
This is an old NAS that I don't really use much.
It's true though, I've mostly stopped using GUI apps on my primary workstation except Firefox because of how messy the situation is with GUIs on Linux. GTK wants to enforce its decisions on me and KDE Qt apps don't work well on my Wayland window manager.
> I've also had KDE apps break quite badly with certain themes so I don't really know what you mean they work fine.
I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps. I'm not using Android or iOS so I don't expect to be treated like an idiot.
> You can try to get them to work in something else like i3wm but it's always been on users of those other window managers to figure out how to integrate it.
It's not the uphill battle you're trying to project to make KDE apps work on non-KDE environment. Sure, some themes aren't built well but some are and all I have to do is install Kvantum+qt5ct to make the app look how I want it to. This isn't possible with GNOME and elementary apps because they chose to become their own isolated silos.
> It's worth noting that blog is one developer's opinion.
Is it? The opinions on that article are almost always shared by all the core GNOME developers I've seen commenting on issue trackers. Even the stopthemingmyapp guys resonate those opinions.
Doesn't sound like "one developer's opinion" to me.
> No, I think it would be worse if there would be no extensions.
Judging by the general disdain towards extensions by GNOME developers and many users, I doubt that's the case.
BTW for an example, here is what the KDE system settings looks like for me when I try to run it using qt5ct in GNOME: https://i.imgur.com/pxEKXye.png
I think we can agree that this is unusable, it also appears that it is attempting to load 3 or 4 themes at the same time which are all conflicting with each other. To me, trying to run KDE apps with a GNOME style or GNOME apps with a KDE style has always been a risky endeavor. Perhaps you got lucky running some apps that played nicely with themes but some apps just don't work at all outside their intended environment because they were not designed to use themes.
> BTW for an example, here is what the KDE system settings looks like for me when I try to run it using qt5ct in GNOME: https://i.imgur.com/pxEKXye.png
I don't get why you'd want to run KDE system settings outside KDE. The system settings app also has a lot of optional dependencies. I don't know which distro you're using but if any of those optional dependencies isn't installed, the system settings app misbehaves.
Typically, you'd run apps like Spectacle and Gwenview and Dolphin, standalone apps that serve a purpose, and from my experience, those have always worked on i3wm without issues.
Well again that's great for you that all the apps you use worked, but a lot of the KDE apps I use are broken with some themes :) I'm sure they would work fine in i3wm if you used Breeze but I have had very mixed results on any window manager with qt5ct, some apps play nice with it and some don't. It's not just the system settings that are broken for me, I just picked that as an example. Sometimes it's useful outside of KDE because it's the best way to configure global settings for some KDE apps, not just the shell and window manager. I've looked into it and it has nothing to do with optional dependencies, there are actually just issues with some themes and some apps.
But generally I think it's a bad idea to try to run any KDE apps outside KDE, or any GNOME apps outside GNOME, etc, those apps work much better when used with their respective desktops.
>I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps.
Well you can also use any theme you want on GNOME apps, libadwaita didn't break that, or rather it's just as bad as it is with KDE themes. Some themes will work but other themes will break everything.
>It's not the uphill battle you're trying to project to make KDE apps work on non-KDE environment. Sure, some themes aren't built well but some are and all I have to do is install Kvantum+qt5ct to make the app look how I want it to.
I can't agree here, I have had qt5ct break really badly with some apps and themes. It just doesn't work if the app wasn't designed to use it. I don't even bother with KDE themes anymore and I just use Breeze, if you ask me third-party theming is a total waste of time on any platform. For me it's always broken things or caused very strange glitches.
>I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps. This isn't possible with GNOME and elementary apps because they chose to become their own isolated silos.
Again I honestly have no idea what you're talking about here, GNOME and Elementary apps can still be themed through unofficial third party methods. Developers of apps for those platforms do tend to focus on supporting the official theme for those platforms but that's the same as KDE where developers focus on supporting Breeze.
>I'm not using Android or iOS so I don't expect to be treated like an idiot.
Funny you mention this because I used to have jailbroken Android and iOS phones that were hacked to install third-party themes. The themes were just as broken as with GNOME and KDE. They might work OK with some of the built-in apps but would break quite badly with any third-party apps or when an OS update happened. That was another reason I just stopped trying to use third-party themes altogether.
>Is it? The opinions on that article are almost always shared by all the core GNOME developers I've seen commenting on issue trackers. Even the stopthemingmyapp guys resonate those opinions.
I'm not sure what you mean by core GNOME developers. IIRC Stopthemingmy.app was signed by some independent developers that decided they don't want to support third party themes that break their apps. It's not even related to the shell or extensions. You're conflating several things here. That petition didn't change anything technically about themes, it was a public acknowledgement that themes can break apps badly and that they won't be supporting them, which they never did before anyway.
>Judging by the general disdain towards extensions by GNOME developers and many users, I doubt that's the case.
You may have a biased view, I've heard complaints but the reason they happen is because users really like extensions and want them to stay. I've also heard lots of good things from users and extension developers, it works well when extension developers can test and update their extensions in a timely manner. Besides you can already have that if you want; just don't install any extensions.
> Well you can also use any theme you want on GNOME apps, libadwaita didn't break that
Happy to correct myself but unless there's a supported way to change themes for libadwaita apps using GNOME tweak tool or something similar, this is just doublespeak.
For example, I wasn't able to change the theme of this app using GNOME Tweak Tool the last time I tried.
I think you are misusing the word "doublespeak", I would suggest against using that word. There are some technical reasons why tweak tool will not work anymore but you can still use gtk.css and GTK_THEME, see here: https://blogs.gnome.org/alatiera/2021/09/18/the-truth-they-a...
Worst case it is the same as KDE, you have to set some environment variables and it still may not work correctly with some apps because third-party theming is inherently unreliable. The tweak tool method was also an unsupported third-party thing with most of the same limitations. It has been in a broken state for a while but you probably just didn't notice it because you weren't unlucky enough to end up in a situation where it affected you.
I'd still like to emphasize my other comments though, third-party theming is quite broken on every single platform I've ever used and I suggest against using it if you want to avoid apps randomly breaking. If you plan to continue that route then you may have to get more involved in development to the point where you can fix theme bugs and patch the apps without asking other people for help. That's been my experience with third-party themes anyway, they are essentially hacking the apps and so are not really for average users to mess with.
> The tweak tool method was also an unsupported third-party thing with most of the same limitations.
Interesting, so what was and is the supported first party method to change themes and set keyboard shortcuts and use Emacs keybindings and make the Caps Lock key behave as Esc on GNOME?
AFAIK there has never been an officially supported way to set those in the GNOME GUI and that's true of everything else in the tweak tool including the themes, that's why they're technically in "use at your own risk because this can break everything and mess up your apps" territory. Those are only implemented as hidden settings that the tweak tool modifies. Not sure about other desktops, XFCE might have a GUI to set them.
Interesting, I'll remember this the next time someone tells me to just use GNOME Tweak Tool to use Emacs keybindings or change the theme or keyboard shortcuts because they're unsupported features and maybe disabled anytime without notice, despite the apparent impression most people seem to be under when they use GNOME Tweak Tool.
Yes, you should also remember that when using third-party KDE themes like qt5ct, or hidden KDE settings, or anything else really that wasn't intended by the developer. In my experience with all of those settings, they do work sometimes but with certain apps they can break. That's mostly what unsupported means. I've already said my piece on themes but with keyboard shortcuts, the app can set key bindings that conflict with those and then you'll end up with a broken app again. It's a bad idea to use those settings unless you're willing to revert them at a moment's notice when they break some apps, or unless you're ready to become a developer and fix some of the underlying issues that are causing the breakage.
>despite the apparent impression most people seem to be under when they use GNOME Tweak Tool
I'm not sure what that impression is, GNOME Tweak Tool has always been this way. Other desktops like XFCE can of course expose the setting and make it supported but that's only guaranteed to work with XFCE apps that they've designed to work with that setting.
> Yes, you should also remember that when using third-party KDE themes like qt5ct, or hidden KDE settings
I don't have much skin in the game to be honest because I've given up on using any GUI apps on Linux wherever possible. If I do use GUI apps, I keep looking for ways to quit using them too. The attitude exhibited by GTK and GNOME developers on their issue trackers and the unstable nature of KDE apps on Wayland has made me cynical about GUI on Linux.
I wouldn't know how to differentiate between "supported" and "unsupported" features on GNOME. If basic features like changing keyboard shortcuts are "unsupported" on GNOME, I'm not sure who the target audience of such a DE is, except maybe grandmas, managers, and people with attention deficit issues. Then again, I fail to see why such people would bother with using Linux in the first place.
And yeah, I would use KDE apps but they're almost unusable on swaywm on Wayland so I've stopped using them as well.
I'll focus on creating and using only command line tools and TUIs. Unlike the GUI mess that we have, they are mostly platform independent and can be used almost anywhere.
>The attitude exhibited by GTK and GNOME developers on their issue trackers and the unstable nature of KDE apps on Wayland has made me cynical about GUI on Linux.
I think you're misinterpreting the attitude, or rather that attitude is the same anywhere. GTK and GNOME developers might just be more honest about it, they're fairly limited in what they can do so they can't really fix every single issue on the tracker in a timely manner. That attitude is the same thing with KDE, they have limited time and so can't stabilize things as fast as they'd like. I'd say use Windows or MacOS if you want an OS that is stable and don't want to deal with the limitations of Linux, it's quite far behind on the desktop, and using things like i3wm or swaywm is putting it even further behind because those don't comprise a complete desktop.
>And yeah, I would use KDE apps but they're almost unusable on swaywm on Wayland so I've stopped using them as well.
The problem there is the same, nothing is really native to swaywm or i3wm so you'll probably find that most apps suffer usability issues on them. That's been my experience with third party window managers. If you like KDE apps you probably should use KDE for the most reliable experience.
>I'll focus on creating and using only command line tools and TUIs. Unlike the GUI mess that we have, they are mostly platform independent and can be used almost anywhere.
TUIs have a number of other issues so I can't really suggest those either, you're forgoing a lot by making them. There are no perfect options for platform independent GUIs, everything is a trade off. I would personally suggest making web apps or Electron apps before I would suggest TUIs.
> It can be forked, it can be changed, your freedoms are enforced.
Sure, let's pretend that every user is a programmer who knows what a hard fork is and, even if he is a programmer, he's willing to create hard forks of each and every GNOME software he uses to support features that worked before and don't work now. This has worked out great for PopOS and Budgie right?
It's so much easier to just fall back on the open source argument and ignore the fact that it means nothing for the average user who doesn't know the first thing about C code or git to be able to make the changes he wants to.
It's not clear what you're talking about because there isn't a reality where this does whatever you want without programmers working on it. Average users are always going to need help from them, regardless of whether it's upstream or a hard fork. That choice also doesn't seem to be relevant to Pop!_OS and Budgie because for them it was a choice between hard fork or start from scratch, which is primarily a technical choice which needs experienced programmers either way.
There are multiple ways to get that though. One of them would be if a lot of hard forks existed, then you'd have a lot of options to choose from. Or those developers can contribute upstream and work on adding tons of options to the upstream project. My point is that there isn't a world where you just get the choice and options out of thin air without programmers, eventually someone has to program the options in somewhere or they just won't exist.
Honestly, I think they are going in the right direction.
The main problem with the Linux desktop has always been the insane fragmentation in my opinion. There's a million different options for every little thing and so developers don't have a platform they can count on and their option is to either provide reduced functionality (no integration with the desktop environment) or support a bunch of different things. And users don't get a polished JustWorks(TM) desktop experience.
> even distros like NixOS encourage users to use GNOME, which is absolutely insane when you think about it.
? NixOS doesn't have a default desktop environment. At the same time, the graphical installation media images have always come with Plasma as long as I can remember, and the example desktop environment commented out in the template given by nixos-generate-config has likewise always been Plasma.
Wow! I can't believe I've never noticed that. For many years, the only graphical installation disk was based on Plasma, and I think it also had that tag. NixOS only started shipping a GNOME iso for installation purposes a little over a year ago (for 20.09), and I kinda never noticed.
Looks like the main reason GNOME is recommended for installation media at the moment is that it does a better job of autodetecting HiDPI displays, and then scaling appropriately: https://github.com/NixOS/nixos-homepage/pull/643
There are also some packaging issues for Qt with NixOS, because Qt plugins fundamentally rely on ‘impurity’ at runtime, and the Qt framework makes promises it doesn't keep about binary compatibility.
Here are some of the relevant issues for historical context and some of the tradeoffs Nixpkgs developers have faced when it comes to handling Qt and KDE packaging:
I realize that may not be a fully satisfying answer as to why the GNOME-based installation graphical ISO is recommended over the Qt one because one can imagine that the Qt packaging issue should be resolved some other way, or see the difficulty of packaging Qt plugins and applications in Nixpkgs as fundamentally a Nix defect. But I hope it makes that decision make more sense.
FWIW, afaict Plasma is the more popular of the two major DEs on NixOS, and it's what I've always used on NixOS myself, including now. It is definitely usable.
> But I hope it makes that decision make more sense.
It does but it's rather unfortunate that the only choice we have when it comes to DEs is either GNOME, which is built by a group of arrogant developers who think there is no downstream for GNOME and GTK, and KDE, which has technical issues that prevent widespread adoption.
I think you're misinterpreting decisiveness as arrogance. GNOME developers would probably like to respond to more of them but they can't because of lack of developers, so they have to make tough decisions about what to support. When downstreams don't handle some of the burden then it's a loss for everybody. KDE also does not really like or benefit from having a ton of downstream forks either, the project is way too large and it's more useful to get upstream contributions. Maybe it would be better if there were more choices, but nothing is perfect. You and I could probably find more things to complain about in any third/fourth/fifth choice.
>and KDE, which has technical issues that prevent widespread adoption
Which KDE technical issues are preventing its adoption? I'm running KDE full for a long time and encountered no issues.
IMHO, the lack of KDE adoption is the inertia of GNOME adoption by the major distros combined with the inertia of hate over KDE with the stereotype that "it's bloated" which hasn't really been the case in the last versions of Plasma.
> Which KDE technical issues are preventing its adoption? I'm running KDE full for a long time and encountered no issues.
Some of them are linked by pxc post above mine.
There's also the issue that Qt apps can only be written in C++, a language that many don't want anything to do with. In comparison, GTK has bindings for a variety of languages including Rust.
>In comparison, GTK has bindings for a variety of languages including Rust.
Are those good bindings , or auto-generated or outdated ones ? I did not checked in a long time but I think only Python had decent bindings. I would avoid non-official bindings, those are most of the time garbage and you waste your time instead of focusing on your work.
I seen Qt in a lot of proprietary applications, including launchers for video games (the app that will let you setup a game configuration before launch) - I was surprised why a Windows only video game would not use the Windows APi directly, but it is obvious that Qt is better then whatever Windows has this days for c++ devs and game devs are not afraid of a bit of c++ or have some irrational disgust for Qt pre-procesor (I see this excuse all the time, we don't switch from GTK to Qt because of the qmake/moc I honestly prefer an honest explanation)
I guess this is just my opinion but NixOS is probably the most esoteric Linux distribution I've used. Anyone who intends to use NixOS comfortably probably isn't apprehensive about configuration and customization, things which are the antithesis of everything GNOME stands for.
I fail to see why GNOME, or any DE for that matter, is something that should be recommended by a distribution like NixOS.
Being the default and thereby “recommended” desktop in NixOS a lot different than in other distro’s.
In other distro’s, to get a non-default desktop, you have to download a whole different distro “spin”, like Kubuntu. Or add the new desktop packages and manually configure them all.
With NixOS you use the same install image, and just change two or three lines in the master configuration.nix file, and re/build. You can change back and forth between DE’s that use different window managers with a reboot, or between DE’s that use the same window manager with a relog [3].
Most the major desktops are supported in NixOS [1][2]. Gnome being the default means little, is easy to change should NixOS community ever form a consensus about changing the default (say in response to Gnome crossing some line), and is easy for end users to change any time.
on ubuntu, and then select cinnamon at the login screen after booting, and it'll work just fine. same for mate, plasma, etc. Same for debian, and most linux distros I've tried. installing another desktop isn't difficult at all, usually
Debian (and Ubuntu as a result) has "task-*-desktop" tasks (meta-packages) which install, configure and tune the whole distro for a new/additional desktop environment too.
Right, and I'm pretty sure you can use the same display manager with both (at least if it's lightdm), and then switching back and forth between gnome and KDE is literally a matter of switching between the words "gnome" to "plasma5" in one place.
> Just because you disagree with them, it doesn't make them the "bad guys".
Since the KDE 3.5.x days, it's always KDE guys who try to build corresponding GTK themes of the themes they default on the corresponding release, or build corresponding Qt themes of the GTK themes put forward as default by the GNOME guys.
Moreover, there are always ways to make GNOME subsystems work well on KDE systems, and KDE guys always make sure that the standards they propose work with the GNOME without much hassle. Also, KDE guys put forward cross-DE ways to make user experience better (XDG base folder specification, for example).
OTOH, GNOME people sit on their high thrones like they're the only game in town. I respect them deeply, but I can't appreciate them just because they auto-generated their JS introspection layer from C code automatically, but didn't bother to write any documentation, because you can try it all in the built-in JS console.
I have a couple of more, lower level stories with them, which caused a lot of all-nighters and project postponements, but that's for another comment.
What actually makes them the bad guys is that they parlayed the goodwill of the original GNOME (2 and prior) which was very open to change and community contribution into the restrictive community hostile thing that it is today.
I don't mind that it exists, but they should have changed the name and been more clear about the direction.
a. Their development team was more professional (locking threads when feedback starts coming in, making offhand derogatory comments about people's reading comprehension skills, trying to minimize serious problems to avoid dealing with merge requests/more work, blaming downstream actors like PopOS! for simply using their software and disagreeing with their ethos, etc.)
b. They used their funding to actually fix issues (GTK4 still has text rendering issues. 8 months later. Insert obligatory "thumbnail file picker" comment here)
c. They didn't regress features that previously worked (No more extensions, no more desktop tweaks, overall fewer settings in new releases, design upgrades that are decidedly opinionated)
d. They didn't treat their opinions as gospel (eg. encouraging Flatpak-or-die culture when Flatpak itself is still in it's infancy and wildly unstable, going out of their way to obfuscate theming interfaces, having "one guy" come up with a new design for something and implementing it before the community decides if it's something they want)
Yeah, I think I am comfortable calling them "the bad guys" in the current landscape of Linux. GTK's team is still fine (barely) but the overall effort to combine the two, add middleware like libadwaita, move fast and break things, and blame it on the user when things stop working is just getting to be asinine.
They can have a vision if they want, but it shouldn't have to come at the expanse of the rest of the community. That's how you burn goodwill.
Really? Isn't GTK where the CSD (client side decoration) is being forced onto every app, with no way to use native/normal window manager borders? It seems rather widely despised:
That's more of a GNOME effort, if I'm being honest. It's a feature that's provided via GTK's libraries, but the whole "we're going to add CSD and you're not going to do anything about it" has been more of a GNOME sentiment[0].
App developers will design their apps in a certain way and will add features that they think benefits the app. Some will add CSD if they think it's beneficial and others won't. What is it that you would want to do about that? That's always been how it is. If you were in charge of designing the app then you'd be the one going to meetings and writing the code.
The app developer gets to choose what decorations they support. Some app developers will choose to only support a certain type of decorations; that's an intentional design decision made as part of the app. In the past, GNOME app developers have chosen to use CSD and XFCE developers didn't, but there seems to be a shift from them towards CSD too. I've also seen some XFCE users saying they like the CSD.
>I prefer it, been a CSD user since before CSD itself, with Winamps rolled up UI.
That is it, but somehow you don't see it??? I mean is so obvious///
You could have Winamp or you could have an application with a window in the form of a circle but this days GNOME decided that you can ONLY have CSD and old apps that use SSD or non-GNOME apps that use SSD should switch to SSD... so you ahve 2 issues
1 GNOME is removing the option to have both SSD and CSD , and forces you into CSD only
2 GNOME does not provide(maybe things changed and someone forced those arrogant bastards to support some legacy app that RedHat needs) any support for SSD apps.
I don't understand how you're having those issues. GNOME has never had the option to have both CSD and SSD. When GNOME apps used GTK2, SSD was the only option. When GNOME apps started moving towards GTK3, CSD became the only option. What you're asking for is a new feature because GNOME never supported both.
Legacy apps using X11 will use the legacy X11 decorations. Those should still work. For Wayland apps, those were never working correctly if they didn't support CSD. What you're again asking for is a new feature, there are no legacy Wayland apps that will depend on that functionality because it never existed in GNOME Wayland.
> SSD was the only option. When GNOME apps started moving towards GTK3, CSD became the only option. What you're asking for is a new feature because GNOME never supported both.
Really? , You should just hide the Window titlebar , and paint your own CSD, titlebars were not forced on you https://developer.gimp.org/api/2.0/gtk/GtkWindow.html#gtk-wi... , this is how for example splashscreens are implemented or fancy non rectangular windows , but to be honest I am not 100% sure if GNOME2 was also an asshold and disabled this GTK feature just to be spacial, if you can confirm then let me know if I am right then you need to acknowledge the fact that SSD was not forced on you(not Qt,not GTK, not even Windows/OSX forced SSD on you )
Sure, the feature existed in GTK but what I mean there is that GNOME 2 apps didn't use that. They never painted their own CSD. Sure some apps did for splash screens but not for ordinary app windows. Then when GNOME 3 happened they all redesigned their apps to only use CSD. They didn't implement SSD in Wayland because it wasn't part of the design and by then all the GNOME 2 apps were already gone anyway. That API is even still present in GTK4, the reason you saw a change is because the apps (the callers of the API) changed how they use it.
But the issue we have with GNOME is not that they changed their own apps to CSD,
the issue is that their Window Manager does not paint the SSD for non-GNOME app, I hope this is clear now or let me try to simplify it
Before
- you could have both CSD and SSD application run on GNOME
After
- you are FORCED to implement CSD on GNOME because their Window Manager will not paint the SSD for you, even for old application that existed before GNOME3 was created.
It would make sense for GNOME to support this old applications or toolkits that do not implement CSD , I really hope sanity will prevail over designer ego (it happened at Apple so there is a chance it will happen at GNOME after a few years of feedback)
>you are FORCED to implement CSD on GNOME because their Window Manager will not paint the SSD for you, even for old application that existed before GNOME3 was created.
No, this is not true at all. Old applications and toolkits that existed before GNOME 3 was created will use X11, and the legacy decorations will still work there.
>No, this is not true at all. Old applications and toolkits that existed before GNOME 3 was created will use X11, and the legacy decorations will still work there.
OK, good news then for old apps and games , is there a solution ready for new applications like Qt,Electron ones that were not created for GNOME? Can you resize them on Wayland or you are forced on X11 ? If you do not use Wayland is he Window Manager still implementing the SSD or they removed the code (I think I read something about code getting removed but I am might be thinking about something else).
So my question if I were to test GNOME+Wayland will this work correct:
1 old games , games that use DOXbox or emulators
2 new games in Wine or native
3 Qt or other apps like Intellij,Thunderbird, Visual Studio Code, VLC, Slack (does GNOME still has no system tray for Slack/email clients ?)
4 is GTK still recommended for cross platform development? isn't cross platform support and GNOME design in a contradiction? any such example of a cross platform GTK4 complex application
I am sorry if my knowledge is a bit outdated, I am no longer reading Linux news ,podcasts or Linux reddits (I got tired about reading all the small drama stuff, the big news will reach me somehow anyway)
2. Wine apps will probably have to draw the win32 decorations. Native apps can implement their own decorations or can use GTK or Qt to draw their decorations.
3. Qt does have its own CSD decorations, VLC should be able to use that. Intellij is a Java app so I'm not sure about that one but Thunderbird should use GTK decorations. The rest are Electron apps and Electron has a PR open for CSD: https://github.com/electron/electron/pull/29618
A system tray can be added to GNOME with an extension.
4. GTK is not a cross platform toolkit like Qt where it tries to draw everything with native widgets, but it is a portable toolkit meaning that you can port applications to other platforms and they will more or less look the same. I don't know anyone using it ship Windows applications, some improvements have been made to get it working better on Windows though: https://www.collabora.com/news-and-blog/blog/2021/03/18/buil...
OK, so I am not doing any desktop app development this days but if I will do I will not write any special code for GNOME.
> GTK is not a cross platform toolkit like Qt where it tries to draw everything with native widgets
Just a correction, Qt does not use native widget, they have code that will adapt and paint the thigns too look and work as native widgets, so for example they have button groups that when you use it say for OK-Cancel buttons it will change it to Cancel-OK on different platforms (some platforms have the order reversed). Also Qt will paint the OK/Cancel button icons on KDE but not on Windows/GNOME . So in fact Qt devs put the effort in and wrote code and themes to get things look native, use the native file dialogs, use the native notifications, system tray, the native paths etc (not ike the other toolkit that doesn't care about integration, theming and configuration)
a. Some discussions become the target of trolling and it's necessary to lock threads, unfortunately it happens sometimes. If somebody has made a rude comment then you may want to report that as a code of conduct violation. The developers are volunteers and don't have infinite time to handle all the work that's thrown at them. The disagreement with Pop!_OS was disappointing but I don't know who else you can blame for that, if Pop!_OS wants to go their own way then that is completely their decision. They aren't forced to contribute upstream and I'd say that's good for them and their goals.
b. There isn't really any funding to pay to fix those issues. They're being fixed by volunteers, so progress is slow.
c. I have no idea what this means, extensions are still there.
d. There are issues with Flatpak but all the other options are worse and are more unstable. Before Flatpak, there was just no way for upstream developers to make an "official" packaging for apps. The theming interfaces haven't really changed because those didn't really exist, those were a hack for the entirety of GNOME 3. Having one person implement a design and then gather feedback on it from the community is how open source works. If the community wants it then they'll use it, if they don't then they'll use something else. I'm confused how else you'd expect it to go. Talk is cheap, putting working prototypes in front of the community and then gathering feedback from there is what gets things done.
I also don't really understand why you're saying this makes them the bad guys or comes at the expense of the rest of the community. Like, none of this affects KDE. KDE has their own middleware libraries and makes their own changes. They don't depend on any GNOME libraries. Even XFCE that depends on some libraries like GTK doesn't really have to deal with any of this. GNOME's issues with extensions don't affect them at all because they don't use the GNOME shell, they can package their apps with whatever they want and they don't have to use Flatpak, they probably won't use libadwaita or if they do they'll heavily modify it, etc.
>Just because you disagree with them, it doesn't make them the "bad guys".
I was replying on the consistency topic. some projects offer the user a consistent experience by offering both Qt/GTK support and others don't care and would rather force their branding on you.
As much as I think that GNOME is a joke at this point (and has been for well over a decade), is that really such a bad thing that they focus on supporting their graphical toolkit of choice?
Besides, the real solution here is for developers to switch to QT and stop using GTK. ;)
Qt, unfortunately, by nature of being C++, is much harder to link into a different language. GTK is a plain C API. So, if you’re using plain C, Rust, C#, etc, it’s a heck of a lot easier to use GTK than Qt.
The thing is that GNOME project and GNOME based distros should put just a bit of effort to support Qt programs, like have the same File Picker Dialog or even have GTK2 and GTK3 use the same fucking File Picker or at least with the same fucking File Sorting.
About easy of use I am sure that you are more productive with a professional toolkit like Qt and a mature language like c++ then fucking around with some broken/incomplete/buggy C# or Rust GTK bindings. Though I think you can do simple Python apps with GTK GUIs but for professional applications that are targeting crossplatform trust me Qt is the solution (I never seen a good GUI cross platform pro application , Linus Torvalds himself used Qt for his app because his Red Hat friends could not answer him on how to do some complex GUI in GTK)
This is a recent development and that was designed to support GNOME/RedHat's flatpack , we should not get tricked to believe GNOME would have done this for helping someone else then themselves(do they support this in GTK2 apps too?, I really hate having different file choser with different sorting order of files and folders)
It probably cannot be done automatically in GTK2 apps because of API differences. GTK2 apps could call the portal API manually or put the functionality in another library.
>we should not get tricked to believe GNOME would have done this for helping someone else then themselves
Well they actually did, the flatpak API was designed to support multiple toolkits.
Consistency is important but is not like the majority of the apps are GTK3 (or whatever is latest) with the GNOME styles even if those GNOME designers pretend nothing else exists and nobody should remove the GNOME branding from the GNOME apps.
Just want to mention that GNOME are the bad guys, KDE distributions will provide GNOME integration with packages and themes that attempt to keep Qt and GTK application consistent in look and feel but I never seen GNOME distros attempt to integrate with the non-GNOME apps.