Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ludditus.com

Post reply on HN
Print view View original

31–40 of 142 posts

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

#31

Post by linguae »

legulere wrote: post #29
linguae wrote: post #19

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 or…

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

Good point. "As unopinionated as possible" should be the emphasis. Perhaps the toolkit could support both types of decorations, with flags that enforce which decoration policy is used.

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

#32

Post by GekkePrutser »

ogogmad wrote: post #9

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.

Doesn't SUSE have KDE by default?

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.

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

#33

Post by silon42 »

kelnos wrote: post #4

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…

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.

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

#34

Post by AnonymousPlanet »

onphonenow wrote: post #10

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

Not for people who are not mentally stuck in the 90s. I am very glad things have processed and have left the ugliness and usabilitly problems of Windows 95 in the past.

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

#35

Post by hvdijk »

mavu wrote: post #24

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

I did not last even two paragraphs: I clicked through on "Ubuntu MATE cannot be trusted" and found something better summarised as "I tried getting away with calling people idiots on Ubuntu MATE forums in a bizarre social experiment and cannot deal with them not putting up with that."

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

#36

Post by bayesian_horse »

alxlaz wrote: post #30
lapser wrote: post #27

Earlier quoted context omitted.

I don't know about Qt but at least GTK's docs are terribly bad. Even more so when you want to develop using a language that isn't C.

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.

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

#37

Post by pengaru »

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.

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

#38

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

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

#39

Post by sph »

pengaru wrote: post #37

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…

Modern versions of GTK+ support Rust, Python and Javascript. I love GNOME, but I think there's a decent group of people that would like a Rust-based GTK+ desktop environment.

https://github.com/gtk-rs/gtk3-rs

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

#40

Post by sph »

morsch wrote: post #5
com2kid wrote: post #2

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.

And then the calculator app, which is native, is wrapped up in some sort of isolating container that makes it take as long to start up as an electron app.

You're using the wrong isolating container ;) There's only one that is quite slow at startup, the other isn't.
Post reply on HN