GNOME policy pushed into GTK3 and newer

Posted Jan 25, 2026 14:40 UTC (Sun) by N0NB (guest, #3407)
Parent article: Debian discusses removing GTK 2 for forky

Some years back I took over maintenance of a favorite niche application (amateur radio). It is a C program written against GTK2. Its UI is relatively simple, mainly one screen with a handful of popup windows. I naively set about porting it to GTK3 and learned a number of things.

The most obvious one I learned is that GTK3 was no longer a general purpose GUI toolkit as elements such as icons in menus were deprecated and difficult to retain in the app's UI. The reason I wanted to keep icons in the menus is that the app, while being multi-lingual with GNU gettext, was obviously used in many parts of the world and retaining the UX of the GTK2 based version would ease the transition for users that didn't have a native language version. Apparently GNOME policy is to not have icons in drop down menus which is fine but should that decision have been pushed down into GTK3? If the intention was for GTK3 and newer to only be used to write GNOME applications, then fine, but it seems as though GTK3/4 are still being presented as general purpose UI toolkits. I'm just asking for honesty regarding the policy layer.

Apparently the removal of icons from menus is not a universal trend in UI design as the Qt apps I use still have them.

As a user of several amateur radio applications packaged by Debian, I am a bit concerned for the future. The main logging program I use, CQRlog, is GTK2 based and I don't see any indication that upstream is going to change. An open bug on the CQRlog GitHub issue tracker has been present since mid 2019 with no comment.

In an ideal world GTK3 would be forked and restored to being a general purpose toolkit by reverting GNOME policy decisions that have been pushed into the toolkit. Of course, I'm unable to do anything of the sort primarily due to limitations of skill and experience.

to post comments

GNOME policy pushed into GTK3 and newer

Posted Jan 25, 2026 22:38 UTC (Sun) by pizza (subscriber, #46) [Link]

> Some years back I took over maintenance of a favorite niche application (amateur radio). It is a C program written against GTK2. Its UI is relatively simple, mainly one screen with a handful of popup windows. I naively set about porting it to GTK3 and learned a number of things.

I'm in a similar boat; I've effectively inherited a GIMP 2.x plugin that relies on a pile of custom GTK2 widgets.

Unfortunately it can't be built against GIMP 3.x without first rewriting its entire UI library to use GTK3, which is far more work than I can justify. And that's _before_ the other GIMP2->GIMP3 porting can meaningfully begin.

> If the intention was for GTK3 and newer to only be used to write GNOME applications, then fine, but it seems as though GTK3/4 are still being presented as general purpose UI toolkits. I'm just asking for honesty regarding the policy layer.

GNOME has pushed more and more GNOME-specific stuff (ie widgets implementing specific policies and the GNOME vision) into separate libraries. Which get them even more hate mail.

> In an ideal world GTK3 would be forked and restored to being a general purpose toolkit

At the end of the day, GTK (like most F/OSS) is a do-ocracy, so it's no surprise that the work that GNOME puts into it reflects GNOME's priorities. (FWIW, I remember similar complaints were made about GTK 2.0 versus GTK 1.2)

...Ironically, each major release of GTK is more agnostic wrt the underlying platform (not just GNOME but also the OS itself) than its predecessor. It's perfectly possible to recreate a GNOME2-era UI with GTK3/4, but someone has to do that work... and that someone does not exist in this very-non-ideal world.

GNOME policy pushed into GTK3 and newer

Posted Jan 25, 2026 23:03 UTC (Sun) by mbunkus (subscriber, #87248) [Link] (4 responses)

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.

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!