Maybe a hint?

Posted Jan 15, 2026 12:32 UTC (Thu) by swilmet (subscriber, #98424)
In reply to: Maybe a hint? by mb
Parent article: Debian discusses removing GTK 2 for forky

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

to post comments

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.