Evaluate Qt for Python + Shiboken as a Python bindings solution

[3nids]

QGIS Enhancement: Investigate if Qt for Python + Shiboken is a suitable solution for our project

Date 2020/01/24

Author Denis Rouzaud (@3nids )

Version QGIS 4.x

Summary

This proposal aims at trying Qt for Python and Shiboken to: 1) evaluate if it is technically possible to replace our current Qt bindings (PyQt5) and bindings generator (SIP) 2) list and evaluate the risks involved in this change, mainly the effort that plugin authors will have to achieve compared to a migration to PyQt6. 3) draw a road plan and a rough estimate of the work required

Why ?

The context

Qt6 is at the corner (end of the year) and we should start thinking at what we are willing to accomplish for the next big turn with QGIS 4. Qt bindings will have to change in any case (PyQt5->PyQt6), it is therefore an opportunity to question this choice.

PyQt/SIP, lack of support and bus factor

• PyQt/sip are currently maintained by a one-man company.
• I have personally failed to obtain paid support from it (in the name of QGIS).
• More generally getting support or fixes is really depending on a one man's wills. Sometimes it works, sometimes not. Luckily most of the times, we do get answers on the mailing list.

The return of PySide, Qt for Python, a new hope

In 2015, PySide was ported from Qt4 to Qt5 and became PySide2. In 2018, it was incubated in Qt project and is now known as Qt for Python

Since there is now an official binding for Qt and the binding generator is also distributed, it is the natural candidate for a replacement

What ?

The QEP is NOT for replacing PyQt by Qt for Python, but to investigate this solution. As stated in the summary, the output of this work is: 1) a technical evaluation of using Qt for Python and shiboken for our bindings 2) a list and an evaluation of the risks involved in this change, mainly the effort that plugin authors will have to achieved compared to a migration to PyQt6. 3) a road plan and a rough estimate of the work required

This will come in a 1 page summary addressed the community. We will hereby have a base on which we can discuss.

How ?

The plan is to propose this work in the next grant proposal round as a package of 10 (TBC) days of work.

Notes

Backwards Compatibility

This QEP is an investigation. There is no change involved.

Links

• https://wiki.qt.io/Qt_for_Python

Some of pending issues with PyQt/sip

• Custom widgets not working at top level (QgsDockWidget): https://www.riverbankcomputing.com/pipermail/pyqt/2017-October/039647.html
• [SIP] template based return value https://riverbankcomputing.com/pipermail/pyqt/2018-April/040193.html
• documenting namespaces https://riverbankcomputing.com/pipermail/pyqt/2018-November/041082.html
• SIP Enums and docstring https://riverbankcomputing.com/pipermail/pyqt/2019-March/041423.html
• [SIP] TypeError: unable to convert a C++ Class::ScopedEnum instance to a Python object (fixed, but requires recent sip) https://riverbankcomputing.com/pipermail/pyqt/2019-October/042190.html
• Building SIP with CMake https://www.riverbankcomputing.com/pipermail/pyqt/2019-October/042228.html
• Missing libQt5Xml when running pylupdate (fixed later) https://www.riverbankcomputing.com/pipermail/pyqt/2019-December/042398.html

Votes

(required)

[wonder-sk]

Yeah, investigating this topic in detail would be really useful for the future of Qt & Python! (and a qgis.org grant sounds like a sensible way to support this effort)

[elpaso]

I've been also thinking at this for a long time. Big +1.

[nyalldawson]

+1. As great as having python in qgis is, I shudder to think of the months of wasted time we've all spent in dealing with cryptic sip issues.

[luipir]

hmmm... this is a grant or something that QGIS HAVE to evaluate?

[lucamanga]

👍 I agree to use it as it is "officially" supported.

[3nids]

this is a grant or something that QGIS HAVE to evaluate?

This is a grant proposal to evaluate the solution, not to implement it.

[idanmiara]

My colleague and I developed a wrapper around PySide6, PySide2 and PyQt5 and that finds and uses any of these backends seamlessly - fidget You can see the tests on GitHub Or try it out using our small application gdalos:

pip install gdalos[qt]
python -m gdalos_qt

Of course QGIS is a completely different scale of application and I don't really know the internal interactions between PyQt5 and QGIS, but maybe a similar approach would be good for QGIS.

[cmaureir]

Thanks for considering evaluating PySide/Shiboken :tada: One of the problems I see while reading the description is that PySide doesn't ship lupdate (nor lrelease).

In the initial release of 6.0, lupdate was updated to use clang to parse C++ code https://bugreports.qt.io/browse/QTBUG-71835 and it doesn't support Python. Before, there was an attempt to provide out of the box Python support from other Qt/C++ tools, like uic and rcc, but we couldn't do the same for lupdate.

The old lupdate version that PySide had was a really old /and outdated/ fork from PyQt, which we couldn't port, and ended up removing from the repository, hoping that Python users would choose gettext over what Qt introduced.

It might be an option to use what PyQt provides still, but not sure if that would be an accepted solution.

If that's really something required for QGIS, we could try to either:

1. Add support for Python in the lupdate Qt tool (not sure how difficult it would be),
2. Build an ad-hoc tool that using gettext can mimic what lupdate is supposed to do.

Of course, if there is a number 3. or 4. options to this, I'll be really happy to read it :)

Don't hesitate to ping the community in case of any question (I'd say the telegram group is the more active one, but there is always IRC/Gitter too)