So much fighting over how best to draw the UI that will launch various instances of the Chrome engine.

Want to know why everything is written in Electron or as a web app? Because literally every desktop platform over the last decade has decided to play design and engineering games instead of just make a really solid stable base to write apps on top of.

>That KDE Plasma 5 is finally usable and stable, after having decided to stop pushing the ridiculous plasmoids on the user (were they liking the Windows Desktop Gadgets, or they were simply idiots?), is like having an old whore finally becoming a respectable woman. It’s hard to forget the developers’ idiotic decisions, though. I don’t like to be Microsoft’s guinea pig, why should I be KDE’s?

This attitude describes why there is no future for Linux desktop.

Given non-GNOME developers' frustration with increasingly GNOME-centric releases of GTK, and given some of the licensing issues surrounding Qt (such as the one-year delay for FOSS releases of the toolkit: see https://news.ycombinator.com/item?id=25748335), I believe the time is ripe for a BSD-licensed GUI toolkit for X11 and Wayland that uses server-side decorations and tries to be as unopinionated as possible in order to allow for different visions of the desktop instead of imposing a particular vision through the toolkit. In fact, starting such a project is something I've been considering for a long time.

If only had GNUstep (http://www.gnustep.org/) been the toolkit for the Linux desktop instead of the Qt vs GTK/GNOME wars; this would have saved a lot of drama regarding toolkits. Back in the mid-2000's it appeared that the matter was settled during the KDE 3 and GNOME 2 days; a lot of people seemed to be happy with these desktops, and those who preferred non-GNOME Gtk desktops and applications had plenty of options. However, ever since GNOME 3 the GNOME developers have been able to mold GTK to its vision at the expense of other GTK users who didn't share GNOME's vision. Qt is less opinionated, but its stewardship is up to the whims of whatever company that owns it. GNUstep is free from these issues, but it never received mass adoption.

Come to think about it, maybe instead of a new toolkit, maybe we should look into GNUstep some more and consider investing our developer resources into building a GNUstep desktop ecosystem. But I'm curious about what other people are thinking.

The tone of that article makes sure that I stop reading after 2 paragraphs.

Yes. GNOME is better than ever, GTK4+Libadwaita is simply doing one: Looking perfect.

The HIG are excellent, without GNOME I would be maybe 40% as productive as with it.

I'm using KDE5 at the moment, and it's essentially problem-free. It's got more features than I know what to do with, but this somehow doesn't detract from it but rather enhances it.

KDE5 never seems to be the default choice of desktop environment for distros like Manjaro, but you're unlikely to go wrong picking it as your default option, if you're given that option.

Programming GTK+ programs in C is rather unpleasant in my limited experience.

Despite the set of signals supported by widgets being a fixed part of the documented API, there aren't even explicitly typed-checked function signatures for callbacks appropriate for those signals. The docs tell you what the function signature needs to be for a specific signal like "clicked", but since all the callbacks basically get thrown into a generalized dictionary of void * keyed by signal name hanging off gobject, there's literally ZERO type checking of the callbacks your program installs on signals.

Segfaults because your callback had the wrong parameter types/arity for the signal you connected is the norm, and that's arguably the best scenario. You can also install a callback on a signal that expects a gboolean return, and your callback returns void, welp, no segfault, but unpredictable behavior. It's kind of awful, there won't be any compile-time errors when making these mistakes, despite being C.

It feels like someone learned how to implement a dictionary then made gobject and built a GUI on top of it with dictionaries all the way down. I don't want runtime dictionaries used for representing any set of things known at compile-time. Fine, use dictionaries for runtime-defined signals, but why the hell am I suffering this way for the things fully known by the toolkit before I even started writing my GTK+ program? Sigh. I may as well just write javascript.

Fast windows 95 would have been fine. Instead the devs lost their minds w design craziness. VS Code and chrome pycharm etc means it’s not a huge deal - they are all x platform

Yep, Nautilus is "unusable" without the compact view.

Idiotic hyperbole like this is where I stop reading. How can I take anything beyond that seriously?

I was an Xfce core maintainer from around 2004 to 2009. In addition to my work on Xfce, I also built a media player, and played around with some other projects that never really went anywhere. GTK2 had its warts, but it was generally fairly easy to build things, and it was fairly easy to work around things when something didn't work the way I wanted.

GTK3 changed a lot of this. Many things that were previously public were now considered private implementation details. Much of that was perfectly understandable (necessary, even), but occasionally this meant that there were things you could do in GTK2, but just couldn't in GTK3 (or could, but doing so was a huge pain in the ass). GTK3 deprecated or outright removed some things in GTK2, and it wasn't often clear what the supported replacement was supposed to be. The theming/styling system was completely replaced, which meant redoing themes, and any app that used theming APIs had to have that part completely rewritten.

On occasion I would report issues to the GTK folks, or would watch issues others had reported that I was interested in, and responses were all over the map, from helpful and welcoming, to actively hostile. What became very clear was that the GTK developers, over time, started only caring about the GNOME use cases. If you were using GTK for something non-GNOME, the GTK developers did not care about you, and would not reverse decisions that (incidentally or otherwise) broke your ability to do what you wanted to do.

I get it: as an open source developer, you have your own priorities, and you're usually not beholden to your users for features or any particular work. I certainly did not care for it when people not contributing to my software would demand I do things for them. But man, did it suck to constantly feel like the rug was getting pulled out from under me.

I haven't touched GTK4 yet, but judging from what I've read about it, I really don't want to. I used Qt a bit around the early '00s, and kinda liked it, but didn't love it (granted, I'm sure things are unrecognizably different now, for better or worse). Regardless, these days I have zero interest in writing C++. (To be perfectly honest, I have little interest in writing C either.) My hope is that one of the pure-Rust UI toolkits will take off, but at the same time that doesn't help existing C/C++ projects, since new-language rewrites are painful and often counter-productive. And on top of that, it just sucks to have more UI toolkit proliferation, which makes it harder to style things so the various apps on your desktop look reasonably consistent with each other.

