During Akademy last week important next steps for proceeding with the migration to KDE Frameworks 6 have been discussed. Meanwhile we also got closer to full platform parity with the rollout of the Qt 6 Windows CI.

Windows CI

All KDE Frameworks with Windows-support now also build with Qt 6 on Windows, and we have CI coverage for this as well. Compilation-wise this brings us to the same level we had with Qt 5.

There still are a few runtime issues to be sorted out that manifest in unit test regressions or timeouts.

Windows was also the first platform that was updated to Qt 6.4 on the CI, Linux has meanwhile followed, for FreeBSD and Android this is still being worked on. Qt 6.4 brings back a few things we were waiting for, such as support for decoding non-Unicode encoded text and the text-to-speech API.

KWin and Plasma

Following the screenshot of a running KWin session I showed a live demo of a full Plasma session during my KDE Frameworks 6 talk at Akademy.

Screenshot of Plasma shell in a KWin Wayland session running on Qt 6.
Plasma Shell in a KWin Wayland session running on Qt 6.

Everything seen in there was compiled against Qt 6. However, to get to that point this still needed a bunch of local hacks, and things might randomly break or crash once you leave the tested paths. This is far from fit for use, but it’s very useful for development, as we can immediately test all code changes now, rather than working blindly for an extended period of time after dropping Qt 5 support.

There has been a recent push to at least get all of Plasma building with Qt 6, two big blockers in KWin have been resolved by Vlad, the last remaining issue is now waiting for a fix in Qt to be integrated. Most Plasma modules beyond KWin in the dependency chain are already building, the main remaining issues are the last KDELibs4Support use in the date/time KCM and the global menu D-Bus code in plasma-integration.


Porting of large parts of KDE PIM was so far blocked by a missing external dependency, the Qt bindings for GpgME. The challenge there isn’t the changes in Qt as such, but GpgME still using autotools for its build system and the necessary changes to support Qt 6 there.

Thanks to Laurent’s and Ingo’s work this is now largely solved, the Qt 6 bindings for GpgME can be built from the latest development branch of GpgME. That in turn allows building a whole set of KDE PIM libraries and applications as well.

Screenshot of the Kleopatra certificate manager built against KF6 and Qt 6.
Kleopatra certificate manager built against KF6 and Qt 6.

Branching Plan

The biggest news from Akademy however is that we now have a plan on how to proceed with branching and with completing the transition to Qt 6:

  • KF5 feature development stops after the December release (5.101), work on KF5 is reduced to maintenance, regular releases continue but eventually with increasing intervals as changes slow down.
  • KF5 is branched, the main development branch becomes KF6.
  • After branching we remove scaffolding that was only needed for supporting both Qt versions, rename libraries for co-installability, apply QML changes we couldn’t apply before and get started on anything else that had to wait for branching.
  • Plasma follows after its 5.27 release in early 2023 in the same fashion.
  • KDE Gear application can but don’t have to follow the same approach and timeline.

In particular this means that we aim at releasing KF6 and Plasma 6 not too far apart. That makes a lot of sense in my opinion as a KF6 on its own is relatively useless without at least the Plasma platform integration bits available anyway.

However this also means that the time window for larger KF6 changes is rapidly closing. If you want to see something specific happening, now is the time to bring it up and get started!

Apart from that, the focus until December is now to get the pre-branching priority tasks sorted out:

  • Have all essential external dependencies released with Qt 6 support (tracker task).
  • Test that our CI infrastructure is ready for managing multiple major versions at the same time, a feature we haven’t exercised in a long time.
  • Resolve the remaining porting challenges around Qt Quick Controls 1, QTextCodec, and exporting of Q_GADGET types to QML.

A sprint for getting the initial work done would be very useful in early 2023, we are still looking for volunteers to organize that as well as a suitable venue.

How you can help

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

To participate, here are the most important coordination and communication channels: