Repository navigation
consider using qtpy for qt abstraction layer #6118
Description
Instead of rolling our own, use https://github.com/spyder-ide/qtpy
The proposal would be to replace our qt_compat.py almost wholesale with qtpy imports.
| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Instead of rolling our own, use https://github.com/spyder-ide/qtpy
The proposal would be to replace our qt_compat.py almost wholesale with qtpy imports.
| Back | FazBrowse Home | New Git URL |
Activity
jenshnielsen commented on Mar 7, 2016
Sounds like a very good idea to me
mdboom commented on Mar 7, 2016
Yes. Spyder's needs of Qt are much more complex than ours, so I suspect it should do everything we need it to do.
tacaswell commented on May 8, 2017
spyder-ide/qtpy#84 <- they now support pyside2 so are back to wrapping parity.
anntzer commented on Dec 13, 2017
See #9993 (comment) for arguments against it.
anntzer commented on Jan 30, 2018
I think spyder-ide/qtpy#138 needs to be fixed first by them.
Edit: my PR to fix the issue went in.
anntzer commented on Jun 19, 2018
Upon further thought, I am against switching to qtpy. The main reason for this is that we already don't declare a dependency on any qt binding, and I guess we wouldn't declare a dependency on qtpy either. Likewise, qtpy does not (by design) declare a dependency on any qt binding. The end result is that you'd have to add yet another manual dependency management step for whoever wants to install matplotlib+qt from pypi.
timhoffm commented on Jun 20, 2018
Not sure if this really works and is an accepted way of doing things, but could we create a placeholder package matplotlib-qt, that will basically only resolve the required dependencies when installing it with pip?
anntzer commented on Jun 20, 2018
That doesn't really help, as the main sticking point is that multiple underlying qt bindings are supported (unless you want to create matplotlib-pyqt4, matplotlib-pyqt5, matplotlib-pyside, matplotlib-pyside2, but meh).
1 remaining item
tacaswell commented on Jun 20, 2018
We have to keep supporting all the qt bindings and probably should not pick an (official) favorite. We definitely can not pick up any dependencies on GUI bindings on pypi by default. We probably should be using the 'extras' part of setup.py a bit more effectively though to support pip install matplotlib[pyside2] etc.
The advantage of moving to qtpy is that we can deprecate all of our binding selection logic and off-load it to qtpy. We are then automatically in sync with any other project that uses qtpy (there is nothing more frustrating that trying to use more than one package that is opinionated about how to import qt bindings....).
anntzer commented on Jun 21, 2018
I think this would only be true if you decide to kill the qt4agg and qt5agg backends and replace them by a single qtagg backend, because otherwise we would still need to maintain code to override the backend selection logic to force either qt4 (pyqt4/pyside) or qt5 (pyqt5/pyside2). (TBH I actually wouldn't mind doing such a deprecation, but I won't be the one making the call...)
timhoffm commented on Jul 14, 2020
Is this still needed now that Qt4 is deprecated since Matplotlib 3.3?
QuLogic commented on Jul 15, 2020
Depends on how Qt6 goes, I guess?
timhoffm commented on Jul 15, 2020
Do we need to/would this cover also PySide2? I not I propose to close this as Qt6 is not yet there and we don't need to hold the PR open just in case it may become relevant.
efiring commented on Jul 15, 2020
Closing. The last discussion was 2 years ago. If new reasons to switch to qtpy arise, a new issue can be opened.