zxzax

I think the suggestion there would be to find someone who is willing to maintain the extension when upstream does a new release.

Please don't assume bad faith. Extensions can be a solution to some problems, but they're obviously not perfect -- I'm not saying they are.

>The problem is that there are huge numbers of dependencies, and if you hold back on updating GNOME Shell, you can't update a potentially huge number of other packages, and you risk your desktop or laptop installation becoming unstable.

So just to be clear, that same problem propagates to upstream, which is exactly why the extensions break. If they wanted the extensions to not break so much, the alternatives there that upstream has would be:

- Hold up the release so that everyone gets a chance to update their extensions. This causes sweeping problems because now everything else is delayed if an extension developer is slow, and this may not even help if the extension developer has truly vanished, because then nobody will be around to update the extension. Gnome switched to time-based releases a long time ago to get away from those problems.

- Merge the extension upstream. There are a large number of extensions, and some of them conflict with each other, so this is sadly not feasible to do with every extension that everyone wants, and some people will still be unhappy because their extension was not popular enough to get merged.

- Limit the extension API to a small group of stable functions. This will reduce the total number of extensions, and people will still be unhappy because some things will not be part of this API (e.g. it's unlikely you'd get the full lower-level workspaces API that allows you to implement something like 2d workspaces).

- Don't allow extensions at all. Now if you want to change the shell's behavior, you have to do a hard fork.

So yeah, I agree extensions are sometimes not a valid solution to a feature request, but the problem is that every other solution is even worse, at least for Gnome anyway.

>I suggest that you not buy Nvidia hardware.

If you want to play this game, I could suggest that you just not use 2d workspaces. But I won't -- I think you deserve to use that feature if you want it. And if I did buy nvidia hardware, I would use nouveau :)

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.

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.

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

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 :)

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.

I'm not sure what you mean twisting. If you're asking for the extension API to not be there, I think that would result in a strictly less configurable program. If that's not what you're asking for, then please clarify. Also, I'm not sure what you mean inadequate, the extension API is the internal API of the shell. You can use it to do anything that the shell can do. How could it be made adequate? You can install many extensions to configure the panels and menus in just a few clicks.

Edit: Somebody could probably make an extension to make the shell look and act like XFCE if that was really desired, for whatever reason. I don't think XFCE users would care much, but I just mean this as a way to illustrate what level the extension API sits at -- it's a level below the panels and menus and stuff.

I'm afraid I don't understand -- the extensions are configurability. That hasn't been removed. If you didn't have an API to configure these things, there would be no way to do it at all, so it still sounds like you're asking for something contradictory. What would help here? What would be the benefit of removing the extension API, and what would you replace it with?

I'm not sure I understand the point -- that's a different complaint entirely. The "cobbling together extensions and swapping out applications" is the customization, that's exactly what you asked for initially.

Edit: If the issue is that some extensions break and become unmaintained sometimes, that's unfortunate, but the only other solution there would actually be to put heavy limits on the extension API. Which would probably not be to your liking either because it would actually reduce customizability.

I don't think that actually is a problem though. For specific GNOME apps it's true, they tend to avoid having a lot of configuration settings. You can just avoid using those apps and use other ones.

The one part you can't replace is the shell, but you can pretty much configure every aspect of that using extensions. If you don't like the way the shell operates on a fundamental level, then you would probably be better served by using a different desktop.

>You have to install an additional configuration tool to enable it.

What exactly is the problem? It sounds like the configuration setting just moved, I can see that being inconvenient if you're used to the old way, but it doesn't seem like some big glaring design flaw.

>For a long time nautilus had a "Connect to server" option, but that went away

I believe that is still there if you click "Other Locations."

It won't happen in GTK3, that's feature frozen. Maybe someone could implement it in GTK4?

I don't think they will add settings back for that, but someone should be able to create an external file chooser that behaves differently.

