Virtuoso Layering

The KDE libraries combine functions and tasks that are necessary for KDE applications. For example, KArchive takes care of packing and unpacking archives, and the Solid library provides information about the hardware, such as battery and network status. These libraries developed organically and grew over time. As a result, KDE libraries have many mutual dependencies, as well as dependencies with other libraries.

These dependencies lead to considerable overhead: A programmer who only wants to use a single function must include multiple libraries. The KDE project also provides all the libraries in a massive package; users have always had to install Kdelibs. Additionally, the libraries are tailored to traditional desktop applications, which makes it difficult to use them for mobile devices. The situation has not changed much to this day, except that the libraries have a new name: KDE Platform 4 [1].

At the Platform 11 developer meeting in Randa, Switzerland (Figure 1), some KDE programmers, weary of the problems with KDE's library collection, worked out a plan for the next version of the KDE libraries. This plan kicked off almost three years of development work [2].

Figure 1: In 2011, the KDE developers gathered in the Swiss town of Randa to unravel the KDE libraries.

To start, the KDE developers sanitized all the libraries, with special attention to reducing mutual dependencies. Each library now takes care of a well-defined task. The idea was for programmers to pick out and use individual libraries without having to include all the other KDE libraries  – and supply them to the users later on as well. People who work only with ZIP archives, for example, can just integrate KArchive.

The developers set much store by platform independence: The idea was for the libraries run on Linux PCs and also support other devices.

Gifts from Afar

At the end of 2011, Qt introduced the Open Governance Model [3]. This model empowered the KDE developers to assist actively in the development of Qt and also inject code from the KDE libraries into the Qt project. Injecting code back into Qt has two advantages: Qt programmers benefit from the additional features, and the KDE libraries shrink and reduce their interdependencies. Many KDE programs can now build directly on Qt, without even needing to include a KDE library.

Jos Poortvliet (Figure 2), head of the KDE marketing teams, points to a prime example in one of his blog posts: the code for time zones [4]. After migrating this code from the KDE libraries into the QDateTime class, the libraries for personal information management, in particular, can use Qt directly. This change removed the need to detour via the KDateTime, KTimeZone, and KLocale libraries.

Figure 2: OpenSUSE community manager Jos Poortvliet – here holding a keynote in Thessaloníki – is also a member of the KDE Marketing Team and loves to blog about the next framework.

Because of these massive benefits, the KDE developers examined their libraries for source code that might be suitable for integration into Qt. The code they identified was revised thoroughly before being handed over and checked with new tests. This step involved a huge amount of work, as is evidenced by the long list of contributions from the KDE makers to Qt in the KDE Community wiki [5]. The exchange of code between KDE and Qt is still not complete, and KDE developers are likely to help significantly in the development of Qt in the future – and thus benefit even more.

Collaboration with Qt

KDE developer Aleix Pol talked to Linux Magazine, describing how the collaboration works: "First of all, we need to move the KDE applications to a Wayland-friendly environment." Although the work began years ago, it is still important to pay attention to mutually beneficial cooperation.

"In addition, we no longer consider ourselves as Qt-based, but we do think that the Qt frameworks are part of our stacks. If something in Qt bothers us, we try our best to improve this situation. This was made possible by the open governance model. This is also the reason why it did not already happen in the past. In the future, we expect both bugfixes and noticeable performance improvements," Pol said.

Despite the code sharing, some KDE libraries still use Qt directly and add a few missing features. The KDE developers speak of such libraries as Qt add-ons (or "drop-in Qt add-on libraries"). However, they invented this term themselves; the libraries are not plugins in the traditional sense [6].

Additionally, more than 50 KDE libraries still exist. To at least improve the overview, the KDE developers now group their libraries into frameworks. Each framework consists of one or more libraries [2].

Because of this new organization, the stakeholders have also decided to develop all the libraries under the name KDE Frameworks 5. Thus, KDE Frameworks 5 replaces the old KDE Platform 4. The plural form (i.e., frameworks) is mandatory. Anyone who forgets this is verbally tarred and feathered; I know, because it happened to me at the start of my research.

Function, Integration, and Solution

The makers sort the frameworks into three categories [7]: The Functional frameworks (referred to as functional elements in some documents) have no further dependencies, which makes them perfect for independent use. One example is KArchive, which exclusively takes care of compressing and decompressing archives.

Integration frameworks (or integration elements), however, can have other dependencies – in particular, on other libraries for accessing the current platform or operating system. For example, the Solid framework provides information on the current hardware; to do this, it needs recourse to other components and libraries on some operating systems.

Solution frameworks definitely need additional libraries to fulfill their respective tasks. One example is KIO (KDE Input/Output) [8], which realizes transparent access to files on a network. To do so, KIO in turn relies on the kioslave daemon (Figure 3). The KDE wiki refers to these three categories as types; the official way of saying this is that "the Solid framework is of the integration type."

Figure 3: The Dolphin file manager's Preferences menu contains many KIO slaves, that is, services that simplify file operations.