6 ms·

I'm sorry, please don't assume bad faith, I'm not refusing. I just don't understand how opening a configuration dialog and doing a couple clicks to install an e

by zxzax 5y ago

I'm sorry, please don't assume bad faith, I'm not refusing. I just don't understand how opening a configuration dialog and doing a couple clicks to install an extension that changes the panels, is different from opening another configuration dialog and making a few clicks to change the panels. It seems exactly the same to me. I don't have any preference towards either of these, I'm just interested to hear why it doesn't work for you.

Nursie 5y ago
Well, because I'm having to install third party pieces which may or may not break stuff, may or may not be supported for long, may or may not break on the next update, in order to achieve a base level of configurability which it seems like DE designers don't want you to have in the first place. Maybe they fixed things in the last few years, I have no idea, but last time I had to use Gnome 3 it broke existing DE muscle memory of using all sorts of environments across all sorts of platforms, and made it hard to discover how to change anything. Having to then install third party pieces to achieve minor change is not something I feel is an adequate replacement, particularly coming from systems where easy, built-in configurability comes as standard. Again, if that all sounds fine to you, more power to you. To me it's an opinionated DE that tries its best to push its own ideas of usage on the user, and hides any/all options behind an API rather than exposing them to the user by default. Why would I bother with such a DE when I can find one that supports what I want to do out of the box?
- zxzax 5y ago
  >having to install third party pieces which may or may not break stuff, may or may not be supported for long, may or may not break on the next update Right, so that is a problem, but it's a different problem from lack of configurability. Those things are being addressed in other ways such as with the extension rebooted initiative: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-rebooted-initiative/ https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-... You're making a distinction of "third party" here but I don't understand why that really matters for configurability, for example it's no different from installing an unoffical XFCE panel applet, or using a third party file manager, etc. In the gnome shell, the extension API is built-in and standard. That is the configurability. If you're asking for specific panel settings to be included by default, that really isn't possible in a way that would please everyone -- you can look at the sheer number of panel extensions there are to see why that is the case. Again someone could make one to make it look and act exactly like XFCE's panel, but that would just be yet another option. Does that explain it? It's not really possible for the shell to act the way you're asking. I support you using XFCE if that's what you want, but if you're asking for changes to be made in Gnome, those could probably not be made without causing much worse breakage. If you're not asking for that, then never mind, I misunderstood :)
  - Nursie 5y ago
    > Right, so that is a problem, but it's a different problem from lack of configurability Lack of out of the box configurability, lack of ease of discovery of configurability, lack of dependability on third party pieces (which may be essential to my workflow, that third party widget in Xfce isn't). That initiative looks like a good move, I don't mean to disparage that. > In the gnome shell, the extension API is built-in and standard. That is the configurability. And that's not a good mechanism for me, as discussed. > If you're asking for specific panel settings to be included by default Yes, that's specifically my preference, for a system the user can configure, easily/out of the box, without relying on third parties to patch some really simple stuff back in. > It's not really possible for the shell to act the way you're asking. I'm not asking the shell to act any particular way, nor am I asking for changes in Gnome. I have had no real interest in Gnome since the 2->3 transition and this approach is part of that.
    - zxzax 5y ago
      >Yes, that's specifically my preference, for a system the user can configure, easily/out of the box, without relying on third parties to patch some really simple stuff back in. I personally would describe that approach as actually more lacking in configurability, because with that you're limited to only the built-in settings. In my opinion all those could be improved with further improvements the extension system. In general I also see the line between "third party" as being blurry in these open source projects, because any random person can contribute something. But in the end, you deserve to use something that is to your preference. >I'm not asking the shell to act any particular way, nor am I asking for changes in Gnome. Sorry, I guess I'm confused as to why you'd be talking about technical issues with GNOME, if it's been totally irrelevant to your interests for the last 10 years, and you don't even use it. If you're not interested to give constructive feedback or try to fix the issues, or try to describe different ways of achieving your workflow, then I would say I'm not really interested to discuss complaints about these things.
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.

by zxzax 5y ago

Nursie 5y ago

Well, because I'm having to install third party pieces which may or may not break stuff, may or may not be supported for long, may or may not break on the next update, in order to achieve a base level of configurability which it seems like DE designers don't want you to have in the first place. Maybe they fixed things in the last few years, I have no idea, but last time I had to use Gnome 3 it broke existing DE muscle memory of using all sorts of environments across all sorts of platforms, and made it hard to discover how to change anything. Having to then install third party pieces to achieve minor change is not something I feel is an adequate replacement, particularly coming from systems where easy, built-in configurability comes as standard. Again, if that all sounds fine to you, more power to you. To me it's an opinionated DE that tries its best to push its own ideas of usage on the user, and hides any/all options behind an API rather than exposing them to the user by default. Why would I bother with such a DE when I can find one that supports what I want to do out of the box?

zxzax 5y ago
>having to install third party pieces which may or may not break stuff, may or may not be supported for long, may or may not break on the next update Right, so that is a problem, but it's a different problem from lack of configurability. Those things are being addressed in other ways such as with the extension rebooted initiative: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-rebooted-initiative/ https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-... You're making a distinction of "third party" here but I don't understand why that really matters for configurability, for example it's no different from installing an unoffical XFCE panel applet, or using a third party file manager, etc. In the gnome shell, the extension API is built-in and standard. That is the configurability. If you're asking for specific panel settings to be included by default, that really isn't possible in a way that would please everyone -- you can look at the sheer number of panel extensions there are to see why that is the case. Again someone could make one to make it look and act exactly like XFCE's panel, but that would just be yet another option. Does that explain it? It's not really possible for the shell to act the way you're asking. I support you using XFCE if that's what you want, but if you're asking for changes to be made in Gnome, those could probably not be made without causing much worse breakage. If you're not asking for that, then never mind, I misunderstood :)
- Nursie 5y ago
  > Right, so that is a problem, but it's a different problem from lack of configurability Lack of out of the box configurability, lack of ease of discovery of configurability, lack of dependability on third party pieces (which may be essential to my workflow, that third party widget in Xfce isn't). That initiative looks like a good move, I don't mean to disparage that. > In the gnome shell, the extension API is built-in and standard. That is the configurability. And that's not a good mechanism for me, as discussed. > If you're asking for specific panel settings to be included by default Yes, that's specifically my preference, for a system the user can configure, easily/out of the box, without relying on third parties to patch some really simple stuff back in. > It's not really possible for the shell to act the way you're asking. I'm not asking the shell to act any particular way, nor am I asking for changes in Gnome. I have had no real interest in Gnome since the 2->3 transition and this approach is part of that.
  - zxzax 5y ago
    >Yes, that's specifically my preference, for a system the user can configure, easily/out of the box, without relying on third parties to patch some really simple stuff back in. I personally would describe that approach as actually more lacking in configurability, because with that you're limited to only the built-in settings. In my opinion all those could be improved with further improvements the extension system. In general I also see the line between "third party" as being blurry in these open source projects, because any random person can contribute something. But in the end, you deserve to use something that is to your preference. >I'm not asking the shell to act any particular way, nor am I asking for changes in Gnome. Sorry, I guess I'm confused as to why you'd be talking about technical issues with GNOME, if it's been totally irrelevant to your interests for the last 10 years, and you don't even use it. If you're not interested to give constructive feedback or try to fix the issues, or try to describe different ways of achieving your workflow, then I would say I'm not really interested to discuss complaints about these things.

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.