Hacker News Reader

Comment by _dh54 | Hacker News Reader

If GTK is operating in a situation where there is no “rich corporate force” to sponsor the maintenance of old versions then it is a strategic error for them to break backwards compatibility.

At this point I cannot imagine a sane third party application developer choosing to build on top of GTK. The clock starts ticking on the life of your application the moment you choose GTK.

View on HN

The alternative would be never refactoring anything and allowing technical debt and complexity to balloon out of control, which would also be a strategic error for a small project without many resources.

The ticking clock you're referring to is real, but it applies to any open source library you're depending on that you aren't contributing anything to, not just GTK. It can't be avoided just by switching to another open source toolkit. If it really bothers you, start contributing and help out!

Contributing to each dependency you use is not realistic. What instead happens is that people leave GTK for more stable dependencies. This is what I did. That's what many likely choose to do.

Jumping from dependency to dependency forever hoping that someone else is always going to do the right thing is not a viable option long term, even moreso if you want to build a large application that lasts a while.

Realistically, most people who decide to ditch GTK seem to switch to Qt and either start contributing there or pay for consulting/LTS/commercial licenses eventually, because that is the only comparably modern option for native widgets on Linux/BSD.

Moving from one toolkit to another is an expensive and tedious process. Speaking from experience, those who need to do it tend to do it once and they do their homework to make sure that the toolkit they choose has a sane API development process.

So yes, jumping from dependency to dependency is not a viable option long term. Luckily you only need to jump away from GTK once.

You also only need to jump away from Qt once, if that doesn't work for you for whatever reason. If the toolkit is open source, and your "homework" doesn't include looking into the contribution process and how it goes working with upstream, then I would say you are doing yourself a disservice considering how this is the most critical dependency that a GUI application has. That gets more important the more your project gets invested in the toolkit, doubly so if you aren't paying for support. (Essentially that means you're supporting it yourself or relying on flaky advice from IRC and stack overflow, all the usual caveats apply there. Ignoring upstream and refusing to talk to them or collaborate is really not going to help you in that case)

Of course, but that "homework" would also include considering the incentives and goals of the authors behind the toolkit. If we took the authors of Qt as an example, their incentives and goals are clear. If they needlessly break their API, they will loose their customers and go bankrupt. These incentives have translated in one of the most smoothest major GUI toolkit transitions I've seen (Qt4 to Qt5).

As far as contribution processes go, both upstreams are equally tedious to work with. I doubt GTK would be willing to accept your code contribution if you added systray icons support back to GTK4 for example. So while the contribution process does matter, it doesn't matter as much as you make it out to be.

I don't think Qt4 to Qt5 is a fair comparison. The really substantial changes here are getting closer to what you would have to do to port an application from Qt Widgets to QML/QtQuick, although not quite as drastic. (The whole scene graph design has changed, but you don't need to change all of your widgets to use it effectively, only some of them) The incentive here is the same: Make a modern and flexible toolkit that works for a wide range of applications. If something is deprecated and removed with no replacement or migration plan, it's the same thing there too: customers didn't see enough of a need to pay for it to happen.

AFAIK the systray icon support in GTK was removed because nobody was willing to maintain it. I don't think that's a great example because it doesn't even need to be in GTK anyway, it relies entirely on platform-specific functionality and has little to do with the toolkit. Someone can just make a library for that. (And I think Ubuntu did, but it was not upstreamed for a few reasons, one of them being that it didn't support multiple platforms) Regardless, that is the point I was getting at. The upstream policy is really not that different between these projects, you can't avoid it just by jumping ship.

It’s not like Google starting a new framework and abandoning another every six months. GTK2 was released in 2002 and is still under maintenance.

> The alternative would be never refactoring anything and allowing technical debt and complexity to balloon out of control

It’s simply false that retaining API backwards compatibility prevents refactoring and necessarily causes technical debt to balloon.

Reply on news.ycombinator.com