The Road to KDE Frameworks 6

At Akademy Lars presented the plans for Qt 6 in his keynote . With Qt 6 planned for November 2020 we have to look at KDE Frameworks 6 within a two year horizon as well. We therefore need to get started with this as well, so we can help to shape Qt 6, and so we ensure a smooth as possible transition.

Planning Frameworks 6

I have previously briefly mentioned the discussions around this at Akademy here, and David has sent a more detailed report on this to the Frameworks mailing list. This topic deserves a few more details though, and things have evolved since Akademy.

The central hub for coordinating plans and work is the KF6 Workboard . The tasks we currently have there basically fall into three categories:

• Ideas/proposals: that is things that still need to be discussed and decided upon, sometimes requiring a more detailed analysis on the impact, or a transition plan. If you have topics you would like to see addressed in KF6, that’s the place to start a discussion. That’s especially a call to Frameworks users.
• Preparation tasks that can be done in KF5-based code already: This is mostly about removing the use of deprecated modules, classes or methods that are expected to go away with Qt 6 or KF6. If you want to get your hands dirty right now, that’s the best place to get started.
• Tasks that depend on Qt 6 or require executing actual ABI breaks: That’s the minority of tasks at this point, and those of course need to wait until that phase of the development starts (I’d guess around H2 2020).

To make progress on the first category there’s the idea to have a KF6 sprint in the not too distant future. We did that for a week in Randa for planning KF5, and that was tremendously helpful in order to come up with a detailed plan on what we wanted to achieve. So I’d not only encourage everyone contributing to Frameworks development to participate there, but also those of you heavily using Frameworks. Feedback from application or workspace developers is immensely valuable, and this is the place to influence the platform you build your software on top. Same goes for the people working on different form factors or underrepresented platforms. Subscribe to T11535 and indicate your interest to participate there.

Planning the Transition

Besides planning what we want to achieve in KF6 I think it’s equally important to plan how we transition there, especially since those transitions haven’t been always exactly smooth in previous occasions. Lars presented Qt’s approach (only minor source incompatibilities if your code builds cleanly without using deprecated methods in the last Qt 5 release), and that’s a good starting point for KF6 too I think.

However, the situation for KDE is different to Qt’s in some aspects. KDE is not primarily producing Frameworks, but products build on top of those (Plasma and hundreds applications), which allows us to define additional criteria for what we are allowed to change or remove.

The current proposal is to define a set of modules that block a breaking change, that is those modules need to be adjusted (or at least need to be trivial adjustable) before a breaking change is allowed. This is less about things like a renamed but otherwise unchanged method but about the less straightforward changes. I would like to avoid things like “KHTML was dropped, just port to QWebEngine”. Yes, both can render an HTML document somehow, but that’s where the similarities end, the API and the capabilities of the APIs are vastly different, and not all use-cases can be easily mapped, if at all. The burden to sort this out should not solely fall on the application maintainers, as that will result in many things staying behind on Qt5/KF5 for years to come.

Which components are part of this set is still under discussion in T11563 . This should contain all actively developed and released products, but ideally nothing on life support and still full of remains from the 4 era. The starting point is Plasma, Applications, Krita and Extragear. So this is also a good reason to promote actively developed things out of Playground, and to retire things from the other categories that we don’t want to carry forward.

Ongoing Work

It’s not all planning and discussion though, actually quite some work has happened since Akademy already:

• Friedrich has been working on infrastructure to disable deprecated methods in KDE Frameworks at compile time in a similar way as Qt does support this, see his blog post for details. This will help with maintenance long-term, and specifically it will allow us to uncover remaining users of deprecated KF5 API.
• Andreas has ported Step, Kalzium and Parley away from KHTML, and Sune has started to do the same for KHelpCenter. We also got rid of quite a few uses of KHTML in Konqueror, only the about screen is remaining there now.
• Dan and Laurent have been porting KSieve, KSMTP and KIMAP away from KTcpSocket.
• David, Laurent and others have been porting away from deprecated Qt methods all over the place, aiming at being able to build things with Qt 5.14 with deprecated methods disabled.

Contribute

It’s a great time to get into KDE Frameworks development! In terms of development tasks there is something for everyone, ranging from simple porting jobs to redesigns of entire modules. It’s also a rare time window where we have more freedom to change things than usual, so it’s the best possible time to bring in your ideas and suggestions, via the KF6 workboard or by participating in the KF6 sprint, especially as a Frameworks user.