© Jennifer Swann, 123RF.com

Seit fast drei Jahren arbeiten bis zu 20 Entwickler an einer generalüberholten Fassung der KDE-Bibliotheken. Das Ergebnis erschien Anfang Februar in einer ersten Alphaversion mit vielen Neuerungen.

Die KDE-Bibliotheken fassen Funktionen und Aufgaben zusammen, die für verschiedene KDE-Anwendungen nötig sein können. So kümmert sich beispielsweise »KArchive« um das Packen und Entpacken von Archiven, während die »Solid« -Bibliothek Informationen über die Hardware liefert, etwa den Batterie- und Netzwerkstatus. Diese Bibliotheken sind jedoch im Laufe der Zeit recht pragmatisch entstanden und gewachsen. In der Folge kamen daher viele Abhängigkeiten untereinander und von anderen Libraries hinzu.

Das wiederum brachte gehörigen Overhead mit sich: Will ein Programmierer nur eine einzelne Funktion nutzen, muss er trotzdem gleich mehrere Bibliotheken einbinden. Obendrein stellen die KDE-Entwickler alle Bibliotheken gemeinsam als dickes Paket bereit, Anwender mussten diese »Kdelibs« immer komplett installieren. Außerdem sind die Bibliotheken auch noch auf klassische Desktop-Anwendungen zugeschnitten, was wiederum den Einsatz auf Mobilgeräten erschwert. Diese Situation hat sich bis heute nicht wesentlich geändert, alle Bibliotheken firmieren lediglich unter dem neuen Namen KDE Platform 4 [1].

Abspeckkur

Es musste sich also dringend etwas ändern. Auf dem Entwicklertreffen Platform 11 in Randa (Abbildung 1) setzten sich daher einige KDE-Programmierer zusammen und arbeiteten einen Plan für die nächste Fassung der KDE-Bibliotheken aus. Das war gleichzeitig der Startschuss für die mittlerweile fast dreijährige Entwicklungszeit [2].

Abbildung 1: Im Jahre 2011 trafen sich KDE-Entwickler im schweizerischen Randa, um die KDE-Libraries zu entwirren.

Als Erstes haben die KDE-Entwickler alle Bibliotheken entschlackt und vor allem die Abhängigkeiten untereinander reduziert. Jede Bibliothek kümmert sich nur noch um eine wohldefinierte Aufgabe. Programmierer sollten sich einzelne Bibliotheken herauspicken und nutzen können, ohne gleich die restlichen KDE-Bibliotheken einbinden und später an die Nutzer mitliefern zu müssten. Wer beispielsweise mit Zip-Archiven hantiert, bindet nur noch »KArchive« ein.

Besonderen Wert haben die Entwickler auf die Plattformunabhängigkeit gelegt: Die Bibliotheken sollen nicht nur auf Linux-PCs laufen, sondern sich möglichst einfach auch auf anderen Geräten wiederverwenden lassen. Die KDE-Entwickler haben dabei natürlich primär Smartphones und Tablets im Auge, aber auch die Windows-Plattform.

Geschenke von außen

Ende 2011 führte Qt das Open Governance Model ein [3]. Dies ermöglichte es den KDE-Entwicklern, sowohl aktiv bei der Entwicklung von Qt mitzuhelfen als auch Code aus den KDE-Bibliotheken in das Qt-Projekt einfließen zu lassen. Letzteres hat gleich zwei Vorteile: Qt-Programmierer profitieren von den zusätzlichen Funktionen, während umgekehrt die KDE-Bibliotheken schrumpfen und sich ihre Abhängigkeiten untereinander verringern. Ein KDE-Programm kann jetzt viel häufiger direkt auf Qt aufbauen und muss nicht noch eine KDE-Bibliothek einbinden.

Als Paradebeispiel nennt Jos Poortvliet (Abbildung 2), Leiter des KDE-Marketing-Teams, in einem seiner Blogbeiträge den Code für die Zeitzonen [4]: Nachdem dieser aus den KDE-Bibliotheken in die Klasse »QDateTime« gewandert ist, können insbesondere die Bibliotheken für das Personal Information Management direkt Qt nutzen. Das machte wiederum auf einen Schlag die Bibliotheken »KDateTime« , »KTimeZone« und »KLocale« überflüssig.

Abbildung 2: Open Suses Community-Manager Jos Poortvliet – hier bei einem Vortrag in Thessaloniki – ist zugleich Mitglied des KDE-Marketing-Teams und bloggt gerne über die kommenden Frameworks.

