Decide how to support qt6/gtk4 #19226
Comments
|
It would be great to just have one backend. But is there going to be call to use non compatible features of qt6? Is assume it is different in some ways ;-). |
|
In practice, we just added a few checks in backend_qt5.py to support both qt4 and qt5 (you can grep for |
|
GTK4 is a major release bump for a reason; there are many many changes involved. However, I don't know how much of that will translate into Python due to duck typing in PyGObject. How will this work out for embedding? |
|
I guess we just need to wait for a pygobject release with gtk4 support to know... |
|
Please, could you just implement Qt6Agg for now? Because on BigSur (MacOS11.x) only PySide6 works correctly. |
Perhaps you could try #19255? |
I think you might want to try #19334. |
|
Done. |
|
matplotlib.use Still not recognize PyQt6 on macOS? interactive backends: GTK3Agg, GTK3Cairo, GTK4Agg, GTK4Cairo, MacOSX, nbAgg, QtAgg, QtCairo, TkAgg, TkCairo, WebAgg, WX, WXAgg, WXCairo, Qt5Agg, Qt5Cairo |
|
Both Qt6 and Qt5 are supported by |
Thanks for the clarification, it seems DataSpell's patch caused this issue. When I tried to use this QtAgg in Dataspell using the interactive shell. It got an error. But it does not get error directly running iPython in commend line. Error when running in DataSpell shell Python 3.9.18 (main, Aug 24 2023, 21:19:58) |
|
Yes, it appears that the error is not coming from Matplotlib, but this |
Both qt6 and gtk4 have been recently released. qt6 already has a working python binding in pyside6; i guess both qt6 and a gtk4-supporting pygobject should be available "soon". (For qt6 I first raised the issue #16836 but that issue ended up being mostly about qt4.)
It turns out to be very easy to support pyside6 -- it's just a couple of import renames and certain things having moved out of the Qt namespace -- and I basically already have a patch for that. The main question, however, is whether we want to put that support in a "qt6agg" (and "qt6cairo") backend, or if we decide to move towards having a single "qtagg" (and "qtcairo") backend and fully move qt binding selection to 1) checking if anything is already imported in the process and 2) the QT_API environment variable.
Even as of today, if one selects the qt5agg backend but already has PyQt4 imported in the process, we'll silently switch to qt4agg for you (well, modulo the deprecation warning for qt4 support), so we already treat the two backends as somewhat interchangeable. Although I guess one of the reasons for doing so was that it was not possible to import both PyQt4 and PyQt5 into the same process at all (the second import would fail); I don't know if that's also going to be the case for qt6...
I'd say it makes sense to just have a single qtagg backend instead. The alternate solution of having both qt5agg and qt6agg would probably involve copy-pasting all of backend_qt5agg.py into backend_qt6agg.py, and then replacing backend_qt5agg.py by a small stub similar to the current backend_qt4agg.py, which is a bit... ugh.
The same question basically exists for gtk3/gtk4, although perhaps we can wait for a pygobject release that supports gtk4 to make sure it'll indeed make sense to go back to a single gtkagg. There we'd need to introduce a new GTK_API environment variable though? Also, there's the additional question of whether that'll confuse people using fairly old docs/versions and confusing that with the old gtkagg (=gtk2) backend, which was removed in matplotlib 2.0... (also, note that a non-numbered qtagg backend also existed back in the times of qt3(!) support (which was removed in matplotlib 1.3).)
TL;DR: 1) perhaps wait for PyQt6 and "pygobject4" before deciding on what to do with PySide6; 2) perhaps move to a single backend_qtagg and a single backend_gtkagg instead of splitting by version?
The text was updated successfully, but these errors were encountered: