Qt for Python - Thoughts?

Development
1

Does anyone have opinions about Qt for Python for the Qt python bindings? I received a promotional email about it recently and briefly looked into it. It would I guess replace PythonQt.

Some background is available at https://wiki.qt.io/Qt_for_Python:

  • Properly supported by the Qt Company
  • The name of the project is Qt for Python and the name of the module is PySide2 .
  • The module was released mid June 2018 as a Technical Preview (supporting Qt 5.11), and it was officially released without the Technical Preview tag, in December 2018 for Qt 5.12.

Licensing: Qt for Python is available under LGPLv3 https://doc.qt.io/qtforpython/licenses.html

Qt for Python Getting Started with platform specific details and about building from source if not wanting to use Pyside 2 wheels from pypi (https://pypi.org/project/PySide2/#history).

1 Like
2

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:

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

  1. Qt version. We would lose control of what Qt version is used and how Qt is built.

  2. Porting the Python/Qt infrastructure and all Python scripts to “Qt for Python” would be a very significant effort.

3

Step by step we will get there. This will also streamline continuous integration.

4

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:

  1. There’s no reason we couldn’t create a QSlicerApplication from python.

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

  3. Yes, lots of work! But most would be pretty routine and would result in a cleaner and more maintainable system.

1 Like
5

It may also be worth investigating:

  • support for wrapping your own classes
  • integration with VTK objects (e.g slot or wrapped function accepting vtk objects)