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