Out of curiosity, which are the relevant features that were removed from GTK3? It should be possible to revive them in a separate library if they really are needed.

Does it? I'd imagine you could collaborate with the Mint developers, most of the hard work in packaging seems to be done there already.

Why not join up with some other Cinnamon users in Debian, and share some of the responsibility of maintaining the packages?

As far as I can see, the value seems to be in using code golfing as a form of artistic programming. Probably useless, but not any more so than your average video game, or theater performance, or art museum...

I think the Go team would also appreciate it if you filed bugs after finding a legitimate regression.

It's not needless if you've found an actual bug, i.e. if your refrigerator is actually broken. I too wish it was possible to get a refrigerator that never breaks or malfunctions or needs to be replaced. If you know how to make one of those, please start selling it, you'll probably get very rich.

On certain corners of Github, I wouldn't say so. I think you would see a lot more people doing the same thing in C++, if there was a Cargo-style package manager that got more adoption there.

>You sure are doing a lot of not understanding in here.

I mean, yes? I don't pretend to know everything about everyone.

>the vast majority of people who say things like "trust the science" don't have the first clue about what the science actually says. It's a dogmatically held belief to them.

I can't agree with this, if they would change their mind about it, it's not a dogmatic belief. You seem to be generalizing about a large number of people, have you asked all of them if they would be open to changing their mind, given new evidence?

I don't see how that's different to C++. You will run into the same issues there if you happen to use code that uses some of the various new features e.g. items targeted for C++23, that are already starting to be supported by the newest versions of GCC and Clang. If you're on Debian Stable or RHEL, I believe those are even still using GCC versions that don't fully support C++20.

I'm still not really sure what that's supposed to mean or why it's not conflation, many Christians that I've met have wildly varying views on the bible. I also don't see what the difference here is supposed to be -- in general, there is not a lot of fact checking happening on public social media, and if there is, it also has a lot of its own bias. I don't see that as being specific to comments on scientific articles or evidence of any kind of "scientism," it's just the usual confirmation bias.

You seem to be describing a stereotype and not an actual person, and also that seems to be conflating it with an actual view on religious beliefs (atheism). So I can't say I know what you mean.

I don't understand what this is supposed to mean. There is nothing in the context of "science itself" besides that particular scientific research or process. That's what it's defined as. Did you mean something like: a layperson might be inclined to place higher value on scientific research performed by a personal friend or colleague? That's probably true in some cases, but it's not "scientism."

I don't really buy it, it seems to suggest that scientific discoveries are not questioned and changed constantly, when they absolutely are. It's not accurate to always refer to them as "beliefs."

I'm not sure what you mean, the paid people are still volunteering. They don't really have to spend company time upstreaming anything, they could technically keep all their patches in a private fork, but the company allows them to upstream things because it makes the most sense. You also don't have to leave it, you can also make a private fork too, and work on it slowly, if it makes the most sense to you.

These complaints about Red Hat are what make no sense to me, if you believe they are "eating Linux" for the worse then I would advise you to produce a version of Linux with all of the Red Hat commits removed, and see for yourself if it's more stable and polished. It may not be, because you would likely also be removing a lot of the bug fixes they upstream.

Well, if you want some changes made, you would have to define what you mean by "fixed" and come up with some concrete steps to do that, and then implement those steps, or find a person who can do them for you.

If the app uses GtkFileChooserNative, it can likely already be configured to use an external file dialog, with some caveats: https://old.reddit.com/r/kde/comments/a5cxwk/firefox_v64_can...

If there are issues you'd like to see fixed, the best way to get those dealt with would be to contribute.

You are perceiving arrogance where there is none. These are volunteer-driven projects, for better or worse the deal has always been "take it or leave it," or fork it if that's what you prefer. If there is something you want extracted into a library, just go and extract it and make the library. Of course if you choose to abandon it entirely then it's going to be a total crapshoot if it improves the way you want it to.