Maybe a hint?

Posted Jan 14, 2026 20:54 UTC (Wed) by tux3 (subscriber, #101245)
In reply to: Maybe a hint? by mussell
Parent article: Debian discusses removing GTK 2 for forky

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.)

to post comments

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.