Just a month ago we had the first KDE Framework build against Qt6 without requiring local modifications. Things progressed rapidly from there, just with 2021 ending Kate has been seen running with proper styling and proper file dialogs. And by now we also have KF6 continuous integration for a number of Frameworks modules.

Building against Qt6

More than 40 frameworks are meanwhile building out of the box, close to 60 build with pending merge requests applied or individual problematic parts commented out.

To support this kdesrc-build now also provides initial configuration files for KF6 development builds, covering Frameworks and their dependencies as far as available already.

Note that this is all experimental and only meant for KF6 development. It uses the latest development branches as well as a number of changes still in review or not even submitted to review yet. Do not try to use this yet.

Running applications

Having libraries build and unit tests run is nice, but ultimately we need real applications to see how well things work.

Screenshot of Kate built against Qt6 using the Breeze style.
Kate built against Qt6.

My test subject has been KWrite and, as things progressed, Kate. That’s working well enough to even use it for creating smaller KF6 patches, and uses the Breeze style and proper KIO file dialogs already. A few other widget-based applications have also been seen running. While there is still plenty of work to do of course, overall this seems to be in a much better state than we have been at previous major version transitions at this point.

QML applications are still slightly behind, but things are also starting up there.

Screenshot of Kirigami Gallery built against Qt6 using the Material style.
Kirigami Gallery built against Qt6.

Custom scene graph items are still missing, which shows in the absence of card shadows for example, as well as the Breeze style, as the most visually notable things. But at least we don’t have to work blindly here either.

Continuous integration

We meanwhile also have initial support for KF6 CI builds. This can be enabled as easily as the KF5 CI by just including the linux-qt6.yml template in the .gitlab-ci.yml file of a repository.

Only Linux is supported at this point, the image used for KF6 is essentially the same as used for KF5 just with all dependencies removed that would still pull in Qt5. Not all possible dependencies provide Qt6 support yet, so we might still miss a few things.

KF6 CI builds are not only interesting to verify if things build against Qt6. They also check that we aren’t using any deprecated API scheduled for removal anywhere in KF5.

The CI is also running unit tests, so we can also already identify and fix runtime issues that arise from the Qt6 migration. Most of the tests just worked, which is very promising.

Issues

One of the main goals of doing pilot ports of applications at this stage is identify gaps or problems we missed so far, or that would otherwise block a KF6 release. Here are some examples:

  • Qt6 removed support for arbitrary text codecs (ie. QTextCodec). That’s not a problem for dealing with local input/output, all platforms use some form of Unicode nowadays. However we still need the full set of codecs for text editors and email applications, where we have to read all kinds of legacy formats. A way forward for our use-cases and APIs for this has yet to be determined.

  • Some of Framework’s C++ header install location turned out to rely on include search paths that were only set for backward compatiblity with the 4 series and thus fail to work in a 6 setup. In particular, this affects the version headers, and modules that conflate module and C++ namespace prefixes. This is being addressed in KF 5.91.

  • While the preprocessor gives us means to deal with (limited) C++ API breaks without branching, we have no such tools for QML. In some places of high-impact QML API changes it might therefore be useful to look into implementing forward-compatibility for the new API in the 5 codebase. Kirigami.AbstractListItem.icon looks like such a case, which in 6 will inherit the icon property with a different API from its Qt base class. If possible this would ease the transition, as applying QML changes that typically only fail at runtime is much easier to do step by step while you can fully test the component or application at hand.

Contribute

Obviously all of the above is the result of a big team effort, and you can be part of that!

The KF6 workboard is the central place for coordinating the work related to Frameworks 6. There’s also a weekly one hour call on Tuesday 17:00 CET. It’s also worth joining the kde-frameworks-devel mailing list and the #kde-devel channel on Matrix.