So, Qt fragmentation is apparently a total mess, but this default priority seems to make sense.
When using pylab=qt, it will respect the proposed rcParam 'backend.qt4', which could be either 'PyQt4' or 'PySide'. If it is PyQt4, then the v2 API is not set. If matplotlib is <= 1.0.1, then PyQt4 is always used.
When using gui=qt, the ETS QT_API env variable is respected. If QT_API=pyqt, then PyQt is used with API v2 for compatibility with ETS 4.0. If QT_API is not set, then the default is to use PyQt with the default API version, and if PyQt is unavailable, PySide will be tried as a fallback.
This means that if you have everything installed, QT_API is a ternary switch:
unspecified: PyQt4 v1
'pyqt' : PyQt4 v2
'pyside' : PySide
I also added a section to the reference doc, covering some of this mess.
reorder qt support in kernel
1. ask matplotlib (if imported) - if PyQt4 specified, use API v1
2. ask QT_API - if pyqt specified, use API v2
3. if nothing specified, try PyQt4 v1, fallback on PySide.
update qt import priority per recent discussion
QT_API now supersedes matplotlib rcParam, so the v2 API will always be
used if QT_API=pyqt (as long as matplotlib isn't too old)
Default behavior for no QT_API is unchanged
Thank you for your effort in working around this mess, Min.
This pull request looks good to me, although I have not tested it out myself.
I have merged the corresponding changes to mpl master.
Merge PR #560 'Reorder qt support in kernel'