by rohshall on 4/8/22, 4:05 AM with 138 comments
by com2kid on 4/8/22, 5:42 AM
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.
by new_user_final on 4/8/22, 6:19 AM
This attitude describes why there is no future for Linux desktop.
by linguae on 4/8/22, 8:11 AM
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.
by mavu on 4/8/22, 8:20 AM
by JCWasmx86 on 4/8/22, 8:07 AM
The HIG are excellent, without GNOME I would be maybe 40% as productive as with it.
by ogogmad on 4/8/22, 7:33 AM
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.
by pengaru on 4/8/22, 8:43 AM
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.
by onphonenow on 4/8/22, 7:37 AM
by denismi on 4/8/22, 9:03 AM
Idiotic hyperbole like this is where I stop reading. How can I take anything beyond that seriously?
by kelnos on 4/8/22, 5:49 AM
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.
by cmacleod4 on 4/8/22, 11:12 AM
by jchw on 4/8/22, 5:46 AM
by rkangel on 4/8/22, 1:41 PM
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).
by ggm on 4/8/22, 7:52 AM
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.
by plaguepilled on 4/8/22, 9:49 AM
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.
by syntheweave on 4/8/22, 8:44 AM
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.
by jcelerier on 4/8/22, 8:51 AM
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.
by jart on 4/8/22, 9:07 AM
by seba_dos1 on 4/8/22, 11:57 AM
by hulitu on 4/8/22, 1:56 PM
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.
by anthk on 4/8/22, 11:47 AM
90% CLI oriented but with common sensical GUI plugins and settings.
The best of both words, and a "DE" with unmatched speeds.
by wooque on 4/8/22, 10:17 AM
by greatgib on 4/8/22, 8:09 AM
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...
