Closed GuillaumeFavelier closed 2 years ago
An alternative would be to define our own version as it is done for example in mayavi
This might not be a bad idea, especially since Mayavi's version differs from VTK's (I think it's newer), and VTK's version is referred to as "contributed code" and not really supported:
It would be great if we could at least fix these macOS bugs, and then preferably contribute them back to VTK (if they'll accept them).
To me Qt6 would be a secondary priority, because it looks like Qt6 support was added only 6 months ago, so probably isn't in VTK6:
https://discourse.vtk.org/t/how-to-get-vtk9-qt6-working-together/4927
I assume we need to wait for VTK9.1 or 10 to be released (no idea what the timelines are), I would look into that and also into the Qt6 thread above (and any other ones you might find) to see what their state of support is actually like.
VTK's version is referred to as "contributed code" and not really supported
Indeed, from (VTK's developper) David Gobbi:
This issue is with regards to vtkmodules/qt/QVTKRenderWindowInteractor.py, which is a community-contributed class (this class does not make use of the GUISupportQt C++ module). As far as I know, none of the core VTK teams use this class. [...] I honestly doubt that any of the VTK developers have time to maintain this class.
I was not aware of this, many thanks for the additional informations.
Mayavi's version differs from VTK's (I think it's newer)
It's definitely worth taking a look if we seriously consider maintaining our own :+1:
I assume we need to wait for VTK9.1 or 10 to be released
I'm interested in working on a PR for this but not until the situation is settled for qtpy
.
Another package to consider is ipython
. In my experiments, I ran into:
from IPython.external.qt_for_kernel import QtGui
../anaconda3/envs/mne-py39/lib/python3.9/site-packages/IPython/external/qt_for_kernel.py:94: in <module>
api_opts = get_options()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
def get_options():
"""Return a list of acceptable QT APIs, in decreasing order of
preference
"""
#already imported Qt somewhere. Use that
loaded = loaded_api()
if loaded is not None:
return [loaded]
mpl = sys.modules.get('matplotlib', None)
if mpl is not None and not check_version(mpl.__version__, '1.0.2'):
#1.0.1 only supports PyQt4 v1
return [QT_API_PYQT_DEFAULT]
qt_api = os.environ.get('QT_API', None)
if qt_api is None:
#no ETS variable. Ask mpl, then use default fallback path
return matplotlib_options(mpl) or [QT_API_PYQT_DEFAULT, QT_API_PYSIDE,
QT_API_PYQT5, QT_API_PYSIDE2]
elif qt_api not in _qt_apis:
> raise RuntimeError("Invalid Qt API %r, valid values are: %r" %
(qt_api, ', '.join(_qt_apis)))
E RuntimeError: Invalid Qt API 'pyside6', valid values are: 'pyside, pyside2, pyqt, pyqt5, pyqtv1, pyqtdefault'
Quick update: the issue with ipython
is solved in 7.27
PySide6
andPyQt6
have been released and now work is ongoing onpytest-qt
(actually4.0.0
is just around the corner) andqtpy
to catch up.Now it seems the main blocker for
pyvistaqt
comes fromvtk
because theQVTKRenderWindowInteractor
does not support these new implementations. Fromvtk/master
:An alternative would be to define our own version as it is done for example in
mayavi
Related to https://github.com/pyvista/pyvistaqt/issues/58