Hacker News Reader

Comment by _2paq | Hacker News Reader

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.

View on HN

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

That is an issue, not a feature.

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

[^1]: https://blogs.gnome.org/tbernard/2021/07/13/community-power-...

>I mean, what is that even meant to convey?

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

That's true you can get them to work but they're not ideal. Your use case seems to be unusual, an old FAQ entry suggests that i3wm users prefer text-based file managers: https://faq.i3wm.org/question/92/what-is-recommended-file-ma...

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.

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

https://gitlab.gnome.org/World/Shortwave

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.

It was nice talking to you. Thanks for your time.

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

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.

>which is just doublespeak for a walled garden.

This is horse shit at best, social espionage at the other end. You are intentionally misusing this term.

Your data and the source can be used in any way you as the user sees fit.

It can be forked, it can be changed, your freedoms are enforced.

> 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 isn't a reality where this does whatever you want

I wish something called user choice and configuration options existed in this reality.

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.

One is a world where its possible and legal. The other is where it's not legal and very difficult.

Sucks that end users can't "hard fork" and fix their shit, but I can't fix planes either, we all pay for our choices.

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.

I'm taking about the "Recommended for most users" tag for the GNOME ISO.

https://nixos.org/download.html#nixos-iso

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:

https://github.com/NixOS/nixpkgs/issues/86369

https://github.com/NixOS/nixpkgs/pull/54525

https://github.com/NixOS/nixpkgs/pull/44047

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.

>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 get the impression that GTK+'s Vala and Python bindings are good. Idk about Rust

I thought Vala was pretty much dead and not recommended for new apps/extensions at this point?

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.

I don’t know the intricacies of the politics at play here, so could you explain why this is “insane”?

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.

——

# Gnome

services.xserver.enable = true;

services.xserver.displayManager.gdm.enable = true;

services.xserver.desktopManager.gnome.enable = true;

——

# KDE

services.xserver.enable = true;

services.xserver.displayManager.sddm.enable = true;

services.xserver.desktopManager.plasma5.enable = true;

——

[1]:More info: https://nixos.org/manual/nixos/stable/index.html#sec-x11

[2]:Supported desktops: https://search.nixos.org/options?channel=21.11&from=0&size=5...

[3]:https://www.reddit.com/r/NixOS/comments/otnfq6/i3_or_sway_wh...

I wasn't questioning NixOS's customisability. I was questioning the choice to promote GNOME as "recommended for most users" on the download page.

https://nixos.org/download.html#nixos-iso

There's no need for a distro like NixOS to do this. It only serves to lend weight to the arrogance displayed by GNOME.

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.

all you have to do is e.g.

sudo apt-get install cinnamon

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.

Reply on news.ycombinator.com