6 ms·

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

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

_2paq 5y ago
> 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-4/ https://blogs.gnome.org/tbernard/2021/07/13/community-power-...
- shatteredgate 5y ago
  >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-manager-for-i3wm.1.html 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-rebooted-initiative/ https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-...

_2paq 5y ago

> 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-4/ https://blogs.gnome.org/tbernard/2021/07/13/community-power-...

shatteredgate 5y ago
>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-manager-for-i3wm.1.html 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-rebooted-initiative/ https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-...