<p dir="auto">Please, add backends based on <a href="https://pypi.org/project/PySide6/" rel="nofollow">PySide6</a> (successor of PySide2) and <a href="https://pypi.org/project/PyQt6/" rel="nofollow">PyQt6</a> as the new Qt6 engine lives now.<br>
Many thanks ;-).</p>
<p dir="auto">Both qt6 and gtk4 have been recently released.  qt6 already has a working python binding in pyside6; i guess both qt6 and a gtk4-supporting pygobject should be available "soon".  (For qt6 I first raised the issue <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="584530762" data-permission-text="Title is private" data-url="https://github.com/matplotlib/matplotlib/issues/16836" data-hovercard-type="issue" data-hovercard-url="/matplotlib/matplotlib/issues/16836/hovercard" href="https://github.com/matplotlib/matplotlib/issues/16836">#16836</a> but that issue ended up being mostly about qt4.)</p>
<p dir="auto">It turns out to be very easy to support pyside6 -- it's just a couple of import renames and certain things having moved out of the Qt namespace -- and I basically already have a patch for that.  The main question, however, is whether we want to put that support in a "qt6agg" (and "qt6cairo") backend, or if we decide to move towards having a single "qtagg" (and "qtcairo") backend and fully move qt binding selection to 1) checking if anything is already imported in the process and 2) the QT_API environment variable.</p>
<p dir="auto">Even as of today, if one selects the qt5agg backend but already has PyQt4 imported in the process, we'll silently switch to qt4agg for you (well, modulo the deprecation warning for qt4 support), so we already treat the two backends as somewhat interchangeable.  Although I guess one of the reasons for doing so was that it was not possible to import both PyQt4 and PyQt5 into the same process at all (the second import would fail); I don't know if that's also going to be the case for qt6...</p>
<p dir="auto">I'd say it makes sense to just have a single qtagg backend instead.  The alternate solution of having both qt5agg and qt6agg would probably involve copy-pasting all of backend_qt5agg.py into backend_qt6agg.py, and then replacing backend_qt5agg.py by a small stub similar to the current backend_qt4agg.py, which is a bit... ugh.</p>
<p dir="auto">The same question basically exists for gtk3/gtk4, although perhaps we can wait for a pygobject release that supports gtk4 to make sure it'll indeed make sense to go back to a single gtkagg.  There we'd need to introduce a new GTK_API environment variable though?  Also, there's the additional question of whether that'll confuse people using fairly old docs/versions and confusing that with the old gtkagg (=gtk2) backend, which was removed in matplotlib 2.0... (also, note that a non-numbered qtagg backend also existed back in the times of qt3(!) support (which was removed in matplotlib 1.3).)</p>
<p dir="auto">TL;DR: 1) perhaps wait for PyQt6 and "pygobject4" before deciding on what to do with PySide6; 2) perhaps move to a single backend_qtagg and a single backend_gtkagg instead of splitting by version?</p>