This is difficult for me. We don't really have numbers on how many people are using Qt4. Since it was basically the preferred backend for vispy (most of the examples were Qt based if they had to be and Qt is the first backend chosen if there are multiple) for a long time.

Switching to qtpy and letting users still choose the various backends they want is fine by me if that is possible. Would people still be able to choose pyqt5 or pyside2? Or would we have to change it all to be qt or qtpy (I don't want this last one)? What about the cases (if any) where PyQt5 and Pyside2 differ? Or those small workarounds where something seems to not work in one but works in the other.

I understand, I feel like both Python2 -> Python3 and Qt4->Qt5 migrations were REALLY hard.

That said, they both happened. PyQt4 isn't even released anymore on PyPi
https://pypi.org/project/PyQt4/#history

The qtpy backend is selected automatically by setting an environment variable. Not convinent for python, but it is effectively the same as setting a global variable and using importlib (which is Vispy's solution)

Users would be able to do

import os
os.environ['QT_API'] = 'PyQt4'

and qtpy will select the desired backend.

The main advantage is that all the backward compatibility logic is handled by qtpy and variable names appear as PySide2/PyQt5 equivalents as opposed to PyQt4 equivalents.

We also get to leverage all the hard work that Spyder is doing.

Assuming that qtpy will support Qt 6, then it would be good to do this transition. Is it a priority for the qtpy project to support the whole Qt API? I could see some of the GL stuff not being a priority.

The environment variable stuff should never be something a vispy user has to deal with. We can hack that in to our existing app import stuff if needed.

I agree the environment variable stuff shouldn't be used by a typical user.

we've been using qtpy with napari and I've found it quite nice. I've only used it with PySide2 and PyQt5, but I think it supports PyQt4 and PySide too so you might be able to continue supporting Qt4 even if you make the switch.

I actually wrote a qtpy backend for vispy in this (closed and unmerged) PR napari/napari#331 before vispy 0.6 and seem to remember it worked fine. Once 0.6 came out though there was PySide2 supported added by @hmaarrfk and so we just went with that.

I think it would be best to do our next release (0.7) and then remove Qt4. If someone wants to create a pull request to do this, please do and let me know that you're working on it.

Would you accept a switch to qtpy?

Do you anticipate conflicts on this if somebody starts working on it now before the 0.7 release?

Qtpy doesn't seem to support PyQt6 (spyder-ide/qtpy#225) which was just added to VisPy. I still don't really like the extra dependency, but let's go for it if it simplifies things.

No problem getting a PR before 0.7 release as I won't merge it until after and I don't expect any changes to the Qt backend.

Understood.

I'm adding this to the PyCascades 2022 sprint project. I think as an initial point of completion we should remove all code in the _qt.py module dealing with PyQt4 or plain PySide which are both Qt4 only.