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.
The big draw for Electron is that we have way way way more web developers out there these days than native-code desktop UI developers, so it's easy to leverage those people and get results fairly quickly, even if the resulting apps don't really conform to any desktop's standard look-and-feel (which I guess avoids the uncanny valley effect of cross-platform toolkits that try to be native, but fail in subtle and not-so-subtle ways). People can even just (sorta) repackage their existing webapp, and end up with more or less a single code base for all desktop platforms + web.
I do agree with you that most of the desktop platforms are pretty annoying to develop for if you want a solid, stable base, but I don't think that's the prevailing reason for Electron's uptake.
but the "way way more web developers" you mention are not, at least in the context of electron apps, interested in that feature except tangentially..
so while everyone knows a full web-ready browser engine is impractical to design from scratch, maybe a simplified engine that supports a conservative subset of best-practices web-style design is in order?
The only annoyance was the breakage that Wayland introduced in 2016. Suddenly you couldn't screen capture the whole screen anymore. It's kinda the same issue as switching from python 2 to 3 but the difference here is that it is a major upgrade that is worth the effort. The reasons why python 3 isn't backwards compatible are incredibly petty for the most part. However, firefox has received Wayland support for screensharing and some people developed a plugin for OBS. Wayland works just fine now too.
This attitude describes why there is no future for Linux desktop.
This has nothing to do with OSS though. You can switch from a closed sources solution too.
The problem is you investment and attachment to certain things.
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.
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.
* OP: "If a distro with 60k packages cannot accommodate one or three extra packages for an official flavor, then someone is an idiot, and that idiot is not me."
* Moderator came and ask to not talk like this.
* OP: "Censorship, simply because I used the word “idiot” without naming anyone in particular!", and OP continue.
* Moderator close the tread.
* OP: "Then the little Stalin closed my thread".
This is not serious. OP doesn't named anyone but hide himself with a general attack to package maintainer (maybe this maintainer is alone). Hiding its attitude behind word meaning is something my 9 years old son is starting to do and I try to explain him its not a valid excuse.
OP should revise it's social expectations.
It's hard enough to keep big open source projects on rails without having childish attitude like this.
The HIG are excellent, without GNOME I would be maybe 40% as productive as with it.
I want small, high quality apps like macOS has. I want to make a living building open source software that can be supported and bought commercially—no, donations and sponsoring isn't good enough. I want companies being able to sell their software on Linux through the integrated app store, now that it's finally become good enough.
1: Plenty Linux users think FOSS means never having to pay for software, or that commercial software will kill us all and it's morally wrong. I strongly disagree.
2: https://discourse.flathub.org/t/seeking-contractors-for-work...
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.
I use it on FreeBSD myself. It's an amazing desktop. I don't like gnome at all. It uses too much screen space (huge touch style window decorations) and doesn't have enough customisation for me. But KDE is perfect.
Apart from KDE Neon, and Garuda, and...
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.
There's no need to be throwing all this up-front known crap into a runtime constructed dictionary.
If the widget has a "clicked" signal, there should be a typedef of the callback function appropriate for that signal and the widget struct should have a clicked_cb member for a list of callbacks of that type. Then there should simply be a unique function for installing the callback on that signal on a widget. At least then the compiler can tell you when you're mixing up callbacks<->signals for API-defined signals. It's not even complicated.
Cosmic desktop.
https://blog.system76.com/post/655369428109869056/popos-2104...
There's a time and place for minimalism, but the term "power user" also has a meaning: your accumulated user-base that didn't leave.
Windows post-Vista has forced me and countless others into never bothering again. The fact of a 90's MCSE certification means nothing when I blankly gaze at the visage of a "modern" Windows UI that tells me nothing of import. M$ basically told all their power users to go away.
And I think this is why Linux on the desktop is going no where soon. The Win 95 interface / control panel / taskbar / start menu was very discoverable for many. In corporate environments it was THE go to interface forever. Yes, KDE and its plasmoids, Windows and it's "live tiles" are the new hotness, but for folks just looking to work the "cool" fly in fly out effects, secret touch points (move mouse to side or top of screen etc) etc are just losers.
You could RDP into a Win95 box set to best performance and basically not know you were remote. All the fancy animations are actually a negative in many environments.
Microsoft itself keeps on trying out new things, but user pressure gets them going back to older ideas.
You can't be more wrong. Windows 95 was built on solving usability issues.
My fluxbox+rox env has a Windows 95 taskbar albeit 10% shorter on the left and right sides so I can right click for the menu fine.
Idiotic hyperbole like this is where I stop reading. How can I take anything beyond that seriously?
Hopefully they can see comments like 'gtk+3 wasn't even backwards compatible with gtk+2' for what they are. (i.e. no shit, hence the major version change).
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.
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.
But you're right there was a lot more developers and funding involved in GTK2 days.
That doesn't really solve the problem, though. You still have all of GTK's baggage, just usable from Rust.
If Qt were ever to become closed source again, it would probably face a very strong competitor in a BSD or Apache-licensed fork from KDE. The Qt Company sells its licenses mostly to people that want to use GPL-covered Qt modules in closed source apps, so they really cannot let that to happen.
That said, I still think the direction of Qt has kind of sucked. QtWidgets is mostly stagnating, and Qt Quick is not really appealing to me…
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).
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.
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.
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.
In regards to the topic of user base alienation: I do think it is an important metric to keep track of, but whether it should be prioritised is contextual. In the case of GNOME, they have frequently made a point that accessibility is a large focus for them. Accessibility is not the same as making their core user base familiar with their software.
Said another way, I believe that making an argument that even with their limited resources, GNOME are not sufficiently servicing their users is ignoring the purpose they wish to serve. Their goal is not to minimise change - that is more in line with xfce, i3, or even DWM.
In contrast, I believe attending to existing users is important for KDE, because their core goals are centred on choice. Therefore, it would be antithetical to their goals to restrict choice.
To summarise my angle, alienation is sometimes important, but not here. It would be more expected if GNOME were better staffed (and so extended scope and service guarantees), which brings me to my next point.
You made an interesting point about how a cranky individual that lamented the loss of a feature would not be able to 'change' the upstream attitude. This is true, but it slightly misses what I am trying to say. I am not advocating for the submission of singular patches in response to singular grievances.
Instead, what I am suggesting is that people who are interested in the survival of projects become involved with the long-term (or even just the mid term) running of the project.
This will not only give them greater influence in how the software is written, it will also mean that, as I alluded to before, scope and service can expand.
Being involved with a project also means you will become better informed on how the code base operates. With that knowledge, you could more easily maintain a fork of the project that supports your chosen feature.
Is that a lot of work? Yes - which returns to my original point. Regular contribution is a huge difference that unhappy people should earnestly consider. It may require contributors to go along with decisions they don't like, but with time comes practice, then experience, then trust, then influence.
Or, in a sentence: you can improve these projects in the way you see fit if you take the steps required.
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.
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.
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.
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,
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.
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.
90% CLI oriented but with common sensical GUI plugins and settings.
The best of both words, and a "DE" with unmatched speeds.
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...
My biggest gripe with systemd unit files is that there are at least four ways of specifying dependencies (Wants, BindsTo, After, Requires) and the semantics are not easily understandable.
