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

41–50 of 142 posts

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

#41

Post by sph »

new_user_final wrote: post #8

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

Not all random users with a blog and an opinion are in charge of the future of the Linux desktop, thankfully.

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

#42

Post by jcelerier »

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

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

#43

Post by sph »

konart wrote: post #21
JCWasmx86 wrote: post #16

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.

This. Now if only people start investing in UI\UX on linux desktop.

Honestly, the real hurdle now seems to be the support for paid apps. It's such a taboo in the Linux world, for some reason [1], but thankfully Flatpak and Flathub are working towards that goal [2], which ElementaryOS already explored.

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

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

#44

Post by pengaru »

sph wrote: post #39
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

This isn't some C problem, this is a GTK+ problem.

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 callbackssignals for API-defined signals. It's not even complicated.

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

#45

Post by charcircuit »

kelnos wrote: post #6
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.

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…

My experience of building an electron application for multiple platforms was similarly painful. When you are writing native specific code, you have to write native specific code regardless of if you use Qt or electron. Something has to interface with the operating system. Either you use someone else's code that is cross platform, or you write your own cross platform code.

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

#48

Post by kelnos »

silon42 wrote: post #33
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.

There are already Rust wrappers for GTK and Qt.

That doesn't really solve the problem, though. You still have all of GTK's baggage, just usable from Rust.

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

#50

Post by nix23 »

sph wrote: post #40
morsch wrote: post #5

Earlier quoted context omitted.

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.

Just imagine you need a container for the calculator.....
Post reply on HN