Constructive GNOME Criticism

Desktop
, ,
1

Hello, i have been using the desktop and thinking about how GNOME does things. I also made a post at the EndeavourOS forum that served as a beta of this and to gather feedback on the shortcomings i found while using GNOME.
The point with this is that it can eventually be used to improve GNOME further, not to go after developers, that already get a lot of bad press.
If i sound a bit imperative, don’t make the bad impression that i don’t know how complicated making software can be and that most contributors are working for free. It’s because I’m angry at the problems.
I was about to provide sources to my claims, but due to forum design i can’t.

1) Stability First
As seen in these two bug reports (GTK scrolling bugs), there was a scrolling bug so bad that it made the experience of using Nautilus unbearable (that was my case).
This bug was reported in early GTK4 development, but the Nautilus developers still decided to make and ship the GTK4 port to all users, including distros like Debian Stable.

This should never happen again. GNOME has to prioritize making the user experience bug free and without mayor stability breaking bugs.
If that means delaying porting Nautilus to have the bug fixed, may it be.
Even three years after it was reported, the bug is still going in laptops.

2) Better Extensions
The GNOME Extensions ecosystem is a wonderful thing, but it could be better. It’s almost a tradition to see extensions break with each release and a lot of users depend on them to be able to work at their computers.

I suggest that the official extensions (where things like gnome fallback go) should be increased to allow for a few top extensions (like Dash to Dock, Panel, DING icons, etc.) to coordinate their releases with GNOME. Make it so Shell and Extension developers work together to avoid experience breaking code creeping in future releases.

3) Bad Design & Accessibility
I think that the current horizontal design for the Overview is a regression compared to the vertical 3X series one.
In the 3X series, you were able to activate the overview and launch apps very quickly with the mouse and the open workspaces were at another spot the user frequented, the quick settings.
Currently for mouse users, they have to go to the top left and then go to the bottom just to open one app.
This is especially true for inexperienced users that don’t know about keyboard shortcuts, they will try to do most things with only the mouse.

And this can be problematic for accessibility and overall efficient use. Lots of movement needed for few actions. It would be helpful to know the points of view of people who really have some kind of difficulty to see if im being nitpicky here or if it’s an actual problem.

Conclusion
I think GNOME is advancing at a great speed and with a lot of accomplishments, but that speed is going against the stability that made GNOME the default choice for enterprise users.
A focus should be done to make user feedback more important. Make a survey before doing big changes like the quick settings redesign or 40’s horizontal overview. Or see how popular are extensions actually.
Just make it feel less like Windows shoving unwanted things down the users’ throat and make feedback a crucial part of the process.

If you want to read my unfiltered thoughts, check this post out:

2

Regarding Nautilus, perhaps making fewer changes to it each release would improve its stability by providing more time for bugs regarding these changes.

Regarding the Overview, there is a design with apps and horizontal workspace in the same space (the current app view), but this could impede window switching, depending on use cases and window preview sizes. What exactly do you expect for launching apps and window switching?

1 Like
3

Thank you for your feedback. Feedbacks from end users are indeed important.

In GNOME 3.x with the vertical workspaces, using the mouse only required also lots of moving to go to another workspace (top-left corner → right side of the screen).

It’s hard to please everybody, I know this from being a developer. Decisions need to be made, and having too many settings will make the software harder to use too (the user would be lost in all the possible settings), and there would be even more bugs because more settings makes the software harder to test too.

Havoc Pennington (a former GNOME developer) wrote a long time ago several essays, especially about UI, adding features, etc. It’s worth the reading.

1 Like
4

I already reported here the hot corner issue:

For that I made Bottom Overview - GNOME Shell Extensions which is a simplified version of Hot Edge - GNOME Shell Extensions. That’s the only rational way, I think, to use a mouse with GS. (Using a laptop, three fingers do perfectly the job.)

You mention some extensions that Ubuntu does maintain now (dock, tiling, desktop icons) and offer to all GS users. For sure, a native dock would be appreciated by some users, and I think it should not be a huge work (I did reuse GS dash to do that in Dock from Dash extension). But to be honest, I’m using only Bottom Overview, that respects GS design and has quite the advantages of a dock.

2 Likes
5

Another reply from me. This time not about the specific problems you outline, but more the general process.

It’s true that GNOME developers, with the 6 months deadlines and schedule (with the different freezes), sometimes rush things to merge features or branches even if the quality is not ideal.

Some Linux/Unix distributions work differently, to give examples:

  • Debian: it’s released when ready.
  • Fedora: for bigger changes made to the distribution, there is the “Change Set”, and for each item there is a “Contingency Plan” (e.g., a rollback).

So for GNOME upstream, it really depends from one developer or project to another.

There is just the version number that needs to fit with the GNOME one (as seen in each About Dialog of the apps), but IMHO it’s not really really important.

So a possibility would be to delay the release of a module, find a way to “rollback” to the previous version but still do a release with the version bump (or not). I know that Evolution, in the past, had sometimes one year as development cycle instead of 6 months.

And - as always - find a good balance between quality and quantity, and discipline versus flexibility.

6

Unfortunately it is actually not possible to do anything meaningful about this in a large open source project with many dependencies outside of the project’s control. By delaying porting you may be leaving in other bugs that are fixed by the port. Often the choice is between the lesser of two evils.

7

GNOME is not a top-down hierarchical structure with a management allocating resources and laying out timelines and goals. GNOME is a (somewhat loose) aggregation of volunteers working on a collection of free software projects. We generally agree through rough consensus on a direction, but we don’t tell people what to work on, or whether or not to stop working on something because there can be regressions.

Bugs and regressions are a fact of life; you are not paying for a product, and the licensing terms of the software you’re using explicitly mention the fact that there’s no warranty.

Yes, it would be nice to have zero regressions and no new bugs across a six months release horizon; the fact is that it can’t ever happen. It doesn’t happen in commercial products with thousands of engineers getting paid for it, how do you expect it to happen on a volunteer-driven free software product?

In practice, what you’re asking is: “I want volunteers to work on what I like, not on what they like”, and that has never worked in the history of the free and open source software movement.

If you want to influence GNOME, then I strongly encourage you to join the effort and start contributing to the project.

7 Likes
8

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.