Aufgrund dieser massiven Vorteile haben die KDE-Entwickler ihre Bibliotheken nach Quelltext untersucht, der sich für eine Integration in Qt eignen könnte. Den so identifizierten Code überarbeiteten sie vor der Übergabe gründlich und prüften ihn mit neuen Tests. Dass da viel Arbeit drinsteckt, zeigt eine lange Liste mit den Beiträgen der KDE-Macher zu Qt im KDE-Community-Wiki [5]. Der Austausch von Code zwischen KDE und Qt läuft weiter, die KDE-Entwickler dürften also auch in Zukunft maßgeblich bei der Weiterentwicklung von Qt mithelfen – und davon profitieren.

Zusammen mit Qt

Wie die Zusammenarbeit abläuft, verriet KDE-Entwickler Aleix Pol im Gespräch mit dem Linux-Magazin: “Erst einmal werden wir die KDE-Anwendungen in eine Wayland-freundliche Umgebung bringen müssen.” Auch wenn die Anstrengungen dazu bereits vor Jahren begannen, müsse man hier weiterhin auf gute Zusammenarbeit achten. “Darüber hinaus betrachten wir uns nicht mehr als auf Qt basierend, sondern denken, dass die Qt-Frameworks Teil unseres Stacks sind. Wenn uns also etwas an Qt stört, versuchen wir das Beste, um diese Situation zu verbessern. Das war erst durch das Open-Governance-Modell möglich. Das ist auch der Grund, warum es nicht schon früher passiert ist. In Zukunft erwarten wir sowohl Bugfixes als auch spürbare Performance-Verbesserungen.”

Trotz des Code-Austausches gibt es nach wie vor einige KDE-Bibliotheken, die direkt auf Qt aufsetzen und ein paar dort vermisste Funktionen ergänzen. Bei solchen Bibliotheken sprechen die KDE-Entwickler auch von Qt-Addons (oder von “Drop-in Qt Addon Libraries”). Diesen Begriff haben sie jedoch selbst erfunden, es handelt sich nicht um Plugins im klassischen Sinn [6].

Des Weiteren bleiben noch weit über 50 KDE-Bibliotheken bestehen. Um hier zumindest die Übersicht etwas zu verbessern, fassen die KDE-Entwickler ihre Bibliotheken noch einmal zu Frameworks zusammen. Jedes Framework besteht aus einer oder mehreren Bibliotheken [2]. Aufgrund dieser Neueinteilung haben sich die Verantwortlichen zudem dazu entschlossen, sämtliche Bibliotheken unter dem Namen KDE Frameworks 5 weiterzuentwickeln. Die KDE Frameworks 5 ersetzen somit die alte KDE Platform 4. Dabei ist unbedingt der Plural (also Frameworks) zu verwenden. Wer ihn vergisst, wird verbal geteert und gefedert, so wie der Autor dieses Artikels zu Beginn der Recherche.

Drei Kategorien: Funktion, Integration und Solution

Alle Frameworks sortieren die Macher in drei Kategorien [7]: Die so genannten Functional Frameworks (in einigen Dokumenten auch als Functional Elements bezeichnet) weisen keine weiteren Abhängigkeiten auf, sie sind also vollkommen unabhängig nutzbar. In diese Kategorie fällt beispielsweise »KArchive« , das sich exklusiv um das Komprimieren und Dekomprimieren von Archiven kümmert. Die Integration Frameworks (oder Integration Elements) können hingegen weitere Abhängigkeiten besitzen und insbesondere über weitere Bibliotheken auf die gerade verwendete Plattform beziehungsweise das Betriebssystem zugreifen. Beispielsweise liefert das Solid-Framework Informationen über die verwendete Hardware, wozu es auf einigen Betriebssystemen weitere Komponenten und Bibliotheken heranzieht.

Die Solution Frameworks benötigen zwingend weitere Bibliotheken, um ihre jeweilige Aufgabe erfüllen zu können. Ein Beispiel ist KIO (KDE Input/Output, [8]), das den transparenten Zugriff auf Dateien in einem Netzwerk realisiert. Dazu greift KIO wiederum auf die Hilfe des Kioslave-Daemon zurück (Abbildung 3). Das KDE-Wiki bezeichnet diese drei Kategorien als Typen, der offiziellen Sprechweise zufolge “hat das Framework Solid den Typ Integration”.

Abbildung 3: In den Einstellungsmenüs des Dateimanagers Dolphin finden sich viele KIO-Slaves, also Dienste, die Datei-Operationen vereinfachen.

Etagen

Einige Frameworks lassen sich bei ihrer Arbeit von gleich mehreren Kollegen helfen. Damit Programmierer schnell abschätzen können, wie komplex die Abhängigkeiten sind, teilen die KDE-Entwickler die Frameworks zusätzlich noch in drei Tiers (Schichten) ein (Abbildung 4):

