Skip to content

KDE Frameworks 6 QML porting

Saturday, 13 August 2022 | Volker Krause


It’s been three months since my last post about the ongoing transition to KDE Frameworks 6, so another update is long overdue given how much has happened since.

QML Porting

While the main attention had been on porting build system and C++ code so far, meanwhile QML code has also moved into focus. QML code is generally harder to port, due to the lack of compile-time checking and the lack of conditional code based on the Qt version.

Only seeing mistakes at runtime means for every single change we need to ensure to manually exercise the affected code paths. That is much easier to do if everything else is fully working, ie. in the current Qt 5 codebase.

That however is only an option for changes that result in code that works with both Qt 5 and Qt 6. Changes that only work with Qt 6 can’t be done at all yet due to the lack of version-based conditional code (such as the C++ prepocessor gives us).

Qt 5 changes

Fortunately the biggest chunk of required QML changes can be done with Qt 5 as well:

  • Porting away from deprecated modules such as Qt Quick Controls 1 (QQC1) and Plasma Components 2 (PC2). In many cases this can be replaced by usage of Qt Quick Controls 2 (QQC2) and Plasma Components 3 (PC3) in Qt 5 already (there are a few components that only become available with Qt 6 though).
  • Porting away from deprecated QML elements or properties such as RegExpValidator and ApplicationWindow.overlay that have newer replacements in Qt 5 already.

There is a tracker task for the ongoing work on this.

Qt 6 changes

Looking at what remains then, the biggest part of that seems to be a relatively small set of recurring changes, such as:

  • Kirigami’s BasicListItem has now the standard grouped icon property.
  • QtGraphicalEffects has been moved to the Qt 5 compatibility module and thus needs different imports.
  • Several dialog elements need different imports.

To ease the transition eventually and to support testing in the current state, some of those have been implemented as code transformation scripts in kde-dev-script. More things can and should likely be added there as we go.

With those two types of changes applied, the remaining necessary changes are very small, and are mostly limited to lower-level frameworks like Kirigami, chances are that simple applications start out of the box with this already.

Status

The above assessment is not necessarily complete though, that’s just the result from the modules looked at so far. But there has been some nice progress nevertheless, we can meanwhile load our QQC2 style, have most of Kirigami Gallery as well as some simple Kirigami apps function properly, and some first bits of Plasma applets and System Settings come up.

Screenshot of Kirigami Gallery, showing correctly styled selection controls.
Kirigami Gallery, properly styled but still missing some shader effects.

To avoid wrong expectations though, you’ll get little of the above out of the box at this point, this still requires various local modifications to be applied (pending MRs, the above mentioned conversion script, temporary hacks to take out still dysfunctional parts, etc).

KDE Frameworks

There has been a few more noteworthy activities beyond QML regarding KDE Frameworks:

Plasma

39 of the 51 repositories relevant for Plasma 6 have meanwhile Qt 6 CI coverage. Particularly important are the inclusion of libkscreen and kscreenlocker, which are required dependencies for the more central modules like KWin and Plasma Workspace. Plasma Workspace itself builds as well even, but depends on KWin. And that still has a few remaining issues:

  • One remaining use of the notorious QDesktopWidget.
  • Use of QQuickRenderControl in OpenGL code, which clashes with the rendering system abstraction now in place in Qt.
  • Some QEvent-derived classes that need adaption to the changes in Qt’s event classes.
  • Two uses of `moc´-related macros that fail with stricter type requirements in Qt 6.
  • A Wayland protocol code generation change that breaks the build.

Still, combined with the QML work, this allowed to bring up simple Plasma applets in the plasmoidviewer tool.

Screenshot of the Plasma color picker applet running inside the plasmoidviewer tool.
Fully functional Plasma color picker applet shown in plasmoidviewer.

Applications

There has also plenty of movement around our applications, you might have spotted a few success stories and progress reports on Planet KDE, such as:

There’s also Nico’s fancy overview dashboard, iskdeusingqt6.org.

External Qt-based dependencies

Attention has also been put on the other end of the dependency chain, external libraries based on Qt we depend on. Some of those have been adapted to Qt 6 already, in some cases packaging and/or co-installability still needed polish, for others the entire port had yet to be done.

  • libaccounts-qt and signond needed by KAccounts, which in turn is a dependency for things in Purpose, Plasma and PIM.
  • mlt, which Kdenlive is built upon.
  • libqgpgme, which many parts of PIM depend on.

See the corresponding tracker task for an overview of the current status.

Akademy

KDE Akademy 2022 is just a few weeks away, and of course the transition to Qt 6 and KF6 is going to be an important topic there. There’s two related talks in the conference program:

And there will also be a number of related BoFs/meetings of course, to be scheduled closer to the event. This might possibly be our last “pre 6” Akademy, so if you have things you’d like to see happening for KF6, this is your chance to bring it up!

How you can help

Obviously all of the above is the result of a big team effort, and you can be part of that! As noted above, a full Qt 6 based development environment isn’t even needed for that, especially some of the QML porting tasks are actually easier to do in a Qt 5 environment for now.

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