Time for another KDE Frameworks 6 update! Since the last one we made significant progress on getting Plasma to build, which also clears the way for properly styled and platform integrated Qt6-based applications.

KDE Frameworks

Since about a month ago the second to last Framework is also building with Qt 6 and has CI coverage for that. This was plasma-framework, which enabled a lot of progress in the Plasma modules build on top.

Applications

There’s also plenty of changes going into applications to prepare for the transition to 6. This is usually done in the same fashion as for Frameworks and Plasma, alongside the 5 code without compromising that, to identify potential issues/risks/challenges as early as possible.

For some applications like Kate this has meanwhile even progressed to a somewhat working state, as described in a post by the Kate team.

Plasma

Of the 51 Plasma repositories relevant for Plasma 6, 29 have already CI coverage for 6, another 10 are building but depend on still pending changes or other modules not available in the CI yet. For a more detailed overview, see this tracking task.

For the rest of the Plasma modules it’s mostly down to the following remaining issues:

  • Use of the removed QDesktopWidget, in particular creative uses such as workarounds for old problems that need careful case by case assessment and occasionally some archaeology.
  • Other removed API in Qt 6 or KF6 without a straightforward replacement. This can be seemingly simple cases like the QNetworkAccessManager::NotAccessible enum, or more complex things like KServiceTypeTrader.
  • A few remaining cases of low-level OpenGL or event handling code in KWin.

Building

If you want to help, here’s a quick summary on how to build with Qt 6 again, given you are familiar with building with Qt 5.

The main difference is the need for the following additional CMake arguments:

-DQT_MAJOR_VERSION=6 -DBUILD_WITH_QT6=ON -DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.91.0

This might seem a bit redundant and unnecessarily cumbersome, and indeed not all of those arguments are needed by all modules. But it’s easier to just use the superset everywhere. And of course all of that will go away once we switch to 6 exclusively.

If you are using kdesrc-build, that also provides configurations for several modules sets already. Those not only contain the necessary build options, but also list the modules that are expected to build already. Include kf6-qt6-build-include instead of kf5-qt5-build-include to use those.

Both approaches assume you do have Qt 6, from distribution packages or self-compiled, and you point CMake to that if it’s not in the default search location.

Also for both cases, a few words of caution:

  • This is only meant to support the transition to 6, and is only aimed at people actively working on this. It is still far away from being practically usable.
  • Co-installability isn’t available yet, in parts this uses the same names and install locations as a 5 installation. Put it into a separate prefix.
  • Interference from Qt-based dependencies that don’t support multiple major Qt versions yet has to be expected, this often shows in form of build errors due to mixing Qt 5 and Qt 6. You might need to comment out the corresponding find_package() calls locally for now.
  • Being able to build does not imply being able to run. This is especially true for QML based code at this point.

That’s not meant to scare you away, just to manage expectations :) If you want to help, give it a try!

Google Open Source Peer Bonus

Our ongoing Frameworks 6 effort got nominated for the Google Open Source Peer Bonus award, alongside the work of many other FOSS contributors.

For some reason this has my name next to it despite being a big team effort. Anyway, I took care of the involved paperwork and made sure the price money has been transferred to KDE e.V..

Contributing

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