Skip to content

Fix PythonQtPlugin broken during new module update 2

Arnaud Billon requested to merge LidarView/paraview:FixPythonQtPlugin into master

This is the continuation of !3649 (closed).

Summary of the additional modifications:

  • In non QT_NO_KEYWORDS builds, we get conflict with Qt5 keywords and vtkpython (e.g PyType_Slot *slots;). As explained in the commit message, we cannot enforce QT_NO_KEYWORDS, so this has to be sovled locally with pragmas.

  • PythonQt_QtAll is built be default, but this is not desired as build will fail if we did not buildBuild every Qt5 modules and enable all features (and do not wish to wrap them all), therefore I made it optional based on PythonQt_QtAll library availability with a warning.

Additionally, without calling PythonQt_init_QtBindings(), non PythonQt_QtAll builds will only have the built-in modules (a subset of QtCore/QtGui apparently), this is a regression with the old behavior that allowed to build a custom libPythonQt.so with only the modules we need. (See https://gitlab.kitware.com/paraview/paraview/-/blob/v5.6.0/Plugins/PythonQtPlugin/pqPythonQtPlugin.cxx#L80).

That being said : calling PythonQt_init_QtBindings() seems to have exactly the same behavior as PythonQt_QtAll::init() without the need to include PythonQt_QtAll.h that may not be available if PythonQt_QtAll is not built.

Here is an example of the setup within LidarView to better understand why a custom linking can be important for some user: The CMake-ified PythonQt from commontk/PythonQt does not build the PythonQt_QtAll library and only does a selective linking as explained above. Moreover, we do not ship OpenSSL, in this case trying to build the plugin with the Qt5::Networking will fail as functions will be missing for the wrapping.

As for the testing, provided samples are working, I am also doing more tests with LidarView, that uses PythonQt extensively.

Edited by Arnaud Billon

Merge request reports