Shaping the Future of KDE Frameworks

(or: “KDE Frameworks 6 Planning Sprint in Berlin”)

Only two weeks after my previous Berlin visit I came back for the KDE Frameworks 6 planning sprint, kindly hosted by MBition in their posh offices near Spree river and Landwehrkanal.

Already during this year’s Akademy we started discussing our strategies for a Qt 6 transition and created a giant work board of tasks for our next major release of Frameworks. Overall our goal is to keep API breakages to a minimum while still cleaning up some cruft that might have built up over the years. We kicked off the sprint Friday morning with discussions mostly around policies and guidelines.

First of all, we acknowledged that our current release model with monthly feature updates works well but found that we need to be more conscious about merging large changes too close to a release. Furthermore, the fact that there’s actually a “string freeze” before each release to give translators a chance to catch up seems not widely known. In general, the categorization of Frameworks into 3-4 tiers worked but we realized a more fine-grained set of tiers might be necessary.

When Frameworks 5 came out QML was still relatively new and its future unclear; now that it has proven itself, a key goal of Frameworks 6 is making its features more easily used in a widget-less environment. This means for instance removing and splitting out widget dependencies. Moreover, we want to apply a hacksaw to KDeclarative which has a lot of declarative wrappers for other Frameworks which are better supplied by the individual Frameworks themselves. Also, we want to have better separation between API classes and runtime services, so external users of an API don’t have to pay a build dependency price for something they then just talk to at runtime.

Later that day David Edmundson and Eike Hein gave short presentations to MBition employees on what KDE is, why we’re here, what we’re doing, and why MBition has an interest in hosting and supporting such events. The gist of it: thanks to KDE’s more than 20 years of experience writing free software there’s hardly anyone out there who hasn’t benefited from KDE in some way.

Analog Kanban board

Saturday morning Kevin Ottens set up an analog Kanban board using a whiteboard with loads and loads of sticky notes. The idea was to go through every single Framework and see whether its dependencies could be slimmed down, which APIs need an overhaul, and where a sensible split between libraries, runtime services, plug-ins, and so on should be implemented. Kevin then assigned everyone to random groups of three and let each group pick a Framework to start with. It was a nice twist to work with someone else than my usual teammates and also browsing through code I never cared looking at. We began with Tier 3 Frameworks as those were expected to be the most problematic ones with regards to our previously mentioned goals. Since David Faure couldn’t make it to the sprint in person, we had him join through an all-day video call – from what I gather a first for a KDE sprint.

My group started with KTextEditor, the Framework which powers everything that needs a little more than just a simple text area: from simple KWrite up to complex KDevelop. A lot of cleanup had been done there in the past months already, so there wasn’t much to complain. Next were KMediaPlayer and KXmlRpcClient, both of which are pretty much obsolete and will be moved out of Frameworks into their respective only application that actually use them. KConfigWidgets and KCMUtils had some overlap and we plan to move everything related to KCMs into the latter. The worst offender in terms of usage and dependencies inside KConfigWidgets was KColorScheme, which is widely used and desperately needs to move down in Tier, we just aren’t sure yet how.

Once eight Frameworks had been analyzed, we sat back together to discuss our findings and pour them into actionable tasks on the KF6 work board. Then we carried on with the next batch of Frameworks.

KNotificationsV2

Sunday was more of the same: analyze, discuss, add task, repeat. At this point we surpassed 200 open tasks mark on the work board. This is a hint to you, dear reader, that we would love some helping hand in all of this!

After lunch I stole Virtual David Faure™ for an hour to brainstorm ideas for a new KNotification API. During Akademy Nicolas Fella and I already outlined a grand vision for what we want to achieve but the question now was how to pour that into an easy to use API. First of all, we want to introduce proper platform backends for Windows, macOS, Android. Secondly, we want to ensure the history (we found “backlog” a more fitting description) is actually useful. Instead of treating notifications as a fire and forget task, we want applications to keep KNotification objects around and consciously delete them when no longer relevant, removing the notification from history. Finally, we also don’t want to deviate from Freedesktop Notification spec too much.

I still need to go through all uses of KNotification in our code base to see what other less common functionality is worth salvaging. Especially the configuration side of things will need some serious cleanup and I apologize in advance for potentially removing space bar heating. Overall this call with David Faure was very enlightening and now I feel confident I can actually pull this rewrite off :-)

In conclusion, it was a very important and productive meeting for shaping the future of our software stack. Thanks to everyone who made this event possible, and special thanks to MBition for hosting us and the KDE e.V. for sponsoring travel costs and accommodation! Now go join the discussions on the KF6 work board, which is a great first step for becoming part of this amazing community!