Live data from Hacker News

Is there any future for the GTK-based Desktop Environments?

ludditus.com

81–90 of 142 posts

Re: Is there any future for the GTK-based Desktop Environments?

#81

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

I agree. Red Hat to me almost feels like a corporate trojan horse taking over open source projects to undermine them from within.

Re: Is there any future for the GTK-based Desktop Environments?

#82
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.

Re: Is there any future for the GTK-based Desktop Environments?

#83
post #30

Earlier quoted context omitted.

I'm not sure how they've kept up, as I haven't used Qt in some time, but back in the 4.x days the documentation was absolutely stellar. Extremely thorough and almost every non-trivial feature came with code samples. I couldn't for the life of me understand why anyone was using GTK at the time.

My point is not about lack of usability or documentation. Rather that the nature of HTML+CSS+JS lets you do things you can't do as easily in either GTK or QT. In the latter, yes you can easily achieve a certain kind of UI, but not deviate from it, and even formatting/displaying a significant amount of information that doesn't fit into one of the classic widgets can be a bit of a pain.

Qt also has QML which allows you to do things similar to what you would have with the combination of HTML,CSS and JS

Re: Is there any future for the GTK-based Desktop Environments?

#84
post #64
post #50

Earlier quoted context omitted.

Just imagine you need a container for the calculator.....

OpenBSD went that route, and when they introduced pledge(2) and later unveil(2), they've applied these to every single program in the base system (over the course of a single release cycle!). There's absolutely zero reason for bc(1) to accept network connections, or for grep(1) to execve(2) into arbitrary programs. But both of these programs need to process and interpret arbitrary input, which makes them potential ta…

OpenBSD's pledge and unveil are intrinsic while Linux crappy sandbox it's extrinsic...

Re: Is there any future for the GTK-based Desktop Environments?

#85
post #63
post #57

Earlier quoted context omitted.

Just imagine getting pwned by malware bundled in a calculator...

What is the connection here? Why would you install the calculator not coming from your distribution?

In my particular case: I don't want to wait months or even years for updates to arrive in my distribution. With the Flatpak version I get updates usually on the same day they are published, since the Flatpak is also maintained by the calculator developers, and I also get a calculator which can't access my ssh keys or the internet, due to sandboxing. And in case of any breakage, I can also quickly roll back to the last version.

Without flatpak I'd need to use some rolling release distribution, where not just a few applications get updated quickly, but also the rest of the system, which I'm not interested in.

Re: Is there any future for the GTK-based Desktop Environments?

#86
post #6

Earlier quoted context omitted.

I don't think that's really the reason for Electron's popularity. While GTK and Qt are cross-platform, my (limited, to be fair) experience with building for multiple platforms was that it was a huge pain in the ass, and Windows and macOS platform integration often felt clunky and out of place. The big draw for Electron is that we have way way way more web developers out there these days than native-code desktop UI de…

a big part of why browser engines are so unwieldy is the implied compatibility with every website ever, right? 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…

That's a really interesting idea, but in practice you might find that the "conservative sunset" ends up being different for every toolkit and developer.

Maybe something a bit opinionated, like a React Native-only runtime, could fit the bill here.

Or in a sense, is this what Flutter is?

Re: Is there any future for the GTK-based Desktop Environments?

#87
post #82

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.

Another fluxbox user here. I've basically ran the same configuration for nearly 15 years now. Everything is in muscle memory and never changes. Totally the best UX

Re: Is there any future for the GTK-based Desktop Environments?

#88
post #49

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.

Hot take: Only having menus are bad UX because they force the human to search for things instead of making the computer search. I have zero fond memories of trying to find options in the giant menu structures of larger applications. I especially don't understand the reverence of the old-style start menus without a search field many seem to have.

Re: Is there any future for the GTK-based Desktop Environments?

#89
post #6

Earlier quoted context omitted.

I don't think that's really the reason for Electron's popularity. While GTK and Qt are cross-platform, my (limited, to be fair) experience with building for multiple platforms was that it was a huge pain in the ass, and Windows and macOS platform integration often felt clunky and out of place. The big draw for Electron is that we have way way way more web developers out there these days than native-code desktop UI de…

a big part of why browser engines are so unwieldy is the implied compatibility with every website ever, right? 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…

There are a bunch of “small subset of HTML” UI toolkits already. The first that comes to mind is Sciter: https://sciter.com/ which bundles QuickJS interpreter, built in support for React-like syntax, and a HTML/CSS like markup and rendering environment. You’ll see on the homepage how it’s used in many products you might have heard of.

The issue here is re-use - Sciter is small and very fast, but won’t run an arbitrary existing web app that targets Chrome. Maybe you could argue for a middler-ground, add more HTML features to Sciter until it can run “most” things… but you’ll end up back to having the whole banana.

Post reply on HN