GNOME policy pushed into GTK3 and newer

Posted Jan 25, 2026 23:03 UTC (Sun) by mbunkus (subscriber, #87248)
In reply to: GNOME policy pushed into GTK3 and newer by N0NB
Parent article: Debian discusses removing GTK 2 for forky

Quite a while ago there was a talk by Dirk Hohndel & Linus Torvalds about how and why they decided to port their divelog application, Subsurface, from GTK to Qt. It's on Youtube. Some of the reasons they pointed out were deprecations & removals, a rather unhelpful/unresponsive community, and a bad cross-platform compatibility story. Some of that mirrors what you wrote about. It was a pretty interesting talk, worth watching.

I recommend you look into porting your application, too. If it's a simple GUI based mostly if not exclusively on standard elements without custom styling requirements, getting it up & running with Qt should be pretty easy (context: I ported MKVToolNix from wxWidgets to Qt quite a while ago and never regretted it). Qt has a much better story of feature removal. They do deprecate & remove stuff, but at a much slower pace with much fewer surprise mass changes. For example, I pretty much did the port from Qt 5 to supporting compilation with both 5 & Qt 6 in a handful of hours on a rainy Sunday. The amount of pre-processor shenanigans required were minimal.

to post comments

GNOME policy pushed into GTK3 and newer

Posted Jan 31, 2026 13:31 UTC (Sat) by N0NB (guest, #3407) [Link] (3 responses)

Porting to Qt would require that the application be ported to some flavor of C++, no? My understanding is that Qt doesn't have a C interface. If so, it would seem that my choices are to rewrite in something else, thus likely completely changing the flavor of the app, or let it die. It seems things are already well on the way of the path of the latter choice.

GNOME policy pushed into GTK3 and newer

Posted Jan 31, 2026 16:07 UTC (Sat) by mbunkus (subscriber, #87248) [Link] (2 responses)

Well, partially. The parts that directly do things with the UI. However, you can run mixed C/C++ codebases in the same program/project (I've done this for years for… reasons). Or compile your C stuff as a static library that you link in. This is viable if you have big parts of code that doesn't directly do things with the UI, e.g. network stuff, calculations, data shuffling etc.

You can reduce the amount of C++ to write further by using Qt's built-in Qt Quick library with the built-in QML markup language. With these two you can design standard UI things such as main windows, menus, dialogs, all the usual default widgets (buttons, list/tree views, text, text inputs…), event listeners etc. using a pretty simple & easy to understand language. Then call your existing/slightly modified C code from those event listeners or wherever it fits.

I'm not saying it's going to be trivial; you still have to learn a small subset of C++. However, the amount you have to learn is very small compared to the size of the whole language.

If all of this is viable at all I cannot tell, of course, as I don't know your original application. I'm just saying, if you're not ready to let your app go & up for a little adventure, this might be worth taking a look, e.g.

https://doc.qt.io/qt-6/qmlapplications.html

GNOME policy pushed into GTK3 and newer

Posted Feb 2, 2026 9:46 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

I would argue that a complete change of code architecture like that, even ignoring the requirement to learn C++ and Qt to do it, is probably too much effort for any application that is so low on developer resources that they are still stuck on Gtk 2 at this point.

GNOME policy pushed into GTK3 and newer

Posted Feb 2, 2026 10:34 UTC (Mon) by mbunkus (subscriber, #87248) [Link]

Given the situation that any way to keep alive that application involved a significant amount of work, all I wanted to do is point out a route I've gone down before that is kind of a middle between "rewrite everything" and "keep everything as-is", onto a platform whose track record for stability and compatibility is quite a bit better than GTK's, instead of simply saying "well just give up, then".

I'm not trying to evangelize, just offer more options. Maybe this is way too much work. That's perfectly fine! Maybe they decide to convert to GTK 3 after all. That'd be great! Maybe they'll indeed sunset the program. An absolutely viable and understandable choice!