Since the last update we finally have all Frameworks build with Qt 6 and got one more platform covered on the CI. We are also only two weeks away from Akademy, which is where we’ll make important decisions on how to proceed.


Besides Linux and Android we now also have FreeBSD CI coverage for the Qt 6 builds, thanks to Qt 6 having become available as FreeBSD packages. The roll-out is largely complete, and was remarkably painless. Pretty much everything built without needing additional fixes, and unit test results match the results with Qt 5.

That’s even more surprising given there is one crucial difference in the FreeBSD CI: it doesn’t use separate containers for the Qt 5 and Qt 6 builds. Instead both versions are built on the same system, with both Qt versions installed. This is of course something that eventually has to work, but that has caused various unintended version mixes in the beginning.

The last missing platform for full Qt 5 parity is now Windows. Work for creating a CI image for that is meanwhile under way as well.

Qt Shader Tools

One of the more invasive changes when porting to Qt 6 is the way how shader programs are handled. In Qt 5 that was done by providing OpenGL shaders directly, Qt 6 abstracts the graphics backends (OpenGL, Vulkan, D3D, Metal) and expects shaders in a backend-neutral GLSL format. Those are then translated by the Qt Shader Tools into the specific backend formats. See Eskil’s recent blog post for details.

While that technically makes sense it requires rather substantial changes to the shader code, the build system and the integration code, which is why we had stayed away from this until now. However corresponding changes have meanwhile been integrated in Kirigami, KQuickCharts, Plasma Frameworks and KWin.

Screenshot of a Kirigami shader effect test program showing shadows of a rounded texture.
Kirigami shader effect test program.

With this done all non-deprecated Frameworks can be built against Qt 6 now.


Another noteworthy milestone was being able to run a nested KWin Wayland session with a Qt 6 based KWin. This is not only an important step towards eventually bringing up a Qt 6 based Plasma session, it’s also rather reassuring given the many changes around Wayland in Qt 6, and the long “blind” work on porting KWin.

Screenshot of qdbusviewer running inside a nested KWin Wayland session showing the version number of Qt used by KWin.
Nested KWin Wayland session running qdbusviewer.


Akademy is now only two weeks away. Besides the KF6-related talks by Alex, Nico and myself, we’ll also have a KF6 BoF on Monday Oct 3rd at 15:00 CEST in room 1. That’s where we have to discuss and take some decisions on how to proceed, as with the current progress I don’t think we are terribly far away from branching anymore.

  • What are the remaining “branch blockers”, ie. things that need to happen before branching?
  • What is the scope for the first 6-based release? Just KF6, or are we aiming at also releasing Plasma 6 at roughly the same time?
  • How would branching practically look like, ie. how do we deal with ongoing work in the 5 branch, how do we manage breaking changes, etc.
  • What defines “done”, ie. when do we get back to regular time-based releases eventually?

As those are questions not only affecting KDE Frameworks contributors, I can only encourage everyone to participate and provide their respective input on this!