Maybe a hint?

Posted Jan 14, 2026 17:00 UTC (Wed) by smoogen (subscriber, #97)
In reply to: Maybe a hint? by wtarreau
Parent article: Debian discusses removing GTK 2 for forky

It always seems to me that it takes a lot longer to port most gtk apps than it does with qt applications. I don't know why and don't know if there has been any sort of serious study of that.

to post comments

Maybe a hint?

Posted Jan 14, 2026 19:11 UTC (Wed) by mussell (subscriber, #170320) [Link] (8 responses)

Distros don't package old versions of Qt since it's too tightly interconnected, so any Qt application needs to either use the latest Qt or risk being removed from distros. The Gtk/GObject system is less tightly connected and more orthogonal, Gtk 2 can be built against a recent glib for example. That's why distros are/were still continuing to package Gtk 2 for the last 20 or so years, but only one of the four major releases of Qt released in that same time span, and if the distros are/were still going to package Gtk 2, then there's no pressure for applications to switch.

Gtk 2 applications are now just getting the same treatment as Qt applications, upgrade or Debian won't package you.

Maybe a hint?

Posted Jan 14, 2026 20:25 UTC (Wed) by AdamW (subscriber, #48457) [Link]

"Distros don't package old versions of Qt since it's too tightly interconnected"

Sure we do. Fedora still has Qt 5.

Maybe a hint?

Posted Jan 14, 2026 20:54 UTC (Wed) by tux3 (subscriber, #101245) [Link] (5 responses)

It's probably also the sheer amount of stuff in Qt/KDE. I wouldn't be surprised if there's an order of magnitude more code in the Qt/KDE frameworks than in GTK (counting the libraries, not the respective desktop environments). Shipping old libraries is all fine as long as upstream is active or when it's only a small maintenance burden.

On the other hand, Qt upgrades have been relatively painless in my experience. They don't tend to make major redesigns that force you to significantly change your UI or rewrite parts of your app. QML/Qt Quick is 15 years old and that's what they recommend for new projects. But you can still port and build your old QtWidgets app with new frameworks, that's also fine.

If Debian only ships Qt5 and Qt6, it's not like applications should really feel trapped on Qt4. The migration is tedious, but for most apps it's mostly mechanical work. It doesn't that all that much pressure in the first place.
Of course if you look at complex projects like GIMP or Krita the migration will be much more difficult. But even in more complex applications, the trend seems to be borne out. (I expect Krita on Qt6 long before GIMP on GTK4, despite both toolkits releasing in the same month.)

Maybe a hint?

Posted Jan 14, 2026 21:48 UTC (Wed) by mb (subscriber, #50428) [Link] (3 responses)

>but for most apps it's mostly mechanical work

It's an absolute horror for any Python based Qt5 application.

Maybe a hint?

Posted Jan 15, 2026 12:32 UTC (Thu) by swilmet (subscriber, #98424) [Link] (2 responses)

It's because of Python being an interpreted language, it's not Qt's fault.

Maybe a hint?

Posted Jan 15, 2026 15:56 UTC (Thu) by mb (subscriber, #50428) [Link] (1 responses)

Well, I was neither talking about whose "fault" this was, nor am I interested in determining this.

But Qt massively changed the API (mainly all enums) and Python did change nothing.

It's a fact that porting Qt5 Python apps to Qt6 is so hard to the point where I seriously consider not doing it and deprecating or rewriting the applications instead (or leave it to somebody else).
It's far from being just "mechanical work".

Maybe a hint?

Posted Jan 15, 2026 21:11 UTC (Thu) by swilmet (subscriber, #98424) [Link]

In that case a good suggestion that I have, but that is not always applicable (it depends on the architecture of the app), is to first port the "leaves" classes and utility functions (and test those independently of the whole app). "Leaves" as in depending on nothing else from the same project.

Then walk up the "tree" (it's actually a DAG, or almost a DAG) of dependencies to gradually port the project, piece by piece, with tests (either unit tests or interactive tests as mini apps). Until the main function which is the top of the DAG.

But not all projects have this kind of architecture. If a class towards the leaves depends on a class towards the top, you're out of luck (it can lead to a spaghetti architecture, in that case).

BTW GTK has those wonderful functions such as gtk_widget_get_parent() (returns the container) and g_application_get_default() (returns the singleton object containing the whole app). These must be used with great care, because it can easily lead to a spaghetti architecture (it's just a downcast away from being able to access every other class of the app). So some discipline is needed.

Maybe a hint?

Posted Jan 15, 2026 9:30 UTC (Thu) by taladar (subscriber, #68407) [Link]

Qt4 to Qt5 basically abandoned widgets (which are still there but basically unmaintained in Qt5) in favor of QML.

Maybe a hint?

Posted Jan 14, 2026 21:02 UTC (Wed) by plugwash (subscriber, #29694) [Link]

> Distros don't package old versions of Qt since it's too tightly interconnected

I can't speak for other distros, but Debian has packaged multiple versions of QT for most of the last decade.

* 2013 - QT5 added.
* 2020 - QT4 removed.
* 2022 - QT6 added

Maybe a hint?

Posted Jan 14, 2026 19:19 UTC (Wed) by ebee_matteo (guest, #165284) [Link] (15 responses)

Qt+ has a large commercial backing, e.g. mobile, automotive, embedded, etc.

These are paying customers that do not want to see backwards incompatibilities unless strictly necessary.

Gtk+ is community led. It has some backing from one big "customer" (IBM), but apart from it, it doesn't have the same constraints.

Maybe a hint?

Posted Jan 14, 2026 21:07 UTC (Wed) by pizza (subscriber, #46) [Link]

> Gtk+ is community led. It has some backing from one big "customer" (IBM), but apart from it, it doesn't have the same constraints.

In this context, "resources" would be a better word to use than "constraints".

At any point over the past 20 or so years, I'd bet there were about two orders of magnitude of folks being paid to work on Qt than on GTK. Heck, Qt alone probably had more developers than the entire GTK ecosystem (ie GNOME + applications) put together.

(FWIW, I've found Qt quite pleasant to use, and I say that as someone who generally loathes C++)

Maybe a hint?

Posted Jan 17, 2026 1:21 UTC (Sat) by mirabilos (subscriber, #84359) [Link] (13 responses)

It’s GNOME-led, not really community.

Maybe a hint?

Posted Jan 17, 2026 2:53 UTC (Sat) by pizza (subscriber, #46) [Link] (12 responses)

> It’s GNOME-led, not really community.

So what else do you call "a loose collection of mostly volunteers working together to create something"?

Maybe a hint?

Posted Jan 17, 2026 13:12 UTC (Sat) by Wol (subscriber, #4433) [Link] (11 responses)

"Community led" implies a GTK+ community, doing what's best for GTK.

If it's the Gnome community doing what's best for Gnome (as appears to be the case), then I wouldn't call GTK+ a community-led project.

Don't forget, the G in GTK stands for Gimp, not Gnome, so we already have a project that's had its founders left behind in a hi-jack ...

(Don't get me wrong, that's the way FLOSS works and it's good, but GTK probably isn't even an independent project!)

Cheers,
Wol

Maybe a hint?

Posted Jan 17, 2026 13:20 UTC (Sat) by pizza (subscriber, #46) [Link] (10 responses)

> "Community led" implies a GTK+ community, doing what's best for GTK.
> If it's the Gnome community doing what's best for Gnome (as appears to be the case), then I wouldn't call GTK+ a community-led project.

So GTK isn't a "community project" because it's being run by... a different community?

Come on.

Maybe a hint?

Posted Jan 17, 2026 18:47 UTC (Sat) by Wol (subscriber, #4433) [Link]

No. It's not "community led" because it's not being led by a team doing what's best for GTK.

It's like saying a village is in charge of its own destiny, because it votes a councillor onto the local Rural District Council.

Simply put, is your own destiny in your own hands. As far as GTK is concerned, it isn't. The people working on it do what's best for Gnome.

Cheers,
Wol

Maybe a hint?

Posted Jan 17, 2026 19:21 UTC (Sat) by Wol (subscriber, #4433) [Link] (8 responses)

Re-reading your comment, I think it's better to say "GTK isn't community-led because there isn't a GTK community".

Cheers,
Wol

Maybe a hint?

Posted Jan 17, 2026 19:50 UTC (Sat) by pizza (subscriber, #46) [Link] (7 responses)

> Re-reading your comment, I think it's better to say "GTK isn't community-led because there isn't a GTK community".

That's better, but still succumbs to the No True Scotsman fallacy.

What is "the gtk community" if not the folks that actually develop and use it? Should GNOME not take an interest in its upstreams?

GTK,is a "community project" as opposed to a "commercial/corporate project" ala QT. Or a "personal project", for that matter. The fact that GTK development has been being driven mostly by GNOME (which is itself another "community project") doesn't invalidate that basic fact.w\

Maybe a hint?

Posted Jan 17, 2026 20:33 UTC (Sat) by Wol (subscriber, #4433) [Link] (6 responses)

> Should GNOME not take an interest in its upstreams?

IS GTK a Gnome upstream? Or is it just a Gnome component?

It started out as a Gimp component. Then it got taken over as a Gnome component (as evidenced by the fact that Gimp stayed on "legacy" GTK long after GTK had moved on with Gnome). Has it now struck out on its own?

Cheers,
Wol

Maybe a hint?

Posted Jan 18, 2026 13:24 UTC (Sun) by pizza (subscriber, #46) [Link] (5 responses)

> IS GTK a Gnome upstream? Or is it just a Gnome component?

That's a distinction without a difference, as GTK is indisputably maintained by "its community"

Maybe a hint?

Posted Jan 18, 2026 19:19 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (4 responses)

It very much is NOT maintained by the Gtk+ community, it’s maintained by GNOME, who have hostile-taken-over Gtk+.

Maybe a hint?

Posted Jan 18, 2026 19:36 UTC (Sun) by Wol (subscriber, #4433) [Link]

> who have hostile-taken-over Gtk+.

I think you mean they've forked it (which is perfectly okay). But yes, they have also hijacked the name, which is less okay ...

Cheers,
Wol

Maybe a hint?

Posted Jan 18, 2026 22:28 UTC (Sun) by pizza (subscriber, #46) [Link] (2 responses)

> It very much is NOT maintained by the Gtk+ community, it’s maintained by GNOME, who have hostile-taken-over Gtk+.

Please, provide *any* citation that GTK was subject to a hostile takeover -- ie against the wishes of the folks that were nominally in charge and maintaining it at the time. Even if what you say is true, and GTK was hostile-forked 2.5 decades ago (because that's the timeframe we're talking about here) what effing difference does it make in practical terms, when the alternative is... being effectively (if not actually) unmaintained? (Let's not pretend that GIMP has been swimming in developers all these years)

Because all you're doing is maligning the folks that have been maintaining one of the most commonly used (*nix) UI toolkits, for reasons that appear to be nothing more than "everything GNOME does is automatically doubleplus BAD".

Maybe a hint?

Posted Jan 18, 2026 22:44 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (1 responses)

Lack of active maintenance is neither an indicator of obsolescence nor a reason to do a hostile takeover.

Maybe a hint?

Posted Jan 19, 2026 0:12 UTC (Mon) by pizza (subscriber, #46) [Link]

Again, I repeat myself:

Please, provide *any* citation that GTK was subject to a hostile takeover.