While most of the effort around the transition to Qt 6 and KDE Frameworks 6 (KF6) is probably going into Plasma currently, there are still a number of lose ends to tie up in Frameworks itself as well. The below is far from a comprehensive overview of that though, it’s merely a few things I have been involved with recently.
The final bits for this, the formal review process and the actual move of the repository, have now been done as well.
Going forward this will mean one dependency release cycle less to deal with for consumers, and a faster and more predictable way to get upstream fixes rolled out.
Barcode generator API
The barcode generation API in Prison used to have a factory method returning an abstract base class pointer. That requires manual memory management for consumers, and it leaks implementation details which limit us in evolving the API without ABI breaks.
As the base class isn’t really useful for inheriting externally we can just as well move that part to the private class and only expose a value-type like object to the outside.
Unit conversion online updates
The KUnitConversion framework provides - hardly surprising - ways to convert values of different units. In most cases those are fixed conversion rates, but there is also support for currency conversions, and not all of those are static.
KUnitConversion therefore downloads current conversions rates, when needed and at most once a day. The problem here however is that this happens behind a seemingly synchronous API. That’s not only bad for being potentially blocking, it’s also prone to nasty reentrancy problems which we have recently seen in form of deadlocks in QML code calling into KUnitConversion.
To address this, there now is a proposed change moving this to an explicit and asynchronous API. This requires consumers to trigger the currency conversion table update themselves. That’s a bit more work, but it makes the actual conversion API much more predictable.
KIO has its own HTTP implementation, dating back to the early 2000s where this was mainly intended for browser use and the security and privacy threat level wasn’t quite what it is today. Since then the world has changed, KIO’s HTTP is nowadays no longer used by web browsers but rather for API calls. At the same time the HTTP standard has evolved considerably, from new security features such as HSTS to entirely new protocol versions.
For KIO this means we’d like to get rid of our own implementation of HTTP,
replacing it with something that already supports HSTS, HTTP/2, etc.
QNetworkAccessManager would be the first
choice there, as we already use that in many other places anyway.
Co-installability with KF5, ie. the ability to install both KF5 and KF6 in the same prefix at the same time is one of the few hard release blockers, and something that’s being worked on since the beginning. In most cases it’s unfortunately more complicated than just renaming an install location, all consumers need to be adjusted as well and sometimes it simply makes no sense to duplicate a file or program.
Runtime components add even more complexity to that, here we also need look at what should only exist once (and thus needs to retain compatibility of e.g. D-Bus interfaces) and what should be duplicated (and thus must not conflict on D-Bus service names etc).
Sometimes we get lucky and things can be dropped entirely, the above mentioned KIO changes should also help with removing remaining conflicts around cookie storage.
Every week some of those issues get resolved, but there’s still some work remaining. We unfortunately lost the Neon-based install conflict checker tool, on its last run it still showed about 500 conflicting files. Many of those have the same root cause though, so there’s a lot fewer actual issues.
Not strictly a Frameworks topic, but nevertheless somewhat related is porting Okular away from KJS and KHTML. Those are gone in KF6, and Okular is one of their remaining users, and a particular complex and important one.
KJS is used for scripting in PDF files. The official specification for the PDF JS API has a whopping 700+ pages,
even with Okular only implementing parts of that not a small task. The security implications of this
and a limited amount of test documents don’t help either, but fortunately Okular has a decent unit test coverage
for this. So we now have a pending merge request
replacing the use of KJS with
I also looked into replacing KHTML with Qt WebEngine, despite Albert telling me it’s not possible. Turns out he was right. Unlike most other KHTML users we have, Okular doesn’t use KHTML to render content directly to the screen, but to render tiles into an image. Technically that can be done with Qt WebEngine as well, however with two limitations:
QWebEngineViewneeds to be visible for this to work.
- We don’t know for sure when the content is ready to be rendered.
Either one of those could be worked around with some nasty hacks probably, but I haven’t found a way to overcome both at the same time.
So how do we proceed here? There’s two options:
- It was mentioned that there is some ongoing work in Qt in support of compile-time SVG rendering using Qt WebEngine that might face the same problem, and thus might result in a viable solution for Okular as well.
- KHTML is used in Okular for rendering CHM files. Given that is a somewhat rare format nowadays, it might be possible to move that functionality to a standalone app instead. There we can then use Qt WebEngine to render the output directly, bypassing this problem entirely. Albert has started such an app already even.
How you can help
The above are just a few examples of things being done and still needing to be done.
If you want to participate, here are the most important coordination and communication channels:
- There’s a weekly call on meet.kde.org every Tuesday at 17:00 CEST. Topics are prepared here.
- For general communication there’s the kde-frameworks-devel mailing list
#kde-develchannel on Matrix.
- The KF6 workboard has the overview of Frameworks tasks and their status, and same for the Plasma 6 workboard.