-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Support for PyQt6/PySide6. #19255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for PyQt6/PySide6. #19255
Conversation
46dbac2
to
ca3b175
Compare
25f5c9a
to
f61c7d4
Compare
87c7795
to
237d660
Compare
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.) |
e04add6
to
e888368
Compare
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 :( |
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.
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
pytest
passes).flake8
on changed files to check).flake8-docstrings
and 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).