Abbildung 4: Die Frameworks 5 gruppieren die vielen KDE-Bibliotheken mit ihren unübersichtlichen Abhängigkeiten in vier Tiers. Ganz unten liegt Tier 1 mit Basis-Bibliotheken wie Kcodecs, darüber Tier 2 mit Kauth, Kcrash und anderen, links daneben findet sich Tier 3 mit beispielsweise Ktexteditorplugin oder Kdesignerplugin. Und über allem thront Tier 4 mit Kde4support, Frameworkintegration, Kfileaudiopreview und Khtml. Die Linien zeigen: Es gibt Unmengen an Abhängigkeiten.

• Ein Framework gehört zum Tier 1, wenn es kein anderes KDE-Framework nutzt, plattformunabhängig ist und sich lediglich auf System- sowie die offiziellen Qt-Bibliotheken stützt. Dies trifft beispielsweise auf das Framework »KArchive« oder die Rechtschreibkorrektur Sonnet zu.
• Ein Tier-2-Framework hängt nur von Tier-1-Frameworks sowie System- und den offiziellen Qt-Bibliotheken ab. Ein Beispiel wäre das Framework »KDoctools« , das auf die Dienste von »KArchive« zurückgreift.
• Tier-3-Frameworks wiederum dürfen beliebige andere Frameworks einspannen sowie natürlich System- und die offiziellen Qt-Bibliotheken nutzen. Zu den Tier-3-Frameworks zählt beispielsweise KIO, das die »KDoctools« benötigt.

Interessiert sich ein Entwickler für ein KDE-Framework und gehört dieses zu Tier 1, so muss er sich folglich um die Abhängigkeiten keine großen Gedanken machen. Gehört das Framework jedoch zu Tier 3, muss der Programmierer noch weitere Frameworks zusätzlich einbinden, die auch noch in einem recht komplizierten Verhältnis zueinander stehen können.

In aktuellen Präsentationen der KDE-Entwickler taucht sogar noch eine vierte Schicht (Tier 4) auf, deren Frameworks ebenfalls von Tier-1-, Tier-2- und Tier-3-Frameworks abhängen dürfen. Den Unterschied zu Tier 3 erläutert Aleix Pol: “In Tier 4 finden sich Dinge, die nichts außerhalb des KDE-Workspace benutzen oder interessieren sollten. Dort finden sich beispielsweise:

• Die Integration mit dem KDE-Workspace, verschmilzt möglicherweise irgendwann mit den Workspaces.
• Die Kde4support-Bibliotheken, die andere Anwendungen während ihrer Portierung nutzen – aber nicht länger.
• Die Kcmutils, ein Modul, das verwendet wird, um unsere Systemsettings zu erstellen.
• Khtml, das wohl durch »QtWebKit« ersetzt wird – es ist groß und kaum gewartet.”

Insgesamt bietet sich so ein recht komplexes Bild, das die Entwickler durch die Zuordnung von vier Tiers zu entwirren versuchen.

Geschäftsbedingungen

Die Überarbeitung der KDE-Bibliotheken dauert schon fast drei Jahre an. Beteiligt sind ungefähr 20 Programmierer, darunter sowohl bezahlte Vollzeit-Entwickler als auch freiwillige Helfer [6]. Und die haben ganze Arbeit geleistet: Die Frameworks 5 bestanden zum Redaktionsschluss aus über 50 einzelnen Frameworks, darunter 19 Qt-Addons, die außer zu Qt keine weiteren Abhängigkeiten aufweisen, neun die ihrerseits nur unabhängige Bibliotheken benötigen (Tier 2), und 31 mit komplexeren Abhängigkeiten (Tier 3 und 4).

Ein aktuelles Abhängigkeitsdiagramm zeigt Abbildung 4 (siehe auch [9]), eine Liste mit allen Frameworks und den jeweiligen Maintainern bietet [10]. Die Entwicklung läuft strikt nach den vom KDE-Projekt selbst aufgestellten Frameworks Policies ab [7].

Dabei folgen die Bibliotheken zunächst einem einheitlichen Code-Stil, der sich an den Gepflogenheiten des Qt-Projekts orientiert [11]. Das soll vor allem Qt-Programmierern den Einstieg und die Nutzung der Frameworks erleichtern. Zudem muss ein Framework eine ganz bestimmte Verzeichnisstruktur besitzen. Das Unterverzeichnis »docs« enthält etwa die Dokumentation, unter »examples« finden Programmierer Beispielcode.

