Version 5 of KDE Frameworks is nearing completion

Tiers

Some frameworks are helped in their work by several peers. For programmers to be able to assess quickly how complex the dependencies are, the KDE developers subdivide the frameworks into three tiers (Figure 4).

Figure 4: Frameworks 5 groups the many KDE libraries with their cluttered dependencies into four tiers. At the bottom is Tier 1 with base libraries such as KCodecs; above this is Tier 2 with KAuth, KCrash, and others. To the left is Tier 3 with, for example, ktexteditorplugin or kdesignerplugin. Above them all sits Tier 4 with kde4support, Framework integration, KFileAudioPreview, and KHTML. Lines show the dependencies. (From KDE.org)

A framework is part of Tier 1 if it uses no other KDE framework, is platform-independent, and merely relies on the system libraries and official Qt libraries. This is true, for example, of the KArchive framework or the Sonnet spellchecker.

Tier 2 frameworks only depend on Tier 1 frameworks, as well as the system libraries and official Qt libraries. An example is the KDocTools framework, which relies on the services of KArchive.

Tier 3 frameworks can integrate any other frameworks and, of course, use the system libraries and official Qt libraries. Tier 3 frameworks include, for example, KIO, which relies on KDocTools.

If, as a developer, you're interested in a KDE framework that belongs to Tier 1, you don't need to put much thought into dependencies. However, if the framework belongs to Tier 3, you'll need to integrate additional frameworks that may also have a rather complicated mutual relationships.

In recent presentations by the KDE developers, a fourth layer (Tier 4) has even emerged; its frameworks can also depend on Tier 1, Tier 2, and Tier 3 frameworks. Aleix Pol explains the difference from Tier 3: "Tier 4 contains the things that do not use, or interest, anything outside of the KDE workspace. This includes, for example:

Integration with the KDE workspace, which might eventually merge with the workspaces.

The kde4support libraries that other applications rely on for porting – but not after that.

KCMUtils, a module that is used to create system settings.

KHTML, which will probably be replaced by QtWebKit – it's big and poorly maintained."

All told, the picture is rather complex, and the developers are trying to unravel it by assigning four tiers.

Terms and Conditions

The revision of the KDE libraries has been going on for almost three years. About 20 programmers are involved, including both paid full-time developers and volunteers [6]. They have done a great job: When this issue went to press, Frameworks 5 included more than 50 different frameworks, including 19 Qt add-ons, that have no other dependencies besides Qt, nine that only require independent libraries (Tier 2), and 31 with more complex dependencies (Tiers 3 and 4).

A current dependency graph is shown in Figure 4[9], and a list of all frameworks and their respective maintainers is available online [10]. The development is strictly in line with the KDE project's own frameworks policies [7].

The first libraries follow a standard code style, which is based on the practices of the Qt project [11] and aims to improve accessibility and use of the frameworks – in particular for Qt programmers. Additionally, a framework must have a very specific directory structure. The subdirectory docs contains the documentation, and programmers will find sample code in examples.

To guarantee high quality, developers need to submit their frameworks for automated unit tests. The framework must be accompanied by appropriate tests in the tests subdirectory. Finally, all frameworks must use the framework build system, which prescribes CMake, among other things.

Inqlude

On Inqlude [12], the KDE developers have gathered other Qt-based libraries, along with to their KDE frameworks. The intent is to create a repository in which Qt programmers can look for pre-built components for their applications (Figure 5). Inqlude is currently under construction, and it's uncertain whether the Qt community will adopt the directory.

Figure 5: The Inqlude site already has many interesting libraries for Qt programmers, not just those by the KDE team.

The KDE team has decoupled the release cycles of Plasma workspaces (i.e., the actual desktops), the frameworks, and applications [13]. These parts are even allowed to skip releases if the stake-holding programmers require more time for development. This approach should help developers in particular port applications to KDE Frameworks 5.

The first beta version of KDE Frameworks 5 is scheduled for release April 5, 2014, and the first stable version June 1. If you are interested, check out the current status of the libraries in the Git repository [14]. The archives on the KDE download servers only offered the Tech Preview [15] (published at the beginning of January) at the time of writing, but an alpha version is promised within the next few days. In the preview, the frameworks still have the version number of 4.95.0; the libraries were based on the Qt 5.2 release from December 12, 2013.

Later, all revised KDE libraries will move to version 5 and be able to be installed adjacent to the old KDE Platform 4 [16]. The current state of development is revealed on the KDE wiki [17]. KDE developers refer to the tasks to be completed as epics. Step-by-step installation instructions for the pre-release are also provided by the KDE wiki [18].

According to Aleix Pol from the KDE project, however, prebuilt packages of the alpha versions are unlikely for the time being: "The KDE Frameworks are exactly that, frameworks. I know it's not exciting, but it goes a little further than a tarball. One alpha has almost been released and it is expected that the various distributions will create packages. I know that Kubuntu and Arch Linux are already doing that; as for the others, I'm not sure. Our goal is to interest individual Qt-based projects in the frameworks, so that they can use them. It's not really an end-user story. I think the first software that will use KDE Frameworks 5 will be the first alpha of the Plasma workspaces."

On the second day of the Gran Canaria Desktop Summit, Gnome and KDE developers have been focused on topics surrounding meta data, community, and infrastructure. Concerning multimedia, audio support for the open source desktop has proved to be a hot topic.