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?

[kislinsk]

We would be absolutely fine with all the minimum required versions you suggested as we dropped Qt 4 a long time ago already, require CMake 3.18 and require C++17, too.

Last obstacle would be the replacement for XmlPatterns.

Regarding PythonQt I didn't look into it so far. To be honest, I think we won't even need it for future versions of MITK as we had someone working on our Python stuff some time ago in a separate branch, and as far as I remember it is not based on PythonQt anymore. I am happy to help in that regard as well, though, after all the other parts of CTK are ready for Qt 6.

[lassoan]

Last obstacle would be the replacement for XmlPatterns.

XMLPatterns is only used in Libs\CommandLineModules, but Slicer does not use it, so for us it is OK if it is not available with Qt6.

Another very small use is in ctkXMLEventSource.cpp for verifying the XML schema, but that should be easy to replace (and it is not even a problem if that validation is not available if Qt6 is used).

I've asked Florian about PythonQt's expected Qt6 support timeline here: MeVisLab/pythonqt#13

[kislinsk]

Thanks!

We use the command-line modules in MITK but it will definitely ease the migration knowing that we may doing so exclusively. It has other nasty details that are hard to migrate like a future class relying heavily on the internal private implementation of Qt's future class, which - surprise - fails in Qt 6.

Another issue that I couldn't completely ignore while removing Qt 4 support and adding Qt 6 support is that the higher minimum required version of CMake relies on some CMake target-based basics that are not fulfilled with CTK's legacy directory-based approach in some cases. I try to keep these changes to a minimum to focus on Qt-related changes, but we should definitely work on that afterwards. Would be a great opportunity for packaging support to make CTK fully installable.

[madcodingrocks]

It's great to see this moving forward!
If there is any way I can help in the upgrade process, I will be happy to help!

[kislinsk]

Just a little update to let you know that we didn't forget this issue. :)

I migrated all parts of CTK that we are using in MITK, except the CommandLineModule libraries. I am currently discussing internally to evaluate if we really still need the CommandLineModule libraries, as it would be a major effort (and pain in the back) to basically completely rewrite them without Qt XmlPatterns. If not, it would be a great relieve to simply disable them when Qt 6 is selected in CTK.

My next step then is to create a branch in our CTK fork with all my changes and to try to build MITK based on it to eventually validate if CTK not only compiles but continues to work as expected. When this is done, it should be a very good starting point to distribute the remaining work.

It's already a pretty big change and the diff exceeds 15.000 lines, even though 60-70% probably are just removed files mainly because of the dropped Qt 4 support.

[jcfr]

@kislinsk Thanks for the reminder, after #1005 is integrated, we will create a tag identifying the last release building against Qt4 and then move forward with removal of Qt4 and integration of Qt6 support.

[jcfr]

For future reference, the following pull requests fix deprecation warnings and are step toward supporting Qt6 and beyond:

• Fix warnings #1083
• Fix regression in ctkDateRangeWidget  #1086
• Fix warnings #1087
• Improve ctkUtils #1089
• Fix simple warnings #1097
• Fix additional warnings #1098
• Fix warnings #1096

In the process also integrated the following:

• Fix plugin framework tests #1088
• Fix ctkCoreSettingsTest #1084
• Ensure ctk::copyDirRecursively skips hidden file by default #1085

[kislinsk]

I already have a huge patch file for Qt 6 compatibility touching thousands of lines from last year but then were busy with some other projects. I really try to divide everything into digestible commits in the upcoming days or weeks and will make it available. As far as I remember it made at least everything in CTK compatible to Qt 6 that MITK depends on but also removes Qt 4 support.

[kislinsk]

I finally dissected the huge patch file into digestible commits. Since the patch was more than a year old and a lot happened in parallel like the removal of Qt 4 support, I manually applied the fixes again to the latest CTK master:

master...kislinsk:CTK:qt-6

To keep momentum, I only modified the parts of CTK that are used by MITK for now so we can quickly continue Qt 6 migration in MITK and check, if all the code changes in CTK are actually valid. For now, all I can say is that CTK configures, generates, and builds on Windows with Visual Studio 2022 with MITK's subset of enabled CTK features.

This is my initial cache file I use to configure and generate CTK for Qt 6 with cmake -S CTK -B CTK-superbuild -C CTK-Qt6.cmake:

set(BUILD_TESTING OFF CACHE BOOL "")
set(CMAKE_PREFIX_PATH "C:/Qt/6.6.1/msvc2019_64" CACHE STRING "")
set(CTK_BUILD_QTDESIGNER_PLUGINS ON CACHE BOOL "")
set(CTK_LIB_DICOM/Widgets ON CACHE BOOL "")
set(CTK_LIB_PluginFramework ON CACHE BOOL "")
set(CTK_LIB_XNAT/Core ON CACHE BOOL "")
set(CTK_PLUGIN_org.commontk.eventadmin ON CACHE BOOL "")
set(CTK_PLUGIN_org.commontk.configadmin ON CACHE BOOL "")
set(CTK_QT_VERSION 6 CACHE STRING "")
set(CTK_USE_SYSTEM_DCMTK ON CACHE BOOL "")
set(DCMTK_ROOT "D:/MITK-superbuild/ep" CACHE PATH "")

A few notes:

• We inject an external build of DCMTK.
• Finding Qt 6 does not work with Qt6_DIR but this is expected, resp. a known issue. The Qt 6 documentation suggests CMAKE_PREFIX_PATH instead.
• When installing Qt 6, the following optional features are required:
  • Qt 5 Compatibility Module
  • Additional Libraries -> Qt State Machines