Fix PythonQtPlugin broken during new module update 2
This is the continuation of !3649 (closed).
Summary of the additional modifications:
-
In non
QT_NO_KEYWORDS
builds, we get conflict with Qt5 keywords andvtkpython
(e.gPyType_Slot *slots;
). As explained in the commit message, we cannot enforceQT_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 onPythonQt_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.