Allow Qt 6.x builds of QGIS 3.x

[nyalldawson]

QGIS Enhancement: Allow Qt 6.x builds of QGIS 3.x

Date 2020/10/08

Author Nyall Dawson (@nyalldawson)

Contact nyall.dawson@gmail.com

Version QGIS 3.X (> 3.16)

Background

1. Qt 6 is coming, and it's coming relatively soon (before end of 2020).
2. Qt 5.15 is the final Qt 5 release. It's officially an LTR release, but in reality -- it's not, due to Qt upstream changes which mean that as soon as Qt 6.0 is released they will stop providing public updates to Qt 5.15. At this point (and in the absence of any community fork), Qt 5 is effectively EOL.
3. We have some big hurdles approaching on which we'll be completely dependent on upstream Qt. Probably the most important of these being Apple's move to their own CPU architecture. If we don't move to Qt 6.0, then QGIS is DOA when the new Apple hardware starts selling.
4. Last time we had to tackle this situation (Qt5) we bumped QGIS to a major release (3.0) and broke API for plugins. This caused a lot of COMPLETELY NECESSARY AND 100% JUSTIFIED pain for both users and plugin developers. We should try and avoid repeating this unless we have absolutely no other choice.
5. We waited far too long to move to Qt 5. (it was around the ~Qt 5.7/5.8 release before we jumped). We risked being kicked out of debian because of our much delayed transition. We also had a period of many many years before we could take advantage of upstream Qt improvements and bug fixes as a result, which has directly lead to a culture of ignoring Qt upstream in QGIS development and implementing fixes/improvements as downstream "hacks".
6. The QGIS 2.x -> 3.x transition was extra complicated, in that it also involved the Python 2->3 transition. Thankfully, there's no sign of Python 4.0 on the horizon ;)
7. Qt upstream have repeatedly pledged that Qt 5 -> 6 will be a "soft break", where they are minimising the changes required by applications to transition. In fact, they've pledged that any code which builds without deprecation warnings in Qt 5.15 WILL build and run without issue in Qt 6.

Proposed Solution

1. Following the release of Qt 6.0, we require QGIS 3.18 and above to be buildable and usable under both the Qt 5 and Qt 6 versions. (Qt 5.15 will remain the recommended version for the near future)

2. We classify this as a "soft break" for plugins -- we do NOT permit any breakage of the existing QGIS 3.x stable api, so the only work required for plugins is to ensure that the are not using the API declared as deprecated in Qt 5.15 and can run correctly under either a Qt 5 or Qt 6 build of QGIS. Based on what it's required so far to remove the deprecation warnings from QGIS itself, this should be minimal work for plugin authors. It is the plugin author's choice whether they want to update their plugins to include Qt 6 support (with the understanding that some users of QGIS 3.x will not be able to use their plugins if they do not update!!).

3. We make a concentrated effort prior to the release of Qt 6.0 later this year to clear all the remaining deprecation warnings from QGIS, so that we're ready to switch as soon as possible. Currently we can build without deprecation warnings on Qt 5.14, and the remaining effort to build cleanly on 5.15 without warnings should be achievable in this time frame.

4. We provide a summary guide for plugin authors to advise them of the steps required to upgrade the deprecated Qt 5 API calls

This proposal should minimize harm to plugin authors, while still permitting us to stay current with upstream Qt releases. We'll be able to continue the current focus of upstreaming fixes and features to Qt itself, and also will be fully prepared to start building QGIS for the new Apple architecture (as soon as Qt 6.x and all our other dependencies are available for the Apple CPU, that is!)

Further considerations

While QGIS itself will theoretically be buildable on Qt 6 as soon as all deprecation warnings are cleared from 5.15 builds, we are also dependent on some 3rd party libraries releasing Qt 6 compatible versions.

Specifically, these are:

• the QWT library
• PyQt/sip

Affected Files

all

[3nids]

Thanks a lot for starting this.

Some questions:

