I understand this is a common suggestion in the developer world, but I think it is self evident that doing so takes a fair bit of time. The parent said they’ll just have to switch, which I expect is much easier than packaging a DE yourself or even sharing responsibility.
But we know nothing about the person who said they will switch DE’s. We don’t know if spending time collaborating with Mint developers is a reasonable suggestion for them. I just want folks to realize that while recruitment is important, not every single Linux user should be expected to code for Linux. For example I’m a heavy Linux user but I’ve got my hands full maintaining my own open source robotics projects. I do not have time to take on something like this. I hope we can be understanding when people don’t have time for this kind of thing.
MATE on Debian provides most of the decent "modern" gnome2 experience it always has. There are some problems with file chooser dialogs and the like due to feature removals in the underlying GNOME gtk3 libs but overall it's very usable.
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.
The ability to toggle gsettings for location-mode from path-bar (those button folder) defaults to filename-entry (the location bar you type in) is what really bothers me. It means I can't paste filepaths into a just opened File dialog (it errors out unless you first type ctrl-l, ., `, or /).
Additionally, the old type-ahead complete was removed from filename-entry. Arch at least has a patch set to put this back, but the location-mode thing is resistant to fixing. I changed the default initialization with a simple patch to gtkfilechooserwidget.c but it only works for the first time I File->Open in a gtk3 application. The second reverts back to pathbar.
I talked to mclasen on GIMPnet IRC #gtk a month or two ago and he did fix this in Gtk4. You can paste without typing anything beforehand in Gtk4 file chooser.
+1 Xfce is also very easy to customize out of the box. I customized my environment using the defaults that are preinstalled and I prefer it's looks to windows.
I personally really like Xfce, but my philosophy has always been function over form, meaning I don't mind if it looks like it's from the last millennium as long as it doesn't hinder the performance of my device (Acer Aspire one, running Intel Atom).
Interesting thing is that you can use the same philosophy in everyday life.
IMO GNOME is too tablet-oriented. I don't like it, this kind of UI is foreign on desktop. They waste an entire top bar. Top bar is not compatible with tabbed applications (mainly browsers). Application launcher screen is absolutely weird for desktop, it reminds me of Windows 8.
The thing is, you can change a lot of those things to match what you want. You can toggle the application menu, which works more like the windows menu. You can use something like dash-to-panel [0] to make the top bar into something useful.
I know that in Firefox you can disable the window bar to make it look a lot cleaner with a top bar.
Here is a screenshot of how my GNOME looks [1]. I don't have the application menu because I use an app launcher, so it doesn't bother me that much.
That's an investment you have to make if you want it to look like you want to. Maybe you just want to have a DE that works for you without tweaking it, which I understand. But I'm pretty sure you could make a GNOME desktop you like given the time.
Having tested multiple desktop environment and window managers, it's pretty great having such a diverse pool of choices : you can really ditch GNOME completely if you don't like it.
The problem isn't that you can't configure GNOME to behave to your preferences. The problem is that GNOME makes it hard to do so, and that's a philosophical decision the project made.
If I'm about to spend time customizing my DE to match my preferences and habits, I'd much rather spend the time on something that is made to be customizable.
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're making my point for me. You're suggesting I spend additional time cobbling together extensions (which presumably can end up unmaintained and/or break?) and swap out some applications.
This feels like ordering paella at a restaurant when I don't like seafood. Sure, I can eat around all the sea bits. But there's lots of other options at this restaurant, so why the f* would I order paella, knowing it has seafood I don't like?
I'm not gonna tell you not to order the paella, or that the paella is bad, or that the restaurant is bad, or whatever. But don't push the paella on me either please ;)
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'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?
It sounds more to me like you're twisting these things to make them seem contradictory.
> the extensions are configurability
And this is an inadequate mechanism.
(For me! If it works for you, that's great! Me, I like to be able to configure bars and widgets and menus and stuff wherever I want with a few clicks, which is why I run Xfce. Far be it from me to say there should only be one true desktop)
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 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.
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?
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 :)
> 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.
>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.
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.
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.
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.
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.
My only real complaint is advocates like you who try to claim that an extension is a valid solution to a feature request. Because it really isn't. People spend a lot of time customizing their environment to meet their needs. And they often don't have a choice not to update some package like a GNOME Shell. 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 the "just a few clicks and you can install an extension" is really a very weak, naive argument. One might even say, one made in bad faith. I don't tell people to use out-of-tree kernel modules either, because that's not really a solution for exactly the same reason. Instead, I tell them, yeah that sucks, I suggest that you not buy Nvidia hardware. :-)
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 :)
This big difference between the Kernel Modules and GNOME Extensions is that we in the kernel community do not encourage out-of-tree modules. Indeed, they are strongly discouraged. So they out-of-tree modules are never considered an answer to anything.
The kernel interfaces which are supported forever, and for which we will never break userspace, are the system call interface. We don't break that, because to do that would be to break faith with our users.
With GNOME, features are removed, and the lack of features are excused, by saying, "there's an extension for that". That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable. If the extensions API is not stable, then you shouldn't be encouraging out-of-tree users of that API. Because you're effectively promising that you will break them, all the time.
There are times when we in kernel land will say, that belongs in userspace; it's insane to put that functionality in the kernel. But when we do that, we offer stable system call interfaces so that you can do it in userspace, and users can trust that it won't break.
The bottom line is if the API is not stable, then there should be no external users of that interface. Which is why you shouldn't use Nvidia drivers. They are a bad idea. Similarly, people should not use GNOME extensions, unless they like being randomly broken at a distro upgrade.
And yes, I will not use 2d workspaes with GNOME, because I refuse to trust in extensions. My solution is to simply not use GNOME. Xfce and KDE support 2-d workspaces as core features. If GNOME can't, then to hell with it.
>This big difference between the Kernel Modules and GNOME Extensions is that we in the kernel community do not encourage out-of-tree modules. Indeed, they are strongly discouraged.
It's not different, it's mostly the same with extensions. They're strongly discouraged unless you're able to track upstream and follow the release. If someone can't do that, then don't depend on them to make an extension. You wouldn't make such a person a kernel maintainer of a key feature either.
>That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable.
That comes back to what I was saying earlier. The system call interface is very small and very limited compared to the total size of the kernel's API. It's not the same as the GS extension API, which is a huge API that allows access to various internals. The equivalent to create a "syscall API" in GNOME shell would be one of the options I said earlier -- "Limit the extension API to a small group of stable functions" which would not please you either, because that would essentially be removing APIs and would cause even more extensions to break and become impossible to implement.
Of course if you decided to stabilize everything then you would be stuck with a project where you can't refactor anything -- imagine a future for Linux where you have eBPF hooks across every function and internal structure, and you can't change any of them ever, because those kernel structures are now external API accessed by userspace. If you want GNOME to stabilize their internal API, that's really what you're asking them to do. Is that a good explanation of the problem? I'm trying to explain here why this is actually a really nasty technical minefield, and ultimately has little to do with release policy, or with any particular architectural decisions made by GNOME. There are basically zero active open source desktops that have a comprehensive and stable plugin API. KDE doesn't do it here either -- these particular areas are not even possible to change there with plugins, you're just lucky enough that the core workflow works for you.
>unless they like being randomly broken at a distro upgrade.
This is not strictly true. Just FYI, I've seen some GNOME-based distros that are starting to bring certain extensions into their release cycle, and make those part of the upgrade. But of course that falls on the distro to support the extension and do the testing before they ship, so the extension has to pass a certain quality and usefulness threshold first for that distro's users. If you get stuck using a GNOME-based distro in the future, you may want to check what their policy is there, you may be surprised (although I don't think any are shipping 2d workspaces).
>Xfce and KDE support 2-d workspaces as core features.
That's great, you should use those if those are what you like. But here is my perspective: If some XFCE or KDE developers (who know how to implement 2d workspaces) wanted to spare some time to revive the 2d workspaces extension in GNOME, and keep it working during distro upgrades, and support you doing what you like, I don't think any GNOME people would have a problem with that. Similarly, if it were possible in a reliable way, I don't think anyone in KDE or XFCE would have a problem if some GNOME developer maintained an optional XFCE or KDE extension to make those use a GNOME-style workspace overview, for those who prefer that design.
I was using GNOME when 2-D workspaces was a supported feature, and when it was removed, people told me, "don't worry, use an extension; the feature isn't really gone". The problem is then the next time my distribution updated to a new version of GNOME, things broke, and I had to scramble to figure out how to get a working desktop environment again.
Fool me once, shame on you. Fool me twice, shame on me.
Or just switch to a DE that is willing to be receptive to the needs of its users. Again, GNOME used to support 2-d workspaces. This feature was removed, deliberately, by the GNOME developers. That's their prerogative, but don't try to fool users by claiming that extensions are the solution. Because extensions break. Frequently. Often. And so they can't be depended upon. If it's a critical part of your workflow and usage model, and the DE doesn't support it except via an extension API, then run away. Run far, far away.
More generally, GNOME has been in the feature removal business for a long time. So even if something is in the supported feature set today, there is no guarantee that it won't be removed tomorrow. And that's one of the ways in which it's not like kernel development. Once a userspace visible feature lands, it won't get removed. Linus will yell at you and revert your changes if you break users in that way. GNOME is frequently removing features, and so as a result, they can't be trusted. Moving something to an extension is a negative value add to users. Worse, it breaks trust with your user base. Because GNOME has done this to me, it's going to be a long, long time before I trust GNOME again.
Hi Ted, thanks for replying. Those statements you've made are untrue. Just like kernel drivers, extensions don't break when someone is maintaining them. To be clear, the issue here is not that the DE was not receptive, the issue is that the extension developer disappeared. All the hundreds of GNOME developers didn't get together and collectively decide to get rid of that extension, the one person who was working on it likely just lost interest. Nobody stepped up to fill the space, so now it becomes a manpower issue. That's the way it goes in open source. It would be the same issue if the feature was upstream and the maintainer disappeared.
What you're saying seems to me the equivalent to saying "If a kernel driver is a critical part of your workflow and usage model, then then run far away, the kernel driver API is unstable and the driver maintainer might get hit by a bus." Because as I have said before, the shell extension API is really not similar to kernel's userspace -- it's closer to the kernel's driver API, in that you get complete access to the shell's internals, you can muck it all up and crash things if you're not careful, the API is unstable, you have to follow upstream closely to really take advantage of it... but if you do all that then it's a very powerful tool, and you can do things that are not possible in "userspace" (i.e. outside the shell).
And the fact is, the kernel does remove old and broken and unmaintained driver APIs. That's your prerogative to do to that, as it is GNOME's (and KDE's) prerogative to remove legacy APIs and features that are not pulling their figurative weight in usefulness. I'm not trying to convince you to use or trust GNOME, I'm happy that you're using KDE and it works for you. But I wish you would not say these falsehoods without an understanding of how GNOME is actually developed, because from my perspective the technical process is extremely similar to that of the kernel, and heavily inspired by it. So please don't forget, the apple never falls far from the tree. If you have some insights on how to plug this maintainer gap that you think GNOME is suffering from, then let's talk about that.
This is incorrect. 2-D workspaces used to be part of the GNOME core feature set. It was removed from the core feature set, and the excuse was, "oh, if you really want that, you can develop an extension". That's not an answer, and that's not allowed in the Linux kernel development paradigm.
As far as we are concerned, out-of-tree modules do not exist. The module interface is only for in-tree users, which are fully supported. GNOME takes the position, or at least apologists like you, that out-of-tree GNOME extensions are a good thing. As far as Kernel developers are concerned, out-of-tree modules are never an answer. Device drivers should live in the kernel. Period. If Nvidia chooses to do otherwise, that's their problem. But we didn't kick Nvidia out of the kernel.
GNOME kicked 2-d workspaces out of the core DE, because they didn't want to support it. They think that they want to keep things "simple" for their users. Google "GNOME Feature Removal" and look at the history. They took perfectly working features and ejected them from GNOME. We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
Please stop making these insulting comments calling me apologist, this is rude and unhelpful; you're a better person than this. I've respected your kernel expertise for a long time and it's disappointing to be treated this way. This is the kind of behavior that pushes people away from open source. I'm only here to help explain how this works and to help get the issue fixed, I would do the same if you were making such statements about KDE.
>We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
GNOME unfortunately does not have enough maintainers to do this. If you'd like to help out, please contribute, or help direct some others to do so. That might mean helping to maintain some extensions that you're using. If you don't want to help, and you want to use KDE, that's understandable too -- but please understand what the real issue is.
>Device drivers should live in the kernel. Period.
It would be great if it was technically possible to do this with GNOME, if this is your goal, I would encourage you attempt to merge all the hundreds of extensions together into one big tree, resolve all the conflicts, and then maintain that. It's probably going to be a lot of work, and will break a huge number of things, and if you don't want to do it... well now you understand why GNOME maintainers don't either. Until that happens, people have to stick to another approach: extension maintainers just have to use CI to check their extensions against master and keep it updated.
First of all, apologist is not a dirty word. Per the Meriam-Webster dictionary the definition is "one who speaks or writes in defense of someone or something".
Secondly, extensions are not the answer, because extensions are inherently unstable. If you think the answer to supporting features is via extensions, then of _course_ GNOME doesn't have enough developers. Some featuers need to be in the core DE --- as 2-D workspaces was once a core feature. Ejecting features from the core feature set, and trying to implement them as extensions, is a receipe for P-A-I-N. It certainly isn't how KDE and XFCE handles 2-D workspaces; there it is implemented in C++ or C, and not in some Javascript extension language using unstable primitives that randomly change from GNOME version to GNOME version.
My Goal is to use a Linux Desktop Environment which meets my needs. And part of my needs is certain well-defined feature set which includes 2-D workspaces, and that they **NOT** be implented as an extension. Because extensions break. All. The. Damn. Time. I've been around since the very early days of GNOME, and GNOME had 2-D workspace support for years and years, and it was not a big deal. It was ejecting features from the core, and implementing them in unstable Javascript which is what caused the problems.
If GNOME simply said, F-U to certain classes of users, we don't think certain features deserve to exist, I'd probably respect them a bit more. I still wouldn't use GNOME, but at least they'd be honest. My complaint is trying to assert that extensions are an answer, and they're not, because it's really unfair to trick users into relying on something which is ultimately built on quicksand. Better to have a small feature set which you can support well, rather than a randomly fluctuating feature set which arbitrarily breaks across distro upgrades.
One issue with extension is that it's not official. For example from the very extension you linked (dash-to-panel) I can find out, that Gnome 40 support issue (#1265) is not closed. Gnome 40 was released almost 3 months ago and it is default in Fedora 34. Imagine someone upgrading and breaking his workflows completely.
That would be OK for some minor adjustments, when user can live without this extension for a while. But for something as major as dash-to-panel, it should be official and updated synchronously with main project to be a proper option IMO. That's my reason to avoid this extension for now. It might be good, but I don't want to depend on it.
That's fair, and I agree it would be much better if it was officially supported. I'm on a rolling release distro but I had to freeze all my GNOME packages to stay on 38 because of the issue you mention.
But I chose GNOME knowing they have a tendency to break a lot of extensions with new versions, which is honestly quite a pain and something I understand many (if not most!) don't want to deal with.
GNOME may be developed by professionals, but its design leaves a lot to be desired in the details. Something as basic as two-finger click, which any competent touchpad has supported for the better part of a decade, is not only no longer enabled by default, but no longer configurable at all by default! You have to install an additional configuration tool to enable it. For a long time nautilus had a "Connect to server" option, but that went away - not the functionality of course, that's still available via Ctrl+L - but all discoverability had to disappear. It's the complete lack of attention to details like these that makes people distrust GNOME and its future direction.
>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."
There's Linux Mint Debian Edition, basically Linux Mint you know but based on Debian, with some tiny quirks. It's maintained by Linux Mint folk themselves, who are the makers of Cinnamon itself.
I've been using LMDE for about a year and a half and it's been great. Originally discovered it when I was having issues trying to update to the latest version of Cinnamon on Debian 9. I have it highly customized compared to what comes out of the box. I've tried XFCE, MATE, and Gnome, but I just feel at home with Cinnamon. What's nice about LMDE is that the Cinnamon DE is always up-to-date compared to the version that's available on Debian 10.
When I was on Debian I was pretty satisfied with Openbox + XFCE panel (and I guess buy in piecemeal other XFCE bits as need) wishing came from the Crunchbang days. It was pretty lightweight and low-maintenance.
With Wayland finally taking off (color management be damned sad), maybe you could give Sway, the Rust tiling manager, a go. Debian has a page for it https://wiki.debian.org/sway
Sway isn't written in Rust, all C as far as I know. It's really great though! Highly recommend it if you're looking for a minimalistic and very practical window manager.
Debian, Gentoo, Arch, openSUSE, I've been on KDE since Gnome 2 came out and it messed up a lot of the things I liked in Gnome 1.
KDE 4 was a low point, at least the first releases were buggy and didn't feel nearly as good as 3, but 5 has been absolute smooth sailing. It's surprisingly light and nimble, I use it on my Thinkpad X220i and it runs great, better than Cinnamon on Mint did when I tried that out.
There seems to be a lot of friction against giving KDE a go, and I just don't understand it.
I do understand the friction against KDE — it's C++, which used to mean huge ass programs and compile times, it uses Qt which keeps having… "second thoughts" on its license, and it used to be slow as fuck 15 years ago.
Only the Qt thing is current, but memory is long on these things and a lot of people formed their opinions a decade ago. First impressions and whatnot.
If KDE binaries were huge, that would be a consequence of KDE design choices, not of being in C++. Most likely, though, the definition of "huge" has anyway since grown past the size of KDE programs, and Gnome sizes probably have caught up to KDE's.
I have not tried KDE in this decade, or the last. The article makes me curious. But Qubes is an Xfce desktop, and I am stuck there for the time being. It has been OK. Qubes desktop can't use a GPU anyway.
If Qt goes proprietary, it will fork without drama.
I have used both KDE and GNOME during their 1.x and 2.x days, and even the beginning of 3.x days and KDE was never outrageously bloated compared to GNOME. The difference IME was always 10-15% more RAM use. And this was understandable since KDE was a much more full featured desktop with far more knobs to tweak and many more inbuilt applications compared to GNOME.
I don't know what the situation is these days though but anecdotally it seems GNOME has now become the "bloated" desktop, thanks to Javascript in the shell.
On a fresh reboot and login to a KDE desktop, the total memory use (minus disk cache) on my system is just a hair over 1GB. This is on a ~10 year old Phenom II with 16GB RAM, and KDE is smooth as butter. It runs great on my Thinkpad X220i, too.
Firefox or Chrome will absolutely dwarf your DE in memory usage, so I don't think it's really a major differentiator between KDE and Gnome. If your PC has less than 2GB of memory, you'll run into other issues first.
I'm currently using KDE Plasma. I used to use XFCE, but it appeared that XFCE was having trouble getting enough developers such their release cycle seemed to be very slow, and in particular, at the time there was no indication that Wayland support was going to happen. I have no particular interest in Wayland on its own merits, but given that the X server support seems to also be not particularly sustainable in the long term[1], it seems like the rest of the world seems to be converging on Wayland, for better or for worse.
So given that GNOME is unacceptable to me (it doesn't support 2-D workspaces as a core feature, and extensions which support 2-D workspaces regularly break because the extensions API is not stable), and while I'm very happy with Xfce, but I was concerned about its long-term maintainability since it's tied to X, and its developer community's ability to move to Wayland seemed questionable, I decided to give KDE a try.
To my surprise (I go back long enough to the days when KDE was highly opinionated and GNOME was the DE that had a lot more flexibility), KDE had support for everything that I needed (which is not a lot; I just want a decent, configurable window manager, and a decent terminal) and so spent the investment to move over to KDE.
I see that the Xfce folks are now starting to think about adding Wayland support, and that's great. My main priorities is that I not be left high and dry when there is a major release, and whether I get messed up because GNOME has broken some extension which I depend upon, or some future desktop hardware no longer works with xfree86, and only Wayland, it looked like KDE was the best bet for me as a user who just wants a window manager, decent terminal support, and a 2-D workspace. You'd think that is a simple ask, but unfortunately, these days, it's not something I can count upon --- but KDE seemed to be my best bet.
Cinnamon on top of Ubuntu has been my absolute go-to for the past 10+ years for a very long list of reasons.
Having to switch to the OSX botched look-alike abomination that currently ships with Ubuntu (unity or something) would force me to walk away from Ubuntu altogether to switch to a distro that supports Cinnamon natively.
I truly hope someone technical enough will pick up the torch.
The funny thing is that, like you, I used to have very strong opinions about the desktop designs I wanted to use. For instance, when Ubuntu's Unity first came out I was appalled.
But as I'm getting older, and after being forced to use (begrudgingly, at first) alternative desktop metaphors at work, I've noticed that it does not really matter as much (to me) as I always thought.
Sure, there are things that you've learned to love and now think you cannot live without. And there are features that other approaches had that I though were completely pointless and a step backwards rather than forwards. Or at least just useless.
But now, I think it's all not so bad, actually. I'm writing this on Ubuntu 18.04, and I remember how much I used to despise the vertical icon bar on the left, that shows both currently running apps and also allows you to start often used programs with a single click. Now I just don't see it anymore. Except when I need to use it, and then I suddenly don't see anything wrong with it, anymore.
Mind you, I still have a list of must-have features for desktops. For instance, having virtual desktops that I can quickly change between using keyboard shortcuts. But my list of "must haves" has definitely changed over time (maybe even gotten smaller) -- which shows that the word "must" was apparently never right in the first place.
78 comments
[ 2.8 ms ] story [ 127 ms ] threadhttps://www.linuxmint.com/download_lmde.php
Still though, I have to imagine there is a lot of work / knowledge required to maintain Cinnamon on Debian proper.
Additionally, the old type-ahead complete was removed from filename-entry. Arch at least has a patch set to put this back, but the location-mode thing is resistant to fixing. I changed the default initialization with a simple patch to gtkfilechooserwidget.c but it only works for the first time I File->Open in a gtk3 application. The second reverts back to pathbar.
Interesting thing is that you can use the same philosophy in everyday life.
I made the switch when gnome 3 happened and have never looked back.
It’s themeable enough for me - xubuntu usually looks pretty good, you can get the themes on Debian easily enough.
It’s featureful enough, while still being relatively lightweight.
But the best thing about it? It’s not opinionated. You can decide what goes on your bars/panels, where they go at what size etc.
That's an investment you have to make if you want it to look like you want to. Maybe you just want to have a DE that works for you without tweaking it, which I understand. But I'm pretty sure you could make a GNOME desktop you like given the time.
Having tested multiple desktop environment and window managers, it's pretty great having such a diverse pool of choices : you can really ditch GNOME completely if you don't like it.
[0] : https://github.com/home-sweet-gnome/dash-to-panel#features
[1] : https://i.imgur.com/NRegvAo.png (The orange on the left is me failing to crop my left monitor correctly)
If I'm about to spend time customizing my DE to match my preferences and habits, I'd much rather spend the time on something that is made to be customizable.
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.
This feels like ordering paella at a restaurant when I don't like seafood. Sure, I can eat around all the sea bits. But there's lots of other options at this restaurant, so why the f* would I order paella, knowing it has seafood I don't like?
I'm not gonna tell you not to order the paella, or that the paella is bad, or that the restaurant is bad, or whatever. But don't push the paella on me either please ;)
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.
The problem is not that the extension API is too wide in scope, it's that you need to use an extension API at all to change even simple things.
> the extensions are configurability
And this is an inadequate mechanism.
(For me! If it works for you, that's great! Me, I like to be able to configure bars and widgets and menus and stuff wherever I want with a few clicks, which is why I run Xfce. Far be it from me to say there should only be one true desktop)
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.
There, that's the issue you're refusing to see. Having to discover and install extensions to do basic things is not a good feature.
If that's OK for you, great. Doesn't work for me.
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?
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 :)
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.
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.
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.
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.
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.
So the "just a few clicks and you can install an extension" is really a very weak, naive argument. One might even say, one made in bad faith. I don't tell people to use out-of-tree kernel modules either, because that's not really a solution for exactly the same reason. Instead, I tell them, yeah that sucks, I suggest that you not buy Nvidia hardware. :-)
>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 :)
The kernel interfaces which are supported forever, and for which we will never break userspace, are the system call interface. We don't break that, because to do that would be to break faith with our users.
With GNOME, features are removed, and the lack of features are excused, by saying, "there's an extension for that". That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable. If the extensions API is not stable, then you shouldn't be encouraging out-of-tree users of that API. Because you're effectively promising that you will break them, all the time.
There are times when we in kernel land will say, that belongs in userspace; it's insane to put that functionality in the kernel. But when we do that, we offer stable system call interfaces so that you can do it in userspace, and users can trust that it won't break.
The bottom line is if the API is not stable, then there should be no external users of that interface. Which is why you shouldn't use Nvidia drivers. They are a bad idea. Similarly, people should not use GNOME extensions, unless they like being randomly broken at a distro upgrade.
And yes, I will not use 2d workspaes with GNOME, because I refuse to trust in extensions. My solution is to simply not use GNOME. Xfce and KDE support 2-d workspaces as core features. If GNOME can't, then to hell with it.
It's not different, it's mostly the same with extensions. They're strongly discouraged unless you're able to track upstream and follow the release. If someone can't do that, then don't depend on them to make an extension. You wouldn't make such a person a kernel maintainer of a key feature either.
>That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable.
That comes back to what I was saying earlier. The system call interface is very small and very limited compared to the total size of the kernel's API. It's not the same as the GS extension API, which is a huge API that allows access to various internals. The equivalent to create a "syscall API" in GNOME shell would be one of the options I said earlier -- "Limit the extension API to a small group of stable functions" which would not please you either, because that would essentially be removing APIs and would cause even more extensions to break and become impossible to implement.
Of course if you decided to stabilize everything then you would be stuck with a project where you can't refactor anything -- imagine a future for Linux where you have eBPF hooks across every function and internal structure, and you can't change any of them ever, because those kernel structures are now external API accessed by userspace. If you want GNOME to stabilize their internal API, that's really what you're asking them to do. Is that a good explanation of the problem? I'm trying to explain here why this is actually a really nasty technical minefield, and ultimately has little to do with release policy, or with any particular architectural decisions made by GNOME. There are basically zero active open source desktops that have a comprehensive and stable plugin API. KDE doesn't do it here either -- these particular areas are not even possible to change there with plugins, you're just lucky enough that the core workflow works for you.
>unless they like being randomly broken at a distro upgrade.
This is not strictly true. Just FYI, I've seen some GNOME-based distros that are starting to bring certain extensions into their release cycle, and make those part of the upgrade. But of course that falls on the distro to support the extension and do the testing before they ship, so the extension has to pass a certain quality and usefulness threshold first for that distro's users. If you get stuck using a GNOME-based distro in the future, you may want to check what their policy is there, you may be surprised (although I don't think any are shipping 2d workspaces).
>Xfce and KDE support 2-d workspaces as core features.
That's great, you should use those if those are what you like. But here is my perspective: If some XFCE or KDE developers (who know how to implement 2d workspaces) wanted to spare some time to revive the 2d workspaces extension in GNOME, and keep it working during distro upgrades, and support you doing what you like, I don't think any GNOME people would have a problem with that. Similarly, if it were possible in a reliable way, I don't think anyone in KDE or XFCE would have a problem if some GNOME developer maintained an optional XFCE or KDE extension to make those use a GNOME-style workspace overview, for those who prefer that design.
Fool me once, shame on you. Fool me twice, shame on me.
More generally, GNOME has been in the feature removal business for a long time. So even if something is in the supported feature set today, there is no guarantee that it won't be removed tomorrow. And that's one of the ways in which it's not like kernel development. Once a userspace visible feature lands, it won't get removed. Linus will yell at you and revert your changes if you break users in that way. GNOME is frequently removing features, and so as a result, they can't be trusted. Moving something to an extension is a negative value add to users. Worse, it breaks trust with your user base. Because GNOME has done this to me, it's going to be a long, long time before I trust GNOME again.
What you're saying seems to me the equivalent to saying "If a kernel driver is a critical part of your workflow and usage model, then then run far away, the kernel driver API is unstable and the driver maintainer might get hit by a bus." Because as I have said before, the shell extension API is really not similar to kernel's userspace -- it's closer to the kernel's driver API, in that you get complete access to the shell's internals, you can muck it all up and crash things if you're not careful, the API is unstable, you have to follow upstream closely to really take advantage of it... but if you do all that then it's a very powerful tool, and you can do things that are not possible in "userspace" (i.e. outside the shell).
And the fact is, the kernel does remove old and broken and unmaintained driver APIs. That's your prerogative to do to that, as it is GNOME's (and KDE's) prerogative to remove legacy APIs and features that are not pulling their figurative weight in usefulness. I'm not trying to convince you to use or trust GNOME, I'm happy that you're using KDE and it works for you. But I wish you would not say these falsehoods without an understanding of how GNOME is actually developed, because from my perspective the technical process is extremely similar to that of the kernel, and heavily inspired by it. So please don't forget, the apple never falls far from the tree. If you have some insights on how to plug this maintainer gap that you think GNOME is suffering from, then let's talk about that.
As far as we are concerned, out-of-tree modules do not exist. The module interface is only for in-tree users, which are fully supported. GNOME takes the position, or at least apologists like you, that out-of-tree GNOME extensions are a good thing. As far as Kernel developers are concerned, out-of-tree modules are never an answer. Device drivers should live in the kernel. Period. If Nvidia chooses to do otherwise, that's their problem. But we didn't kick Nvidia out of the kernel.
GNOME kicked 2-d workspaces out of the core DE, because they didn't want to support it. They think that they want to keep things "simple" for their users. Google "GNOME Feature Removal" and look at the history. They took perfectly working features and ejected them from GNOME. We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
>We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
GNOME unfortunately does not have enough maintainers to do this. If you'd like to help out, please contribute, or help direct some others to do so. That might mean helping to maintain some extensions that you're using. If you don't want to help, and you want to use KDE, that's understandable too -- but please understand what the real issue is.
>Device drivers should live in the kernel. Period.
It would be great if it was technically possible to do this with GNOME, if this is your goal, I would encourage you attempt to merge all the hundreds of extensions together into one big tree, resolve all the conflicts, and then maintain that. It's probably going to be a lot of work, and will break a huge number of things, and if you don't want to do it... well now you understand why GNOME maintainers don't either. Until that happens, people have to stick to another approach: extension maintainers just have to use CI to check their extensions against master and keep it updated.
Secondly, extensions are not the answer, because extensions are inherently unstable. If you think the answer to supporting features is via extensions, then of _course_ GNOME doesn't have enough developers. Some featuers need to be in the core DE --- as 2-D workspaces was once a core feature. Ejecting features from the core feature set, and trying to implement them as extensions, is a receipe for P-A-I-N. It certainly isn't how KDE and XFCE handles 2-D workspaces; there it is implemented in C++ or C, and not in some Javascript extension language using unstable primitives that randomly change from GNOME version to GNOME version.
My Goal is to use a Linux Desktop Environment which meets my needs. And part of my needs is certain well-defined feature set which includes 2-D workspaces, and that they **NOT** be implented as an extension. Because extensions break. All. The. Damn. Time. I've been around since the very early days of GNOME, and GNOME had 2-D workspace support for years and years, and it was not a big deal. It was ejecting features from the core, and implementing them in unstable Javascript which is what caused the problems.
If GNOME simply said, F-U to certain classes of users, we don't think certain features deserve to exist, I'd probably respect them a bit more. I still wouldn't use GNOME, but at least they'd be honest. My complaint is trying to assert that extensions are an answer, and they're not, because it's really unfair to trick users into relying on something which is ultimately built on quicksand. Better to have a small feature set which you can support well, rather than a randomly fluctuating feature set which arbitrarily breaks across distro upgrades.
That would be OK for some minor adjustments, when user can live without this extension for a while. But for something as major as dash-to-panel, it should be official and updated synchronously with main project to be a proper option IMO. That's my reason to avoid this extension for now. It might be good, but I don't want to depend on it.
But I chose GNOME knowing they have a tendency to break a lot of extensions with new versions, which is honestly quite a pain and something I understand many (if not most!) don't want to deal with.
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."
With Wayland finally taking off (color management be damned sad), maybe you could give Sway, the Rust tiling manager, a go. Debian has a page for it https://wiki.debian.org/sway
https://github.com/swaywm/sway
The closest thing is probably indeed KDE, which the Debian Cinnamon maintainer switched to as they say in the post…
KDE 4 was a low point, at least the first releases were buggy and didn't feel nearly as good as 3, but 5 has been absolute smooth sailing. It's surprisingly light and nimble, I use it on my Thinkpad X220i and it runs great, better than Cinnamon on Mint did when I tried that out.
There seems to be a lot of friction against giving KDE a go, and I just don't understand it.
It's called NIH syndrome.
Only the Qt thing is current, but memory is long on these things and a lot of people formed their opinions a decade ago. First impressions and whatnot.
I have not tried KDE in this decade, or the last. The article makes me curious. But Qubes is an Xfce desktop, and I am stuck there for the time being. It has been OK. Qubes desktop can't use a GPU anyway.
If Qt goes proprietary, it will fork without drama.
I don't know what the situation is these days though but anecdotally it seems GNOME has now become the "bloated" desktop, thanks to Javascript in the shell.
Firefox or Chrome will absolutely dwarf your DE in memory usage, so I don't think it's really a major differentiator between KDE and Gnome. If your PC has less than 2GB of memory, you'll run into other issues first.
[1] https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...
So given that GNOME is unacceptable to me (it doesn't support 2-D workspaces as a core feature, and extensions which support 2-D workspaces regularly break because the extensions API is not stable), and while I'm very happy with Xfce, but I was concerned about its long-term maintainability since it's tied to X, and its developer community's ability to move to Wayland seemed questionable, I decided to give KDE a try.
To my surprise (I go back long enough to the days when KDE was highly opinionated and GNOME was the DE that had a lot more flexibility), KDE had support for everything that I needed (which is not a lot; I just want a decent, configurable window manager, and a decent terminal) and so spent the investment to move over to KDE.
I see that the Xfce folks are now starting to think about adding Wayland support, and that's great. My main priorities is that I not be left high and dry when there is a major release, and whether I get messed up because GNOME has broken some extension which I depend upon, or some future desktop hardware no longer works with xfree86, and only Wayland, it looked like KDE was the best bet for me as a user who just wants a window manager, decent terminal support, and a 2-D workspace. You'd think that is a simple ask, but unfortunately, these days, it's not something I can count upon --- but KDE seemed to be my best bet.
Cinnamon on top of Ubuntu has been my absolute go-to for the past 10+ years for a very long list of reasons.
Having to switch to the OSX botched look-alike abomination that currently ships with Ubuntu (unity or something) would force me to walk away from Ubuntu altogether to switch to a distro that supports Cinnamon natively.
I truly hope someone technical enough will pick up the torch.
But as I'm getting older, and after being forced to use (begrudgingly, at first) alternative desktop metaphors at work, I've noticed that it does not really matter as much (to me) as I always thought.
Sure, there are things that you've learned to love and now think you cannot live without. And there are features that other approaches had that I though were completely pointless and a step backwards rather than forwards. Or at least just useless.
But now, I think it's all not so bad, actually. I'm writing this on Ubuntu 18.04, and I remember how much I used to despise the vertical icon bar on the left, that shows both currently running apps and also allows you to start often used programs with a single click. Now I just don't see it anymore. Except when I need to use it, and then I suddenly don't see anything wrong with it, anymore.
Mind you, I still have a list of must-have features for desktops. For instance, having virtual desktops that I can quickly change between using keyboard shortcuts. But my list of "must haves" has definitely changed over time (maybe even gotten smaller) -- which shows that the word "must" was apparently never right in the first place.