[syntheweave]

There's something missing from the analysis, which I believe is quite important: There are only a few applications complex enough to push these toolkits to their limits, and that's not a case of "developers craving such a toolkit and not getting it". Most of the things people were going to write native for in the past have been absorbed into the browser; and many new applications are written with a more ground-up concept of UI that needs to start from the beginning with a lower level framework(e.g. game engines). Without that ambient demand pulling toolkits forward, they're going to revert to the needs of desktop environments - a problem which was already solved mostly adequately back in the 2000's and now is in a product churn cycle. The complaints of Linux desktop users haven't been about the desktop UI in quite some time; it's been other parts of the stack with friction that sometimes surfaces to the desktop(e.g. input devices under Wayland, or the entire landscape of audio session management), but not the basics of windowing and presentation.

Every time Linux faces big coordination challenges to stand up a more robust overall system, a "Ship of Theseus" method of getting first a political consolidation and then replacement has appeared. This can be traced at least as far back as the appearance of udev, and more recent examples include PulseAudio, systemd, Pipewire, and Wayland. One can see this taking place on both the GNOME and KDE fronts too: both had their toolkits come up out of an environment where GUI hadn't yet been commoditized, and therefore the stakeholders were broad. Over two decades on, consolidation has taken place, and that's gradually reached a point where it does impact the "alternative desktops" like Xfce.

The overall maintenance budget for old code isn't infinite, though. We can leverage the past, but only if we're still doing the same things we needed in the past. And I don't think the desktop is staying the same; the move towards touchscreens was a fashion, but the approaches to UX are generally going away from creating a space shuttle control panel, and instead looking for a way to configure more targeted workspaces. Which means that toolkit needs are changing as a result.

[jart]

Apple doesn't change. Chrome doesn't change. They both look exactly the same as when they were introduced. What makes platforms strong is stability and consistency. Linux desktop projects are more likely to get funded the more disruptive they are and the more likely it is they'll alienate supporters and cause drama. Like gnome's big shift circa 2014 to tablet first interfaces. If we consider that Linux desktop users are the smartest and most technically advanced computer users in the world, then it's quite a slap in the face to force them to use a gimmicky gui intended for toys as their workstation. The most advanced computer users deserve the most advanced desktop. Sadly that's not the world we live in. Hopefully someday we can liberate the technical class from this orwellian treatment of continual destruction of identity.

[linguae]

I wholeheartedly agree. It seems that there is no middle ground these days between Web- and mobile-inspired GUIs that have taken over the desktop (even in the macOS world) and doing everything via the command line. I feel the same way about GNOME 3's shift to mobile-influenced UI/UX paradigms; sadly this shift also occurred in Windows and macOS.

What I believe is needed are UIs for power users and developers. Nobody stays a novice forever; we need UIs that facilitate the tasks of technically-inclined users, something more ergonomic than CLIs but not oversimplified like modern UIs. Some examples of UI/UX that addresses the needs of power users are support for scriptability (such as AppleScript and Visual Basic for Applications), composability (such as OpenDoc [https://www.youtube.com/watch?v=oFJdjk2rq4E]), WordPerfect's Reveal Codes that allow writers more fine-grained control over formatting, and a demo I saw of Symbolics Genera where the CLI shell assists the user in completing the command (see https://youtu.be/7RNbIEJvjUA?t=380 for a demo of how that interfaced worked; while it's a CLI shell, it's much more ergonomic than any Unix shell I've seen). I would like to see more UIs that fit the needs of power users.

[zozbot234]

> Like gnome's big shift circa 2014 to tablet first interfaces.

It took a long time to work itself out, but today Linux+GNOME is the only mainstream system that's usable for real productive work on a pure tablet or palmtop device. Far more so in fact than even Apple's iPad. And it got done without having to write and test separate apps, everything has a responsive interface that works throughout the range, from a small handheld to a big desktop screen. That's a remarkable feat.

[seba_dos1]

To be frank, I believe that's mostly thanks to the work put into it because of the Librem 5 project and related initiatives. Before that, GNOME didn't really work all that well on touchscreens at all. 2014 GNOME felt like it would work well on a tablet, but it didn't - as you noted, it took some time to make it work. (disclaimer: I work on L5)

[zozbot234]

> Most of the things people were going to write native for in the past have been absorbed into the browser

The use cases for native applications vs. in-browser frontends are still very different - not everything depends on a network connection. Complex applications that might rely on non-trivial toolkit features are more, not less likely to be native,