Support for Qt >= 6.0

[emmenlau]

I've tried to build CTK with Qt 6.0.0, but already the cmake configuration fails. I've tried to add support for Qt 6 but it turns out there is quite some logic in place to have wrapper macros for calling moc, uic and other tools. Generally Qt 6 should have pretty good cmake support if a very recent cmake is used. But the current implementation of the cmake build scripts is too complex for me to extend it for Qt 6.

Help would be appreciated!

Notes

This section was appended to the original issue description by @jcfr

• Instead of adding qt6_generate_mocs to ctkMacroGenerateMocs (based on qt5_generate_mocs), leverage CMake AUTOMOC feature. See COMP: Update ctkMacroGenerateMocs to fix warnings using qt5_generate_moc #1007 (comment)

[lassoan]

We'll add Qt6 support to CTK when 3D Slicer or MITK moves to Qt6. Usually first major Qt releases are very buggy, so we would wait at least a couple of minor releases. We may also want to delay the upgrade due to Qt licensing changes (there will be no free LTS release for Qt6), so I would guess that we'll update to Qt6 in a year or so.

[jamesobutler]

There are some uses of #include <QWebEngineView> here in CTK and based on https://www.qt.io/blog/add-on-support-in-qt-6.0-and-beyond, Qt WebEngine isn't getting support in Qt 6 until the Qt 6.2 release. In that same blog post it says:

we want to release Qt 6.1 and Qt 6.2 LTS at a faster pace than usual. Qt 6.1 release is coming in April, and Qt 6.2 LTS at the end of September 2021.

So full Qt 6 support for CTK doesn't appear to be viable until Late 2021.

[emmenlau]

Thanks @lassoan and @jamesobutler . Lets leave this issue open then, ok?

[lassoan]

Yes, sure. You can monitor the status of this task here.

[nolden]

@kislinsk would be the person from the MITK team to comment on this when activity starts.

[emmenlau]

Now that Qt 6.2 is out, could this be reconsidered? Its currently not super urgent for us, but would be nice to have...

[jamesobutler]

Work could begin on it. Do you know anything about if PythonQt supports Qt6 yet? It creates the python wrapping for the Qt based CTK widgets. https://github.com/MeVisLab/pythonqt

[lassoan]

CMake, VTK, PythonQt would all need to support Qt6 before CTK can fully support it. @emmenlau if you want to speed up the process then please ask these projects first (and copy here the links to the questions/issues you submit so that we can track the progress).

Based on past experience with Qt, now that they have an (almost) complete release, it will take them about half year to a year to iron out all the major regressions, so I would not rush things too much yet.

[jamesobutler]

I'm not so worried about CMake as Qt work directly with them on updates to support their new build system. However it will require a minimum version update by various projects to use in superbuilds.

For Building Qt from source it requires the following version of CMake [source]:

Version 3.16 and newer (3.17 and newer for -debug-and-release builds 3.21 and newer for -static builds).

[emmenlau]

@lassoan we build VTK against Qt6 successfully. However we do not usually run the tests, so I can not say how well it is supported. cmake seems well supported as @jamesobutler says, I've made the same experience. That leaves mostly PythonQt, of which I do not know much...

[kislinsk]

Since Qt 6.2 is available for quite some time now we consider the migration of MITK to Qt 6. A major blocker is CTK. I already created a pull request for qRestAPI (commontk/qRestAPI#24), but while working on CTK I noticed that a few non-trivial decisions have to be made:

• QtScript has been removed from Qt 6 (and is deprecated in Qt 5) but I was able to solve this with a few ifdefs like in qRestAPI.
• QtXmlPatterns has been removed from Qt 6 (and is deprecated starting with Qt 5.13) and there's no replacement for it in Qt 6
• QRegExp has been removed from Qt 6 (and is deprecated in Qt 5) and even though it's still in the optional Qt6Core5Compat module, it was removed from the interfaces of other classes that are used in CTK. The replacement is QRegularExpression (not available in Qt 4).
• The Qt6 CMake scripts collide with an old version of find_dependency() that was copied from CMake 3.1 into CTK's CMake module folder 8 years ago. The signature changed in CMake 3.9.

It would considerably streamline the migration to Qt 6, if CTK would drop Qt 4 support #1006. I further suggest to raise the minimum required version of CMake to a sane version able to handle modern C++ standards and the current signature of find_dependeny().

I am happy to help with all of that but I need the go from you or a general direction you would like to go to tackle the mentioned blockers.

[jamesobutler]

if CTK would drop Qt 4 support

3D Slicer dropped support for Qt4 in Slicer/Slicer@c7fe93d back in March 2019. It currently requires Qt 5.15 on Windows and macOS. Based on this, I think the 3D Slicer community is fine with dropping Qt 4 support in CTK especially if MITK is ok with it as well. @jcfr can confirm based on the linked CTK issue to drop Qt 4 support.

3D Slicer also currently requires CMake 3.16.3 as a minimum based on the needs for ITK 5.3. 3D Slicer also requires C++17 in preparation for Qt6 and other modern toolkits. You could use these as possible references to set new minimums.

Thanks for your work on the Qt6 support here in CTK.

Have you had any success with PythonQt using Qt6 for the wrapping of the Qt based CTK widgets?