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:
Application developers either started porting "too" early or "too" late. Some jumped on the 4.x bandwagon quickly and suffered constant API drift, while others waited until "it" (whatever that meant) was stable (whatever that meant). Our users, in the meantime, drummed their fingers waiting for applications and workspace that they could use to be released. The need to get releases of applications out to users put unnecessary pressure on the library development process as well as the workspaces. They were all "welded together" in terms of release management. This reflected how we generally thought of the KDE codebase in general.
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
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.
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:
get to the point that we modularize, and Qt 5 becomes a reasonable target,
and we switch to Qt 5 as a dependency, at that point we'll start bringing
applications over [...] at least two more 4.x releases while changes
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.
to post comments)