Saturday, 16 March 2024
@vkrause:kde.orgGetting the KDE Mega Relase 6 out was a key milestone in the transition to Qt 6 and KDE Frameworks 6, but it doesn’t mean we are done yet. There’s still components to port and scaffolding to remove.
Porting remaining applications
While KDE Frameworks and Plasma switched completly to Qt 6 with the release, there’s still a number of components in KDE Gear using Qt 5 by default. The following modules still need work:
- Artikulate
- Cantor (MR)
- Kalzium - has Qt6 CI already
- Kig
- KmPlot - has Qt6 CI already
- KTouch (MR)
- Marble (branch)
- Minuet - has Qt6 CI already
- Rocs (QtScript porting MR)
- Step - has Qt6 CI already
- KolourPaint (MR)
- K3b - has Qt6 CI already
- KMix
- Kwave
- Cervisia - partially ported
- Lokalize (MR)
- poxml
- Umbrello
- KDevelop (MR)
- KRDC - has Qt6 CI already
- KImageMap Editor - has partial Qt6 CI already
- Kamoso
- Kirigami Gallery (branch)
- Calindori - CI is Qt6 only but default build is still Qt5?
- ghostwriter - has Qt6 CI already
This list doesn’t include modules that are basically ported but cannot switch yet due to other things depending on them, ie. there is more than those not released for KF6 yet. Same goes for modules providing plugins that are still needed for both versions.
The complexity of the remaining work here ranges from putting on finishing touches and taking the decision to make the switch all the way to dealing with potentially difficult to port dependencies such as QtScript. So there’s something for everyone here ;)
And then there’s of course even more outside of the KDE Gear release automation that also needs to be looked at, Krita for example recently posted their plans for the migration to Qt 6.
Cleaning up porting aids
But even in the modules released exclusively for Qt6 and KF6 already there is still work to be done, namely removing the remaining uses of porting aids such as Qt5Compat.
While the need for this might not seem that pressing anymore there’s many good reasons for doing this sooner rather than later:
- We have many people around still familiar with how to do that and its potential pitfalls. That knowledge tends to fade away over time.
- We pay extra in download, storage and runtime cost for carrying around those dependencies. That matters especially for bundled apps, e.g. for some of our APKs this lead to a 20% size reduction.
- Future-us will hate us for not doing this, in the same way as we were unhappy about past-us not having cleaned up after themselves during the 4 -> 5 migration.
QtCore5Compat
On the C++ side that’s basically QRegExp, QTextCodec and the SAX XML parsing API.
QTextCodec:
- Uses for small chunks of UTF-8, Latin-1 or local 8 bit encoded strings can
be replaced by
QStringAPI (not that common). - Use for larger amounts of data or different codecs can be replaced by
QStringEncoderandQStringDecoder(the most common case). - Uses for listing all codecs needs new API in Qt 6.7 and cannot be replaced just yet (rare).
- Uses in combination of
QTextStreamfor non-Unicode content have no replacement (fortunately very rare by now).
QRegExp:
- Fully replaceable by
QRegularExpression. - Wildcard and exact match support might need changes to the actual expressions,
either manually or via corresponding
QRegularExpressionhelper methods (somewhat common by now as most easy case have long been converted).
Things get a bit more tricky for both of those when these types are used in API and thus propagate through larger parts of the code, but fortunately we only have a few of those cases left. The vast majority of uses is very localized.
SAX XML parser:
- Replaceable by
QXmlStreamReader. - Can require larger code changes and needs extra care when dealing with XML namespaces.
- Fortunately rare by now.
Qt5Comapt.GraphicalEffects QML module
The other big part of Qt5Compat are about 25 graphical effects for QML.
DropShadowandRectangularGlowcan in many cases be replaced byKirigami.ShadowedRectangle, which is probably the most common case here.MultiEffectcovers the rest, ie. shadows on anything else than (rounded) rectangles.LinearGradientin any other orientation than vertical needs a nested and rotated `Rectangle` now to hold the gradient, see e.g. Kirigami.EdgeShadow for an examplein horizontal or vertical orientation can be replaced by aRectanglewith associatedGradient(few cases left).- For anything else you have to hope that the Qt6
MultiEffectprovides a suitable replacement. For the most common cases (blur and opacity masks) that’s the case fortunately, for more exotic effects you might need to get creative.
Plasma5Support
Qt5Compat isn’t the only porting aid though. Plasma5Support is another one to look at, with still hundreds of uses left just within KDE code.
Plasma5Support contains some of the former Plasma Framework functionality, such as the data engines. I have no experience porting away from that myself though, maybe the Plasma team can provide some guidance for that :)
You can help!
In particular removing the remaining porting aid uses in many cases doesn’t need in-depth knowledge of the affected applications but consists of separate and localized changes, so it’s the ideal side-task while waiting for longer compile runs for example.
LXR is a very useful tool for finding the remaining uses and the KDE Development channel on Matrix is the place to ask if you need help. Among my merge requests from the past two weeks you’ll also find 30+ examples for such changes.
ervin
