For many years now KDE has focused on polish, bug fixing and "nice-to-have" improvements rather than major redesigns, and it paid off.
I often wondered why desktop UIs became so terrible somewhere in the 2010s and I don't want to attribute it to laziness, greed, etc... People have been lazy and greedy since people existed, there must have been something else. And I think that mobile is the answer.
UI designers are facing a really hard problem, if not impossible. Most apps nowadays have desktop and mobile variants, and you want some consistency, as you don't want users to relearn everything when switching variants. But mobile platforms, with their small touchscreens are completely different from desktop platforms with their large screens, keyboards and mice. So what do you do?
In addition to mobile, you often need to target the browser too, so: native desktop, native mobile, browser desktop, browser mobile. And then you add commercial consideration like cost, brand identity, and the idea that if you didn't change the UI, you didn't change anything. Commercial considerations have always been a thing, but the multiplication of platforms made it worse, prompting for the idea of running everything in a browser, and having the desktop inferface just being the mobile interface with extra stuff.
Who do you think has been "infected" by the "mobile" virus? KDE's only real competitor is way more keyboard focused than KDE...
[1] Hamburger menus are designed to make efficient use of a small vertical display where horizontal screen space is a limited commodity, which just is not the case at all for a large horizontal computer monitor. On a large horizontal display, they're a straight downgrade since you need to click the menu to see what's inside it, which makes action discovery harder. This click is also added to a lot of actions so they add more friction to almost all interactions.
Supposing I did, the only hamburger menus I can think of contain lesser-important functions of each app, like seeing the version/build number, or certain settings. I'm not sure I want something like a "See hidden files" ticker occupying screen real estate forever when I could just set it once in an accessory menu.
I question whether these critiques would evaporate if, instead of the three horizontal bars, Gnome instead used a gear icon or something, and turned their contents into a pop-up window rather than a popover element.
Perhaps the biggest problem with the hamburger menu is that there is absolutely zero convention for what you put in there, or in which order. You don't know what you'll find in the menu unless you click it. With the old top menu, there were a set of conventions for this; roughly where specific options went, and in which order, and even which hotkeys you'd press to activate the menus. This means that even in an application you were completely unfamiliar with (even hideously complex ones such as an IDE or 3d modelling software), you could fairly easily navigate the application.
I cannot tell you how many times I want to go into an app's settings, and it takes longer than 20 seconds; some have it in File, some in Edit, others in random menus like "Tools". Further still, the damned menu item itself could be named Settings, Preferences, Options, whatever. Even further, looking at Gimp here, Preferences is one of 25 menu items that I need to scan through. This is not good UX, this is Stockholm Syndrome.
Contrast with Gnome apps: Hamburger -> Preferences, invariably, never takes longer than three seconds to find it.
There's this Pinta image editor that since its initial release offered standard menus - for years it looked nearly identical to Paint.NET on which is partially based. In January devs switched to GTK4/libadwaita; new 3.0 release replaced menus with combined hamburger menu which of course cannot be decoupled in any way and which make advanced editing annoying. There's more clicking to do anything unless you decide to learn all shortcuts. And this "learn shortcuts" is quite common answer to hamburger menu complains.
If I were to assist with their design, I would eliminate everything that already has a headerbar icon or an on-screen affordance; so most of Files, Edit, View, and Layers is taken care of.
The stuff that remains:
- Quit: superfluous, not present in Gnome apps
- View: borrow the Ephiphany (gnome-web) zoom controls, move Grid, Show/Hide, and Ruler units into a preferences dialog
- Add-ins: Move to a preferences dialog
- Window is useless, they have tabs
- Help can stay
So no surprise that the laziest implementation of a hamburger menu is not good.
In the end I swapped from Pinta to Gimp and Krita because I couldn't stand that interface
Pinta is interesting, but the UI is terrible. Did we really have to remove the resize handles? They're there when adding shapes, but not when manipulating pixels/selection? Half the options I need being hidden in a hamburger menu isn't great either.
Gimp is gimp. I don't need Photoshop. And I don't want a Photoshop level of a learning curve.
Krita is interesting, but it seems to be aimed at drawing. I struggled to copy the color code from an image. By default my eyes are drawn to the massive advanced color selector on the right, but it's a trap. You actually need the tiny color selector in the top bar. It shouldn't be this hard.
I need a subset of image manipulation features in my work and each tool has a different one.