KDE moves forward on Frameworks

The KDE Project recently got together for a sprint called Platform 11 in Randa, Switzerland. One of the major decisions coming out of that gathering is to start work on the next KDE Frameworks — a set of high-level components for applications to use — immediately following KDE 4.7. What does this mean for the community? This time around, KDE won't be dragging users or application developers through the "big change" phase of underlying technologies for KDE.

The KDE Software Collection (KSC), what was once known simply as the K Desktop Environment, comprises everything from the KDE Developer Platform and the KDE Workspaces (such as the desktop and netbook workspaces) to KDE's applications. In the past, this entire collection has moved forward together — or tried to, at any rate. KDE developer Aaron Seigo describes major release cycles as "that 'big change' phase" that included applications, desktop, and pretty much everything else.

That worked well enough when KDE was a smaller and less complex beast and "the overlap between 'people who work on kdelibs' and 'people who work on applications' was very high." As has been noted by many, however, that worked less well when work began on KDE 4:

At Platform 11, KDE folks started thinking that having a "welded together" platform was not the best course of action. Putting application development on hold while doing library development seems a bad idea. It also happens that some libraries offered by KDE may not in fact be of use only to KDE applications. In a discussion over Skype, Seigo noted that the KDE Project wants to allow developers to choose KDE components — such as the Solid Hardware Library — without having to pull in all of the KDE libraries.

The trigger for this decision? As Sebastian Kügler wrote during Platform 11, the impetus to begin working on KDE's Frameworks starts with Qt 5. As Kügler notes, the fact that Qt 5 has a change in its binary interface, "is a good point in time to introduce some changes to our frameworks that are only possible if we change the ABI -- which Qt 5 will do for us anyway."

The decision has been made to start working on the next generation of KDE Frameworks following KDE 4.7 but not applications or workspaces. What are Frameworks? That's what is currently referred to as kdelibs, kde-runtime, kdepimlibs, kdepim-runtime, and kdesupport — essentially the core libraries for KDE user interface elements that are not provided by Qt. These are the libraries used by major KDE applications like the KDE Addressbook, KMail, and Dolphin.

Kügler also says that this will not only make it easier for developers to use KDE Frameworks, but also lower the barrier for contributions to KDE, as well as making Frameworks more suitable for mobile devices. Seigo also emphasized the benefits for using KDE Frameworks on mobile devices such as phones, tablets, and set-top devices: "We want to make it possible that an application developer can use [just one component like Solid] a la carte with a clear set of dependencies."

What Frameworks will be

According to Kevin Ottens, the libraries will be sorted in two categories: the Framework type and into Tiers based on the level of dependencies. The Framework types will be Solutions, OS integration, and functional Qt Addons. Solutions would include a full technology like the Akonadi personal information manager (PIM) or KIO, which provides access to files stored locally or remotely. Solutions would also have libraries and mandatory runtime dependencies. OS integration Addons would either use a built-in feature for an OS or implement it directly. The example given by Ottens is libkdatetime which watches ktimezoned for time zone changes on Linux, but might use the Windows APIs directly. Finally, the functional Addons have no runtime dependencies at all. These would include new libraries like libkcore, which Ottens says "will contain the job classes, handling of command line arguments, text handling classes, file locking, and not much more."

The Frameworks will also be split into Tiers, with the first Tier depending only on Qt itself, Tier 2 depending on Tier 1 frameworks, and Tier 3 having dependencies on Tier 1, 2 and other Tier 3 Frameworks. So, for example, Ottens says that window management would be a Tier 2, OS integration Framework: "The window management features of kdeui will be split out into their own library. It will depend on libkgui and Qt, granting it the Tier 2 label. As it provides integration with the OS which in particular might require a runtime payload (although not in that particular case), it is granted the OS Integration label." Ottens also provides a graph (small version at right, click for a larger version) that visualizes the organization of existing KDE components.

The Frameworks plan also comes with new rules, or at least more explicit rules, that codify (as Ottens says) "changes to our habits which already happened a while ago during the Qt 3 to Qt 4 port." This includes following the license policy, following a consistent coding standard (preferably the kdelibs standard — but that's not required), meeting the criteria of the Tier and Framework type, and maintaining binary compatibility until the next major release of KDE Frameworks.

Next steps

The next steps for the Frameworks plan is to keep working on libraries until KDE 4.7 is branched, as well as trying to contribute to Qt 5. Seigo says that contributions to Qt 5 are going well so far, and that the Qt open governance process is working out satisfactorily. Though there is still work to be done and "lots of details left unresolved" he says that there have already been examples of pushing development upstream to Qt rather than trying to implement or fix things in KDE. Seigo gave the example of a problem with keyboard shortcuts due to a limitation of Qt, and says that he pushed to fix it in in Qt rather than KDE: "in two weeks it was done and in Qt."

After the 4.7 branch has been created, David Faure says the plan is to create a new branch in kdelibs for the work on splitting kdelibs. This will still continue based on Qt 4, says Faure, because "we don't need Qt 5 to reorganize our own code." At the same time, application developers will continue working in master with the kdelibs frozen.

How long will this go on? Seigo said that it will likely be at least two KDE releases before moving to Qt 5 and the new KDE Frameworks:

At the same time, KDE will continue bugfixes and features in kdelibs, but there will be no major changes.

When the time comes for applications to be ported to the new Frameworks, Seigo says that the application developers will find "a cleaner API and a much better dependencies story" and users will see performance gains — but there won't be a lot of changes due to Frameworks themselves. Seigo also says that it will mean dramatic improvements for "those using free software on tablets, set-top boxes" and a next-generation UI for mobile devices on top of Qt 5.

Naturally, mobile is another driver for the project re-thinking how it handles Frameworks. Seigo says that mobile and cross-platform development is very important for the KDE project and there will be a great deal of focus on Android and MeeGo for KDE.

Given the pain that users and application developers went through with the early releases of 4.x, this plan does seem to make a lot of sense for the project. Though it will take some time for it to come to fruition, there should be few downsides for application developers or users while other KDE developers focus on KDE Frameworks.