1. Does this make Qt 5.15 the minimum Qt version to build QGIS by QGIS 3.18?

2. Instead of explicitly upgrade plugins to PyQt6, could we consider using an agnostic approach (qgis.PyQt), so that the plugin could (flawlessly?) work under PyQt5 and PyQt6 (and maybe Qt for Python). So the plugin could be flagged in metadata as PyQt5 (by default), PyQt6 or "ultimate approach (qgis.PyQt).

[nyalldawson]

@3nids

Does this make Qt 5.15 the minimum Qt version to build QGIS by QGIS 3.18?

No -- we ifdef in support for older Qt versions

Instead of explicitly upgrade plugins to PyQt6, could we consider using an agnostic approach (qgis.PyQt), so that the plugin could (flawlessly?) work under PyQt5 and PyQt6 (and maybe Qt for Python). So the plugin could be flagged in metadata as PyQt5 (by default), PyQt6 or "ultimate approach (qgis.PyQt).

That's ideal, but ultimately it's up to the plugin author to do. It's not going to magically make the plugin compatible with Qt 6 either -- the plugin author will still need to put in conditional handling of Qt6 related API changes.

[lbartoletti]

Thanks Nyall. +1 for me.

1. Do you think we should start adapting the code for the transition from qt5 to qt6 (I'm thinking in particular of QList vs QVector ).

2. @3nids Do we stay with PyQt/sip (sip6 is coming) or are we interested in PySide/Shiboken which is driven by Qt?

3. QWT could be replaced by QtChart -- but QtChart is GPL3

[nyalldawson]

Do you think we should start adapting the code for the transition from qt5 to qt6 (I'm thinking in particular of QList vs QVector ).

Yes -- but with ifdefs guarding the qt 5 build where appropriate. Also note that there's no need for QList/QVector changes in QGIS, upstream didn't break those.

@3nids Do we stay with PyQt/sip (sip6 is coming) or are we interested in PySide/Shiboken which is driven by Qt?

That would need to wait till QGIS 4, it would involve complex API breaks and we want to keep the impact here as tiny as possible

QWT could be replaced by QtChart -- but QtChart is GPL3

Yeah.. QWT development is extremely slow. For reference the current version STILL has dual Qt4/Qt5 support in place! I think we should investigate porting away from this wherever it's easy to do so.

[3nids]

Do we stay with PyQt/sip (sip6 is coming) or are we interested in PySide/Shiboken which is driven by Qt?

I will be working on the grant to evaluate Qt for Python next month.

That would need to wait till QGIS 4

If we ask plugin author to use qgis.PyQt, there are good changes that 90-99% of plugins work on both bindings (I guess, we're mainly talking about plugins having direct call to sip). Introducing an option to choose the binding can be done in cmake.

But that's what will be determined by other QEP #163 so we might better discuss this separately.

[PeterPetrik]

+1

in details,

• really looking forward for QtChart integration, I would love to use it for few plots for mesh layers
• looking at QGIS-Mac-Packager, these are libs based on Qt
  • libqt5keychain
  • qtwebkit
  • qwt
  • qscintilla
  • qca

[roya0045]

Are OS specific dependencies the only reason why supporting version below 5.15? https://doc.qt.io/qt-6/portingguide.html states that using 5.15 to 6 is the easiet to port but won't supporting too many versions of qt potentially cause a lot of IF clauses to ensure support to previous versions?

[M-Rick]

Another reason why Qt6 is interesting, it's its native graphic APIs support like Vulkan, Metal and Direct3D which will improve QGIS speed, especially in 3D which uses will increase in the coming years.

[swaxolez]

I'd really like to see QT 6 builds sooner rather than later so that we can start properly testing Apple Silicon arm64. QGIS under Rosetta 2 is not smooth for me on my new MacBook Pro M1 Max. Out of curiosity, I tried an arm64 QGIS 3.10 compilation for Ubuntu running under Parallels and it absolutely flys by comparison to the Rosetta 2 translation.