Of course, my happy place would be Xfce rewritten to use a modern UI toolkit that is not GTK (or Qt, for that matter). (I would prefer Rust, but see above re: new-language rewrites.) But if we all thought the GTK2->GTK3 effort for Xfce took a really long time, rewriting using a new toolkit (let alone a new language) would likely take a decade. We were always understaffed when I was involved, with Xfce being a spare-time, volunteer, passion project for everyone involved (I believe one guy was paid for a while to work on Xfce-related things, but not for all that long). Not sure how much that's changed, but I wouldn't expect much corporate backing, despite Olivier (the project lead) working for Red Hat.

Just use Tk, problem solved :-) - https://tkdocs.com/

I agree with some of this, though it is perhaps a bit overly harsh at times. Frankly, I’m not terribly impressed by the direction that Qt has taken either, though. This puts the open source desktop in a pretty unfortunate place…

As a consumer of desktop environments (and not a GUI application developer) I think that GTK based desktop environments are in the best place they have ever been and Linux as a DE for 'normal' people is a reasonable option in a way it never has been in the past.

Gnome on Fedora is a solid experience. It works well out of the box, it's performant, intuitive, well designed and good looking. I'm sure it rubs some developers the wrong way (there are always some) but based on my (small sample size) observation of people using it, it seems to be intuitive. It's not just Gnome - Wayland is part of the picture because it makes things like multi-monitor more reliable too. We're past the performance issues that the current version of Gnome had to start with, and Wayland is continually having the issues eliminated (once the last few screen sharing ones are dealt with there won't be loads to complain about).

Feels like 80/20 class problem. 80% working, same effort to close 80% of the remaining 20% and recurse enough times you wind up burned out. Now add rewrites and factionalism and dissent.

They don't love and nurture each other and they don't love their users either.

I used to care. As a user I can't buy into it any more.

A preface: I use GNOME and KDE on separate devices. I have tried i3 and intend to return to it when graced with more time to customise it. Importantly, I used GNOME before GTK3 happened.

I mention the above as preface because I see these kinds of posts on this website a lot and they are very misleading, and I believe I have the credentials to explain why.

If you skim the original article you could be forgiven for thinking that it is a well researched and justified piece of writing, but I would like to challenge that. In particular, I note that a lot of 'evidence' for the claims of GTKs downfall are hinged in the author's preexisting expectations (and bizarre tangents - who gives a shit about title bars one way or another in a conversation about software maintenance? Scope pls).

One very revealing assumption by the author is the idea that a major release of a community project such as GTK3 should be free of bugs. This seems very obvious to an end user. 'Of course a major release should be stable! What are you saying? I need my servers to be reliable so I can feed my kids! Not everyone lives in fantasy land like you, plaguepilled!'

But there are actually two assumptions being made here. The first is that major releases of FOSS should be free of bugs and not corrected with time, and the second assumption is that this is no harder to accomplish than for a commercial entity.

However, crucially, the open source software community has had a huge shortage of maintainers for at least a decade now. Look up your favourite utility, then look up the team supporting it: often it is one person who is very, very over it. This can contribute to the phenomenon of fixes that come after the major release, not with it.

In fact, this single fact can explain why major projects that 'weren't broken' seemingly 'choose' to self sabotage. The GNOME team are not stupid. They are heavily under-resourced. The same can be said for KDE and even the Linux kernel teams. If that bothers you, it is far more productive to actually contribute your time to fixing the issue than simply describing it while waxing lyrical about how all these modern devs have simply 'lost the way'.

But I am here to contend that the idea of flawless FOSS is itself bizarre. Wealth inequality is a major issue in 2022 and proposing that the existing body of skilled software engineers should provide enterprise level software, consistently, without pay, is insane. If you care about software support and are not paying, and you do not yourself write FOSS software, you are at best a hypocrite, and at worst attempting to exploit people.

I am a fan of FOSS and want it to be better, but this article is not the way to that future.

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.

> My ultimate prediction is that within about three years after GTK 5 is released, touchscreens will go out of vogue

haven't they already ? I remember buying much more easily a computer with a touchscreen in 2011 than today, at some point every other model had it, but now it feels like NVidia's 3D Vision in its end times.

Same for tablets, when I check analytics for my website, tablet use is pretty much zero.

I think there's a future for STLWRT. All was right with the world when Linux looked like this: https://www.linglom.com/images/Linux/ChangeIPAddress/1.png I still run RHEL5 and use it everyday. I don't even consider it that old.

All I got out of this blog post is that its author appears incredibly toxic. There's no need to waste your time with it.

"Is the Linux desktop heading south?"

There is a whole world out there. I use fvwm as a "desktop environment" with MC as file manager. I also find the idea of "desktop environment" a bit old. Even on windows 10 every programm behaves differently. Even MS is not able to have a unique look and feel in its own programms.

I use Fluxbox (slightly tweaked Zukitre theme), lxappearance, Tango2 icons and Rox filer with a bunch of plugins among Rox-Lib under ~/lib.

90% CLI oriented but with common sensical GUI plugins and settings.

The best of both words, and a "DE" with unmatched speeds.

Yes, Xfce is working perfectly as it was for the last 7-8 years

<<So, if GTK+ 3 flopped, how are we where we are today, with GTK+ 3 suddenly being forced down our throats? It turns out it was probably started by Red Hat.>>

Systemd, gnome 3, I think that it is Red hat that ruined the desktop experience in the last decade by imposing terrible choices on everyone else...

> uses server-side decorations and tries to be as unopinionated as possible

You are contradicting yourself. Some people think decorations should be server-side others think client-side. So it seems what is better is an opinion.

There are several "unopinionated" tookits out there already. Nobody uses them because it is all a matter of popularity. The most popular toolkit by far is called HTML+CSS+Javascript. You might hate it but the point of no return has been passed ages ago. So If you want to make a difference implement a browser with a trusted zone for local applications (which are allowed to occasionally call C-routines to get native speed) that is not controlled by apple or google.

This really echoes with me too, I have a semi-big (but not so popular, at least not any more) application [1] that has gone through GTK+ 1.x, ported to 2.x, ported to GTK3, that I feel I "should" port to GTK4 since it's out.

But I just can't be bothered to even try to prioritize that since all I read about v4 is anger, weird new libraries with strange names ("libadwaita" sounds like a Disney character library) and stuff.

It really felt back in the day like the developers bringing out GTK+ 2.x where, like, on the case and really doing good clever work to bring out a solid platform for application development, and for a while (at least to me, but I was very biased even then) it was the mainstream/default/major choice in Linux GUI application development. Sure some people liked Qt but GTK felt like the home turf.

[1] The strangely-named "gentoo" file manager; I don't even think the site is up, sorry.

I believe a start would be to write a Rust wrapper around of Qt and GTK (and other platforms native stuff). Probably using out-of-process integration.

> If that bothers you, it is far more productive to actually contribute your time to fixing the issue than simply describing it while waxing lyrical about how all these modern devs have simply 'lost the way'.

I agree with that sentiment in principle. In fact, I advocate the same myself.

However, playing the devils advocate, all an individual non-core developer can do is try to smooth out the rough edges.

If the complaint is "you removed this option", it doesn't matter if the complainer provides a patch to put it back - the powers in charge of that project already have the code (it was there before they removed it, after all), so providing a patch to add it back in is pointless.

The non-bug complaints in general (still devils advocate) are not that the software is missing a feature, it's that the direction it is going (or has gone) in is alienating the existing users.

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.

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