5 ms·

For me, it's very simple. There are certain things that I must have in a desktop environment (DE) --- for example, having a 3x3, 2-dimensional workspace. As

by tytso 5y ago

For me, it's very simple. There are certain things that I must have in a desktop environment (DE) --- for example, having a 3x3, 2-dimensional workspace. As far as a DE is concerned, I want to be a user of the DE, not a developer of the desktop environment. The problem is that the extension API is fundamentally unstable, and so extensions which provide the functionality that I consider a must-have, are unreliable, and may break in future versions of GNOME. I don't want to be in the position of debugging an extension which stops working in a future version of GNOME. I may be a kernel programmer, but as far as the desktop environment is concerned, I just want to be a user of it. And if an extension breaks, and I have to figure out which other extension might have the feature that I want, but which might require painful configuration somersaults after successive new GNOME versions, the answer is very simple. I'm just going to say, "No Thanks". KDE/Plasma supports what I consider to be fundamental key functionality, and I don't have to mess with it. And so GNOME is just not for me. If it works for you, great! But an extension API which is not stable, and when what I consider core functionality can only be provided by extensions which are resting on top of quicksand, is not going to be persuasive answer.

zxzax 5y ago
Hi Ted, thanks for responding. The extension API is similar to the kernel's driver API, with the same caveats -- you can use it externally, but you need to track upstream for breaking changes, because upstream is always going to need to have the ability to refactor and deprecate things, otherwise they get stuck maintaining deprecated/crufty APIs forever. And yes, I am suggesting that making a stable extension API for the shell would probably be about as difficult as making a stable Linux driver API. There is not really any consensus on what a GUI shell is supposed to look and act like, as you can probably tell from all the arguments all over the years. If KDE has a solution to this problem in the works, I'd love to hear about it, but AFAIK this is not solveable with code, because it's a headcount problem, not a technical one. Otherwise my suggestion would be the same as the kernel developers say to someone using out-of-tree drivers: either get your extension upstreamed, and deal with the long review process from the shell developers, and be prepared to explain in extreme detail why you need 2d workspaces and why it's worth it to have upstream maintain that... or just don't update your shell until the extension gets updated. This isn't really a Gnome specific problem either if you ask me, I haven't seen any desktop compositors for Linux that are active and offering a fully complete and stable API, because turns out it's not an easy thing to do.
- tytso 5y ago
  KDE has solved the problem for me by providing 2-D workspace as a core feature, and not relegating it to the slums of "you want it, write your own d*mn extension". GNOME has chosen not to do this. And so, GNOME is not for me, because I consider a 2-D workspace a "must have" feature. And so I will choose KDE over GNOME, because as a user (and I'm not interested in becoming a Desktop developer, sorry; I'm also not a web browser developer, or word processor or spreadshet developer, either. We can't be developers for everything), KDE meets my needs as a user. GNOME does not. My main complaint with GNOME is that their answer for "you don't support feature X" is not, "yeah, sorry, we have an opinioned design, and go f*ck off", but rather, "Stop complaining, we have an extension for that". And so they don't understand that unstable extensions is not an answer to a user complaint that a feature doesn't exist. If they don't want to support a feature, that's fine. But don't try to use the lame excuse, "there's an extension for that", since they don't want to admit that they are asking users to rely on something that will randomly break. If someone wants to use ZFS, I'll tell them that this is not supported by Linux. If you really want ZFS, use Illumos or FreeBSD. If you use Linux with ZFS, and it breaks, that's not my problem, and I'll be first to disclaim that Linux support ZFS. Because it really doesn't. There may be 3rd party developers who are trying to make that work, but I would never recommend to a user that they use Linux/ZFS, since if they need newer hardware support which is in a kernel not supported by Linux/ZFS, or their distribution has updated their default kernel to a version that doesn't support Linux/ZFS, they shouldn't come complaining to the Linux kernel community. Unfortunately GNOME is trying to have things both ways.
  - zxzax 5y ago
    That's great, I support you using KDE. But the fact is, if you really wanted that feature in core Gnome, someone would have to advocate for it, implement it, and then get that feature upstreamed, and then someone will have to maintain it upstream, indefinitely. An alternative to that would be for someone to write the extension, and then maintain it by tracking upstream, indefinitely; both are about the same amount of work. So it's not clear to me why you're complaining about having to write your own extensions -- this is just how open source works. You have to do the same thing in KDE if you decide you want to add some new non-default functionality that doesn't exist there too. It's not any different because it's a desktop and not a kernel, or a web browser, or a spreadsheet, or whatever. I'm happy that you could use KDE and that it works for you, but from my perspective Gnome is not doing anything weird or strange that KDE is not doing, other than having a different default design of what workspaces are supposed to be.

by tytso 5y ago

zxzax 5y ago

Hi Ted, thanks for responding. The extension API is similar to the kernel's driver API, with the same caveats -- you can use it externally, but you need to track upstream for breaking changes, because upstream is always going to need to have the ability to refactor and deprecate things, otherwise they get stuck maintaining deprecated/crufty APIs forever. And yes, I am suggesting that making a stable extension API for the shell would probably be about as difficult as making a stable Linux driver API. There is not really any consensus on what a GUI shell is supposed to look and act like, as you can probably tell from all the arguments all over the years. If KDE has a solution to this problem in the works, I'd love to hear about it, but AFAIK this is not solveable with code, because it's a headcount problem, not a technical one. Otherwise my suggestion would be the same as the kernel developers say to someone using out-of-tree drivers: either get your extension upstreamed, and deal with the long review process from the shell developers, and be prepared to explain in extreme detail why you need 2d workspaces and why it's worth it to have upstream maintain that... or just don't update your shell until the extension gets updated. This isn't really a Gnome specific problem either if you ask me, I haven't seen any desktop compositors for Linux that are active and offering a fully complete and stable API, because turns out it's not an easy thing to do.

tytso 5y ago
KDE has solved the problem for me by providing 2-D workspace as a core feature, and not relegating it to the slums of "you want it, write your own d*mn extension". GNOME has chosen not to do this. And so, GNOME is not for me, because I consider a 2-D workspace a "must have" feature. And so I will choose KDE over GNOME, because as a user (and I'm not interested in becoming a Desktop developer, sorry; I'm also not a web browser developer, or word processor or spreadshet developer, either. We can't be developers for everything), KDE meets my needs as a user. GNOME does not. My main complaint with GNOME is that their answer for "you don't support feature X" is not, "yeah, sorry, we have an opinioned design, and go f*ck off", but rather, "Stop complaining, we have an extension for that". And so they don't understand that unstable extensions is not an answer to a user complaint that a feature doesn't exist. If they don't want to support a feature, that's fine. But don't try to use the lame excuse, "there's an extension for that", since they don't want to admit that they are asking users to rely on something that will randomly break. If someone wants to use ZFS, I'll tell them that this is not supported by Linux. If you really want ZFS, use Illumos or FreeBSD. If you use Linux with ZFS, and it breaks, that's not my problem, and I'll be first to disclaim that Linux support ZFS. Because it really doesn't. There may be 3rd party developers who are trying to make that work, but I would never recommend to a user that they use Linux/ZFS, since if they need newer hardware support which is in a kernel not supported by Linux/ZFS, or their distribution has updated their default kernel to a version that doesn't support Linux/ZFS, they shouldn't come complaining to the Linux kernel community. Unfortunately GNOME is trying to have things both ways.
- zxzax 5y ago
  That's great, I support you using KDE. But the fact is, if you really wanted that feature in core Gnome, someone would have to advocate for it, implement it, and then get that feature upstreamed, and then someone will have to maintain it upstream, indefinitely. An alternative to that would be for someone to write the extension, and then maintain it by tracking upstream, indefinitely; both are about the same amount of work. So it's not clear to me why you're complaining about having to write your own extensions -- this is just how open source works. You have to do the same thing in KDE if you decide you want to add some new non-default functionality that doesn't exist there too. It's not any different because it's a desktop and not a kernel, or a web browser, or a spreadsheet, or whatever. I'm happy that you could use KDE and that it works for you, but from my perspective Gnome is not doing anything weird or strange that KDE is not doing, other than having a different default design of what workspaces are supposed to be.