It is always better to use mainstream libraries (people are more familiar with it, easier to find help, less likely to die off, etc.) and “Qt for Python” is a clear winner. In the long term we would like to be able to distribute Slicer components as individually loadable Python packages (starting with vtkAddon, MRML, etc.) and using “Qt for Python” for GUI would be aligned with this goal.
My concerns are the followings:
In “Qt for Python” examples the application is always Python.exe, and the QApplication object is always created in Python and executed in Python:
It would be great if somebody could try if Qt for Python can be used in an application that embeds Python (not in Python.exe), so that we can keep complete ownership of how the application is created/destroyed, how threads and message queue is handled, etc.
Qt version. We would lose control of what Qt version is used and how Qt is built.
Porting the Python/Qt infrastructure and all Python scripts to “Qt for Python” would be a very significant effort.
Yes, I’ve been keeping an eye on this too, and certainly there are a lot of advantages in using the mainstream libraries. There are good reasons why we have the current system, but they are always worth revisiting if/when circumstances evolve.
To Andras’s points:
There’s no reason we couldn’t create a QSlicerApplication from python.
We could still choose to build and distribute any specific versions we wanted, but aiming for compatibility with the standard installations would have a lot of benefit.
Yes, lots of work! But most would be pretty routine and would result in a cleaner and more maintainable system.