Hacker News new | ask | show | jobs
by linguae 1526 days ago
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 order to allow for different visions of the desktop instead of imposing a particular vision through the toolkit. In fact, starting such a project is something I've been considering for a long time.

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.

3 comments

> 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.
Actaully, it’s not really about doing it server-side or client-side. It’s about how to make client render on windows border. CSD is obviously simpler, but that’s when you do bitmap…
There are several "unopinionated" tookits out there already. Nobody uses them because it is all a matter of popularity. The most popular toolkit by far is called HTML+CSS+Javascript. You might hate it but the point of no return has been passed ages ago. So If you want to make a difference implement a browser with a trusted zone for local applications (which are allowed to occasionally call C-routines to get native speed) that is not controlled by apple or google.
Eh, no. QT5 is THE serious cross-platform toolkit. Everything else it's a turd deserved to be shunned. Microsoft Teams it's seen as a disaster even from die-hard MS users.
It doesn't have to be though, it's not because it's HTML+CSS+JS that it's bad, it's bad because it was poorly written. You can write poor code in any language/toolkit. You can make beautiful and fast apps with HTML+CSS+JS.
You can also make safe and reliable applications in C++, or fast applications in Python, or readable code in 1990's Perl - it's just very difficult, because those languages lend themselves very poorly to those things, and that's why good developers avoid using those languages when those traits are needed.

Heck, you can make fast code in Python by embedding a DSL and writing a native-code compiler for it. Turing completeness means that everything is possible, which means that "possible" isn't interesting - practical is.

Judging by how few fast webtech applications there are, it seems like making them is not very practical.

>readable code in 1990's Perl - it's just very difficult, because those languages lend themselves very poorly to those things

Perl is not Forth. I know y'all know Perl because of Gold code contexts and oneliners, but look at some games written in Perl and tell me Perl is not readable.

Better, get the free books from Orelly:

https://docstore.mik.ua/orelly/index.htm

The 4th version is updated enough.

Alright, maybe Forth would have been a better example for that point...