Hacker News Reader

Comment by blueflow | Hacker News Reader

The constant GTK rewrites are a disaster. Why should applications even bother starting with GTK(n) if it will be obsolete and incompatible when GTK(n+1) comes around?

View on HN

You're exaggerating. GTK2 came out in 2002, GTK3 in 2011 and GTK4 in 2020. That' s almost a decade for each version, and you have to consider that GTK2 was maintained for a long time after 3's release and that current Linux distros still package it. And the GTK3 to 4 transition required some changes, but far from a rewrite.

If you need multi-decade support from your GUI layer, I can recommend raw Win32 or VT100 terminal codes. There's hardly any other API with that kind of backwards compatibility.

Multi-decade support should be the norm for GUI toolkits. Why should all GUI apps of the world have to be rewritten every decade? That’s just a wasteful use of developer resources, and also a wasteful disruption of end user habituation.

Because requirements change and you can't keep API's sane when only bolting on new functionality. You can disagree about the support timeframe, but in 10-15 years time we've gotten used to high resolution screens, HDR, HFR, multitouch etc. If you don't ever change API's you're leaving a lot of potential on the table.

Windows added all those functions without breaking compatibility. Yes, applications might have to be modified to take advantage of new features that make sense for the application in question, but that doesn’t imply that they should have to switch toolkits.

While Windows doesn’t provide a unified GUI toolkit, win32 UI controls of different generations can be mixed freely within an application, enabling gradual upgrades.

Windows is a paid operating system with thousands of developers working on it. GTK has 3 regular developers. Please step up if you're going to complain.

I guess that’s why the year of the Linux desktop will never come.

>There's hardly any other API with that kind of backwards compatibility.

Qt? 99.99% of the API from Qt 4 (2005) is identical in Qt 6 (ongoing). A few headers were renamed, and a few minor functions, generally stuff you can port in 1 day.

When they released Qt 5 and 6 and decided to switch from Qt Widgets to a new GUI toolkit (QML), they didn't say "umm, just rewrite your whole codebase in QML bro", they kept widgets around in perpetual maintenance mode. This is how you respect your users.

I think what Qt does is a good compromise, but there are breaking changes. Complex FLOSS projects spent months or years upgrading from Qt4 to Qt5 and then to Qt6. The exact timeframe is a matter of priorities and available developers, but someone had to put a not insignificant amount of work into porting. A far cry from decades-long ABI compatibility.

Meanwhile a Windows application compiled 25 years ago still runs today. A Windows application compiled 30 years ago runs with a very small compatibility shim you can ship with it as a DLL.

Having discussed this issue with friends at Microsoft, they apparently spend astronomical amounts of time, money, and effort to maintain backwards compatibility while still adding new capabilities, functionality, and toolkits. They know that this is a key reason many organizations rely on Windows.

I have no specific insight into decision-making in open source organizations, but given that the resources they're working with are several orders of magnitude less it's not surprising to me that they sometimes end up having to choose between stability and new functionality. (While I personally prefer projects towards one end of that spectrum, I'm happy that different projects have different values for other people.)

A big part of it is the ecosystem is mostly/almost entirely open-source, so in theory you can update all your applications to use the new API. So breaking changes are not as big a deal in that world, as they are on Windows where you definitely do not have that option due do the primacy of closed-source software. I think this view is short-sighted, though. If there are 100 users of a given library, then it takes 100x more effort to update all the applications than for the 1 library developer to avoid making breaking changes.

Linus is also kind of obsessive about this at the kernel level. I wish more of the userland shared that priority (cough cough)

Yeah, the driver ABI in Linux is totally stable. Cgroups as well!

> a Windows application compiled 25 years ago still runs today

*Usually, not always.

A GTK 2 application compiled 25 years ago usually still runs today, too. Just because GTK 3 is available doesn't mean GTK 2 stopped existing.

A GTK 2 application compiled 25 years ago was before the Big Glibc Switch that caused us so many headaches in the early 00's, so no, it won't.

My xv copy has a mtime of Aug 4 1998 (pre-compiled binary from the RPM on the website). It runs on my current Void Linux system. Not GTK, but that's a detail: point is it runs, and is 25 years old. I've also run old Opera copies from the 90s, although that's longer ago and I'm not sure if that still works.

It's the downstream projects.

It take 2-3 years to iron out the bugs. Non-gnome downstream take another 3 years to adopt and stabilise.

By the time the adoption is finished, another major version emerges.

We don't have any good way to maintain compatibility that long.

That's assuming downstream is even still around to adopt the new version. There are plenty of simpler tools which are "done" - itch scratched - and the author has long since moved onto new things. Duct-taping the bitrot inflicted by toolkit churn is something that requires resources - if nothing else it consumes time and energy that people could otherwise be spending on current interests and projects. That's where the "open-source means everything's free" mindset can be a problem, since it's just assumed the authors will step up and do work made necessary by the decisions of others, with no remuneration or consideration.

> There's hardly any other API with that kind of backwards compatibility.

X11/Xlib, though obviously you have to do the GUI bits yourself (but then you mentioned VT100 terminal codes so i guess that is acceptable).

Also AFAIK Motif is backwards compatible going back to the 90s.

Motif is compatible, because it is dead.

I meant OpenMotif as pjmlp mentioned. These days it seems to mainly receive patches to keep it working but it maintained API (and ABI where possible) compatibility even when it was more actively developed as it was a design choice, not a byproduct of not receiving updates. AFAIK it is how Lesstif managed to be a (mostly) drop-in binary compatible alternative to Motif before the latter became open source.

Well, there is Open Motif for those that feel like using it.

Reply on news.ycombinator.com