Support for PyQt6/PySide6. #19255
Support for PyQt6/PySide6. #19255
Conversation
anntzer
force-pushed the
anntzer:qt6
branch
2 times, most recently
from
46dbac2
to
ca3b175
anntzer
force-pushed the
anntzer:qt6
branch
3 times, most recently
from
25f5c9a
to
f61c7d4
anntzer
force-pushed the
anntzer:qt6
branch
2 times, most recently
from
87c7795
to
237d660
|
Agreement was to switch to qtagg/qtcairo without version numbers (keeping qt5foo as aliases for backcompat). Will try to make it by next week to get it in 3.4 (but that's not urgent either). (GTK will be handled separately, may require a fully separate backend.) |
anntzer
force-pushed the
anntzer:qt6
branch
9 times, most recently
from
e04add6
to
e888368
anntzer
changed the title
|
This should be working now (although I'm not sure about how much needs to be done on IPython's side). Edit: hmm, CI is crashing but it's hard to see why :( |
|
Any progress on this? We have it listed as "High Priority" for 3.5... |
|
I've just tested this PR with the PySide6 backend in my application, and everything seems to work just fine! I'd be happy to help get this PR merged, please let me know what I can do. Maybe someone can summarize the remaining open issues (which seem to be related to the test suite)? Update: Merge conflicts don't seem to be too crazy, in contrast to what is listed below I only get conflicts in |
Newbie here. |
|
I'm working on this right now, this should be in mpl 3.5. |
Currently these must be selected via `QT_API=pyqt6`/`QT_API=pyside6`. Note that I didn't create a separate backend_qt6agg (and backend_qt6cairo, and mplcairo.qt6...) as it seems preferable to instead move towards a single backend_qtagg and allow selection of the actual qt binding via the orthogonal QT_API mechanism. Most of the work is just handling attributes that moved out of the Qt namespace.
Testing all qt bindings actually caught the fact that PySide makes the backend not thread-safe. Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
Also, PyGObjects built on different Ubuntus are incompatible, so the cache should be keyed by matrix.os (which includes the version number), not runner.os (which doesn't).
We do not exercise all of the code paths that call _enum in the tests. At least PyQt5 5.8 does not support the enums by name so we still need the version gating.
Perfer to run with Qt6 if available
Just run with what ever version of PyQt we find.
Used to be parameterized, now just marked. There is no backend fixture.
|
Thanks @tacaswell, that's really great! Do you have an estimate when 3.5 will be available? Edit: The milestone is due August 18, so I guess that's the plan. |
|
@tacaswell: @anntzer's comment still needs fixing. |
If pyqt4 is imported the code just above will catch the problem and if pyqt4 is not imported we can rely on `plt.switch_backend` to handle the fallback between pyqt/pyside versions.
QuLogic
merged commit c34fa77
into
matplotlib:master
Currently these must be selected via
QT_API=pyqt6/QT_API=pyside6.Note that I didn't create a separate backend_qt6agg (and
backend_qt6cairo, and mplcairo.qt6...) as it seems preferable to instead
move towards a single backend_qtagg and allow selection of the actual qt
binding via the orthogonal QT_API mechanism.
Most of the work is just handling attributes that moved out of the Qt
namespace (but the new locations are also compatible with Qt5).
See https://www.riverbankcomputing.com/static/Docs/PyQt5/gotchas.html#enums
re: enum renames (sip 4.19.9 corresponds to PyQt5.13.1).
Just for those who want to play with this wrt #19226...
PR Summary
PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).