Um eine hohe Qualität zu garantieren, müssen Entwickler ihre Frameworks automatisierten Unit-Tests unterwerfen. Geeignete Tests müssen dem Framework im Unterverzeichnis »tests« beiliegen. Abschließend haben alle Frameworks das Framework-Buildsystem zu verwenden, das unter anderem Cmake vorschreibt.

Inqlude

Auf der Website Inqlude [12] sammeln die KDE-Entwickler neben ihren KDE Frameworks auch weitere Bibliotheken, die auf Qt aufbauen. Sie wollen so ein Verzeichnis schaffen, in dem Qt-Programmierer nach fertigen Komponenten für ihre Anwendungen suchen können (Abbildung 5). Inqlude befindet sich derzeit noch im Aufbau. Ungewiss ist auch, ob die Qt-Gemeinde das Verzeichnis annehmen wird.

Abbildung 5: Die Seite Inqlude führt bereits jetzt zahlreiche interessante Bibliotheken für Qt-Programmierer auf, darunter nicht nur die des KDE-Teams.

Das KDE-Team hat die Releasezyklen der Plasma Workspaces (also des eigentlichen Desktops), der Frameworks und der Anwendungen entkoppelt [13]. Die genannten Teile sollen sogar Releases überspringen dürfen, wenn die zuständigen Programmierer eine längere Entwicklungszeit benötigen. Das soll besonders beim Portieren von Anwendungen auf die KDE Frameworks 5 helfen.

Die erste Betaversion der KDE Frameworks 5 wird nach den derzeitigen Plänen am 5. April 2014 erscheinen, die erste stabile Version am 1. Juni. Den aktuellen Stand aller Bibliotheken finden Interessierte im Git-Repository [14]. Die Archive auf dem KDE-Downloadserver enthielten bei Redaktionsschluss nur die bereits Anfang Januar veröffentlichte Tech-Preview [15], doch soll in den nächsten Tagen eine Alphaversion kommen. In der Preview tragen die Frameworks noch die Versionsnummer 4.95.0, die Bibliotheken basierten auf dem am 12. Dezember 2013 veröffentlichten Qt 5.2.

Später sollen alle überarbeiteten KDE-Bibliotheken die Versionsnummer 5 erhalten und sich neben der alten KDE Platform 4 installieren lassen [16]. Den aktuellen Entwicklungsstand verrät eine Seite im KDE-Wiki [17]. Die zu erledigenden Aufgaben bezeichnen die KDE-Entwickler darin als Epics. Eine Schritt-für-Schritt-Installationsanleitung für die Vorabversionen liefert ebenfalls das KDE-Wiki [18].

Fertige Pakete von den Alphaversionen wird es laut Aleix Pol vom KDE-Projekt vorerst aber wohl nicht geben: “KDE Frameworks sind genau das, Frameworks. Ich weiß, es ist nicht aufregend, aber das geht etwas weiter als Tar-Files. Eine Alpha ist fast released und es ist zu erwarten, dass die verschiedenen Distributionen Pakete erstellen. Ich weiß, dass Kubuntu und Arch Linux bereits welche bereitstellen, bei den anderen bin ich nicht sicher. Unser Ziel ist es, die einzelnen auf Qt basierenden Projekte für die Frameworks zu interessieren, sodass sie diese nutzen können. Es ist nicht wirklich eine Enduser-Geschichte. Ich glaube, die erste Software, die die KDE Frameworks 5 nutzen wird, ist die erste Alpha der Plasma Workspaces.”

Fazit

Die Entwickler der KDE Frameworks 5 scheinen auf einem guten Weg: Die Bibliotheken werden plattformunabhängig, schlanker und modularer. Programmierer können sich zudem gezielt die Frameworks herauspicken, die ihr Programm benötigt, und müssen keinen dicken Klumpen mit ungenutzten Bibliotheken mehr ausliefern. Von der Übereignung des Quellcodes an das Qt-Projekt profitieren alle Qt- und KDE-Entwickler. Denen helfen auch die einheitlichen, an Qt angelehnten Entwicklungsrichtlinien und Werkzeuge.

Allerdings bestehen die KDE Frameworks 5 noch immer aus über 50 einzelnen Teilen, in denen sich Entwickler erst einmal zurechtfinden müssen. Die Einteilung in Types und Tiers verwirrt eher, als dass sie hilft – eine einfache Liste mit allen vorhandenen Bibliotheken und ihren Abhängigkeiten wäre übersichtlicher und auch aussagekräftiger.

Laut Aleix Pol sprechen für diese Einteilungen jedoch zwei Gründe: “Sie half uns bei der Kommunikation und gab uns ein Bild, wohin die Dinge liefen. Darüber hinaus möchte niemand die Abhängigkeiten von KIO auflisten” [19] (siehe auch KIO in Abbildung 3).