A bit more than a week ago we had a virtual KDE Frameworks 6 sprint, to discuss and decide on some of the next steps in the KF6 transition.

Sprint

Screenshot of the KF6 sprint BBB video call.
KF6 sprint group photo.

Being virtual allowed a lot more people to participate than we had at the last physical KF6 sprint, peaking at more than 30 attendees. That however also means it’s practically impossible for me to cover everything that has been discussed here, as the majority of work happened in smaller groups in parallel.

To see what happened in detail, the KF6 workboard and the sprint meeting notes are useful to look at, below I’ll just cover a few topics that I have been involved with.

Qt 6 Migration

While the first thing coming to mind, the migration to Qt 6 is actually the smaller part of the KF6 work. Nevertheless it is of course a very relevant aspect, and we got progress on a few important points:

  • The minimum supported Qt version for KF5 will be 5.15 starting with KF 5.82 (that is, in April). This will allow to more preparation work in moving away from Qt API deprecated since 5.14, further minimizing the gap to Qt 6 compatibility.

  • At the same time, we’ll increase the minimum requirements for the compiler to C++17 (gcc >= 8, clang >= 6, or MSVC >= 2017) and CMake 3.16. Those are the same minimum requirements that Qt 6 has, which both enables more porting preparation work and doesn’t tie down work on new KF APIs by old requirements.

  • Planning the branching for an actual Qt 6 port will be revisited at Akademy in June.

There were however also two more complex build-system issues which still await final decisions.

ECM and Qt major versions

One such problem is ECM’s reliance on Qt in a few modules, or rather it’s implicit find_package() calls for Qt 5. This is something that will need to be adjusted to Qt 6, and since ECM isn’t parameterized and co-installable on a major Qt version, it actually will need to support both Qt 5 and 6, and least for some time.

Technically this isn’t very complicated, T14233 describes the options to implement this, ECM MR 103 has a prototype implementation for one of the approaches. The problem however is the impact any of this has on many ECM users: before using certain ECM modules, the major Qt version has to be defined in one way or the other, and for a commonly used module like KDEInstallDirs.cmake this is often not the case right now.

Again, not something particularly hard to fix, but before reordering hundreds of CMake files we should at least be very sure we are on the right track.

Version-less CMake targets

Another interesting problem we are going to be exposed to with the upgrade to Qt 5.15 are the version-less CMake targets that Qt introduced. That is, you can now link against Qt::Core rather than Qt5::Core and that will also work with Qt 6. On first sight that looks like a very useful tool for migrating to a new major Qt version (and it certainly is).

There’s a catch though, for libraries intended for public consumption (such as KF): By using version-less targets, they will leak into the installed CMake config files. This has two consequences for code using this:

  • Version-less targets can be disabled, which makes sense for code bases supporting multiple major Qt versions at once. That’s not something that we commonly do in KDE, but e.g. Poppler is a prominent example for doing this. Once you have a dependency using version-less targets in its CMake config file this will not work anymore.

  • The decision which major version a version-less target refers to moves to the consuming code. That can become a problem if that ends up being a different major version that the dependency was originally build against. This can result in mixing multiple major versions of Qt, causing hard to predict compile-, link- or even runtime errors. There might be ways to introduce safeguards against such unintended mixing though, but that needs some more research.

Based on that we need to take a decision on whether or not we can use Qt’s version-less targets in KDE Frameworks, and following that, whether we want to introduce similar version-less targets for the KF libraries ourselves. See T14164.

The Framework product

There was also some discussion on the structure of the KDE Frameworks as a product. Essentially KDE Frameworks contains three different types of components:

  1. Libraries that abstract platform features behind a cross-platform API (e.g. KF5::Notifications), or are a self-contained platform-independent implementation of a specific feature (e.g. KF5::SyntaxHighlighting). Those are ideal for applications, as you don’t have to worry about platform specifics.

  2. Libraries for integrating with platform-specific technologies, typically requiring a specific service (e.g. NetworkManager), a certain technology (e.g. D-Bus or Wayland), or a specific OS. Those are primarily interesting for platform builders or highly platform-specific applications, while in cross-platform applications they can’t be used unconditionally.

  3. Plasma foundation libraries. That is, components for building Plasma or deeply integrating with Plasma. For those one might even argue they should rather be part of the Plasma product and release cycle, and from an application point of view their use is similar to (2).

If that sounds like rather theoretical, there are a number of reasons why this matters:

  • Communicating expectations. As a cross-platform application developer I want to be able to easily assess on which platform I can rely on a Framework, or whether it implies some deployment challenge due to depending on a certain platform service. For internal communication this would also help, seeing the recent discussion about Baloo on Windows.

  • Guiding API and library design. We have a few Frameworks that don’t clearly fall into one of those categories, e.g. KWallet. The introduction of the tier system with KF5 to structure dependencies has lead to much more focus on minimizing dependencies between Frameworks, my hope would be that we can achieve something similar regarding a cleaner separation between platform abstraction and platform building.

  • Dependency management. Ideally we would find a way to untangle the inter-dependencies between platform abstraction and platform building frameworks, augmenting the rules of the tier system. This however turned out to be rather tricky in practice.

We haven’t found a good way to capture all this yet I think, a good small first step might be refining the existing Framework type classification that was introduced with KF5.

Contribute

The KF6 workboard is the central place for coordinating the work related to Frameworks 6. In order to get open questions resolved and decisions taken a bit faster we’ll also have a weekly one hour BBB call on Saturday 15:00 CEST (13:00 UTC). It’s also worth joining the kde-frameworks-devel mailing list and the #kde-devel channel on Matrix or Freenode.