VTK 9 + PyQt Application

We are thinking about rewriting an existing C++ application to include 3D/2D visualization capabilities and we were thinking about using VTK 9 to do it. We are also possibly wanting to move over to python as the main language of the application. We were thinking about PyQt with QML as the UI framework since we have experience with QWidgets already. My question is this:

Has anybody gone down this road already and what was your experience like? Were there any major road blocks that were encountered? Any subtle issues that crept up that were hard to work around? Were there any limitations of using this combination?


This could be a good approach overall, but there are several non-trivial decisions to make.

Qt: Qt Company has been very capricious recently, essentially working against its users by restricting access to pre-built binaries and source code. If you need Qt not just as a GUI toolkit but also as operating system abstraction for C++ then there are not really any good alternatives. If you only need a GUI toolkit and use Python as OS abstraction then you might want look around if you find something that has enough capabilities and has a more trustworthy leadership than the current Qt Company.

QML or classic widgets: Classic widgets are guaranteed to work, because both major projects that use VTK with Qt (Paraview and 3D Slicer) use those. However, Qt essentially stopped development of classic widgets years ago and they just do minimal bugfixes, if even that. You can customize classic widgets with stylesheets to get modern look and feel, but it is easier to create custom GUIs (that does not resemble native controls) using QML. However, I’m not sure how many projects use VTK with Qt QML - you may need to invest time into making the VTK renderer work in QML and plan extra time for testing and development at each Qt or VTK release.

Embedding Python or extending Python: You need to decide if you want your application to be a Qt application or Python.exe. By embedding Python you retain control over your application (including building, packaging, distributing, and tricky parts, such as application initialization, multithreading, etc.). It also allows making Python an optional dependency (you can enable/disable Python support by a flip of a CMake switch). However, it means that your application cannot be pip-installed, you need to take custom solutions from Paraview or Slicer to set up debugging, jupyter kernels, etc. and there are a very few low-level packages, such as async, which may not work well in a Qt application.

PySide vs PythonQt: By far the most widely used Python wrapping of Qt is PySide (provided by Qt company), which is important because all examples that you find on StackOverflow are for this. However, I’m not sure if it works if Python is embedded. Also, it does not wrap your own custom Qt classes, so you need to take care about that yourself. For embedded Python, you can use PythonQt, which is a small, lightweight library that uses a smart way to wrap Qt and all your custom Qt classes, without the need for any manual interface definition. You can build it yourself, so you are not dependent on pre-built binaries from Qt company (that are increasingly getting more problematic).

Dear Andras,

Thank you for the feedback. Our current application is a cross platform Qt5 application. We have been developing it for the last 10 years as a C++ QWidgets application so we are living through the Qt Company’s current shenanigans. We were thinking of using PyQt from Anaconda as the base “SDK” for our developers which would make the project a python.exe. We can leave certain parts of the application (which were originally plugins anyways) as compiled code for the time being and for speed as the application is a data analysis application. The thought was to try to get PyQt + VTK + QML all working. I understand that there are issues with VTK9 + QML which we have a plan for and if it works out, would be released into opensource or as a part of VTK if the VTK team wants those bits. All of our dependencies are taken care of through Anaconda (Qt5, HDF5, Eigen, Mkdocs).

Relying on Anaconda is a huge dependency but I can see that it can make sense for certain applications. It certainly takes off some workload of building dependencies, but introduces a lot of other issues. The main problem is that the process of building your dependencies becomes opaque and out of your control. For example, you cannot dictate what build options Anaconda uses when it builds your various dependencies (what OS platform target is chosen, or hardware support is chosen, what optional components are enabled, etc.) and you cannot quickly apply patches in dependencies. For example, you want to use virtual reality in VTK, but if VTK was not built with that option enabled then you will need to build your own VTK or give up on virtual reality in your application. Self-contained packaging and distribution becomes more complicated too. Also, not everyone is fond of Anaconda, and in some environments you are simply not allowed to pull in many gigabytes of precompiled binaries from a hard-to-verify source.

Using CMake ExternalProject infrastructure, building all your dependencies along with your application is quite manageable - see Paraview and 3D Slicer. If you go as far as building your application as a custom application based on Slicer or Paraview then you get all the dependency builds and platform maintenance on Windows/Linux/Mac for free.

Just jumping in to correct here: PyQt is provided by Riverbank Computing. The Qt Company provides PySide2.

Yes, sorry I meant PySide (PyQt is commercial/GPL). I’ll update my post above if I still can.

Hi Michael,
We are in a similar position with existing VTK applications for 3D image processing and looking at the UI framework. In particular we want to add charting and database query functionality (forms etc…)
Have you looked at Activiz .NET?

I understand that a .NET 5 version not too far away. So cross platform C#

For our application we require multi-user 3D visualization.
So we will rewrite the UI as a separate visualization client application with ActiViz in a .NET 5 application. The image processing code remains unchanged.


Since Qt’s future is somewhat uncertain, it could be interesting to explore .net as application framework. Is ActiViz free and open-source? How well .net applications work on non-Windows platforms nowadays? Do the applications have native look&feel? Does packaging, installation, publishing in app stores work well? Can you use .net from Python?

ActiViz is not free but the cost includes support and is modest in commercial terms.
The issue with many third party libraries is the annual licensing model. For example, in order to support a Qt application when all development is complete you still need to continue paying annual license fees even if no issues occurred.

Better to refer you questions on .NET 5 to a .NET 5 developer.

One of the reasons for out path is that ,at least in Australia, there are many more .NET developers.
In fact it is difficult for us to find any local experienced Qt developers.

I fully agree that annual licensing models are highly problematic, especially when they come at the outrageous price as Qt’s commercial license ($3950 per year for each developer). Fortunately, Qt is available with completely free license, too (the only problem is that Qt Company is trying to find loopholes to make free usage practically impossible without violating its obligation of keeping Qt free and open-source forever).

The main problem is that even a one-time fee of $10 for each developer (or even a requirement for a free registration) is a major inconvenience, because you cannot set up automatic builds, redistribute SDKs, etc. without potential legal consequences or workarounds that introduce significant complexity.

It is of course beneficial for everyone if maintainers are sufficiently funded, but forcing users to pay up is not acceptable for many projects. Maybe Wikipedia-like fundraising or a premium membership model (same software product for everyone but improved support for paying users, such as tokens for voting on which bugs to fix or features to develop) would be more widely acceptable.

I agree, it is hard to find C++ developers nowadays. We are a university research lab and 10 years ago students typically graduated with a mix of C, Matlab, and C++ or Java experience. They can now do everything in Python, which is pretty awesome, but a side effect is that they are much less comfortable with using C/C++.

However, choice of programming language is not tightly linked to GUI toolkit. A good GUI toolkit can be used from many programming languages. For example, Qt is not only for C++ but can be used in Python, Java, C#, etc. (of course not all of them are equally well supported).

It is hard to make any decision now about what GUI toolkit to use for multi-platform desktop application development. It will be much more clear in 1-2 years, because by then we’ll see if Qt Company will reverse its recent decisions, Qt will be forked, or Qt users will migrate to some alternatives. Also, users nowadays demand to run everything in their web browser (and although I find this unreasonable, I cannot change mind of so many people), so it would be nice to find a solution that can somehow address this need as well.

Very interesting discussion about licensing models and choice of programming language and GUI toolkit. Thanks!

I confirm NET 5/NET 6 is now stable enough for cross-platform C# to be considered. We started using Avalonia UI in Activiz, and will look into .NET MAUI soon.