Skip to content

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

Merged
merged 11 commits into from
Aug 5, 2021
Merged

Support for PyQt6/PySide6. #19255

merged 11 commits into from
Aug 5, 2021

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Jan 7, 2021

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

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (run flake8 on changed files to check).
  • New features are documented, with examples if plot related.
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

@anntzer
Copy link
Contributor Author

anntzer commented Jan 21, 2021

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 anntzer force-pushed the qt6 branch 9 times, most recently from e04add6 to e888368 Compare January 24, 2021 19:02
@anntzer anntzer changed the title Add "experimental" support for PyQt6/PySide6. Support for PyQt6/PySide6. Jan 24, 2021
@anntzer
Copy link
Contributor Author

anntzer commented Jan 24, 2021

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 :(

@anntzer anntzer marked this pull request as ready for review January 24, 2021 19:06
@joaorsbarbosa
Copy link

joaorsbarbosa commented Aug 4, 2021

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 lib/matplotlib/backends/backend_qt5.py and lib/matplotlib/backends/qt_editor/_formlayout.py.
Update 2: OK, this is of course only before applying the first commit.

Newbie here.
Just started a project using matplotlib (3.4.2) and PyQt6. However, I'm having trouble getting it to work. I cant select PyQt6 "backend". I can "cheat" by selecting PyQt5 in some sections of my code, but it's a mess and it's not working.
I'm guessing that the support for PyQt6 has yet to be rolled out?
My apologies if this is the wrong place to ask such question. I'm still learning all this!! 😅
EDIT: If PyQt6 support is being worked on at the moment, the right thing to do is wait a bit and develop my project using the newest version of PyQt, instead of using PyQt5 right? Or no? Thanks in advance!

@tacaswell
Copy link
Member

I'm working on this right now, this should be in mpl 3.5.

anntzer and others added 9 commits August 4, 2021 16:54
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.
@cbrnr
Copy link
Contributor

cbrnr commented Aug 5, 2021

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.

@QuLogic
Copy link
Member

QuLogic commented Aug 5, 2021

@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.
@tacaswell tacaswell mentioned this pull request Aug 5, 2021
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants