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.
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
ApplicationWindow.overlaythat 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:
BasicListItemhas 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.
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.
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).
There has been a few more noteworthy activities beyond QML regarding KDE Frameworks:
- Qt 6.4 will finally bring a (partial) replacement for the non-Unicode features of the removed QTextCodec
class. This should hopefully allow us to remove some of the last remaining
QTextCodecuses in public KF API, which are a blocker for an eventual KF6 release.
- Friedrich wrote a blog post about the deprecation macro system used to support the transition to KF6.
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
- Use of
QQuickRenderControlin OpenGL code, which clashes with the rendering system abstraction now in place in Qt.
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
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.
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:
- Getting your application ready for KF6, by Alex and Nico.
- KDE Frameworks 6 - Plans and Progress, by myself.
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:
- The KF6 workboard has the overview of Frameworks tasks and their status, and same for the Plasma 6 workboard.
- There’s a bi-weekly call on meet.kde.org, topics are prepared here. The next one will be on Tuesday 16th August at 17:00 CEST.
- For general communication there’s the kde-frameworks-devel mailing list
#kde-develchannel on Matrix.