Wenn Programmierer über ein Jahrzehnt lang ein Softwaresystem entwickeln, das so schnell wächst wie KDE, schleichen sich unweigerlich Bausünden ein. Das Desktop-Projekt wagt die Generalsanierung, bei der die Code-Architekten viele Schnittstellen vereinfachen und neue Techniken einführen.

Als Trolltech vor über drei Jahren damit begann, ihr bis dato monolithisches QT aufzubrechen und kräftig zu überarbeiten (siehe Seite 50), stand für KDE die Entscheidung an: Einfach auf QT 4 portieren oder es dem Vorbild gleichtun und die hauseigenen Bibliotheken, APIs und Architekturen modernisieren? Die Entwickler entschieden sich für Letzteres. Dabei krempelten sie die Innereien so kräftig um, dass sich die Arbeit über zwei Jahre hinzog und die erste Release KDE 4.0 noch nicht einmal alle neuen Techniken umfassend nutzen wird. Aber die Neuerungen stehen [1] und jeder Entwickler eines KDE-Programms kann sie guten Gewissens nutzen.

Bereits die Oberfläche ist aufgefrischt. Recht beliebt sind die Plasma-Applets [2], auch Plasmoids genannt (siehe Artikel auf Seite 36). Diese hübschen und nützlichen grafischen Gimmicks wirken wie ein aufpoliertes Superkaramba [3] aus KDE-3-Zeiten, doch die Technik hat sich grundlegend gewandelt. Plasma nutzt SVG (Scalable Vector Graphics), um ansprechende und beliebig in der Größe veränderbare Oberflächen zu schaffen, die der Benutzer frei auf dem Desktophintergrund oder in der Startleiste (Panel) verstauen darf. Praktischerweise funktionieren Superkaramba-Applets auch in Plasma.

Code sparen

Die Programmierer wird freuen, dass Plasma-Applets in wenigen Zeilen Code entstehen – dank des Javascript-Binding ist dazu nicht mal ein Compiler-Lauf nötig. Die von QT 4 bekannte Trennung von Daten (Model) und Ansicht (View) spiegelt sich auch hier wider, sie heißen aber Data Engine und Visualization.

Die Plasma-Technik hat neben dem KDE-Kernteam auch die Entwickler der Mediacenter-Software Linux MCE überzeugt, die damit ihre TV-Bedienoberfläche aufpolieren wollen [4]. Auch in der Musiksoftware Amarok 2 sorgt Plasma für moderne Optik, die nicht hinter der proprietären Konkurrenz aus Redmond und Cupertino zurücksteht. Sogar aufwändige 3D-Darstellungen sind dank der Composite-Effekte unter Linux längst möglich. KWin wird in KDE 4 Compiz-ähnliche Effekte selbst implementieren [5], der Einsatz fremder Fenstermanager erübrigt sich damit.

Für den einheitlichen Look von KDE ist Oxygen zuständig. Es liefert vordergründig einen neuen Satz Icons, das Projekt gibt aber selbst an, Oxygen würde “entwickelt, um eine neue User-Experience zu erzeugen” [6]. Hinter der vollmundigen Ankündigung steckt ein recht umfassendes Konzept, welche optischen Elemente (Farben, Formen und der Detaillierungsgrad) zu einem ansprechenden und gut bedienbaren User-Interface führen. Es setzt auf SVG und hat nebenbei die Benennung der Icons vereinheitlicht, passend zu den Freedesktop-Vorgaben.

Performance

Um trotz der recht aufwändigen SVG-Berechnungen einen performanten Desktop zu behalten, liegen üblicherweise Icons als vorab gerenderte Bitmaps auf der Platte. Diese Bilder gibt es in mehreren Größen, jede in einem eigenen Verzeichnis. Allein das Durchsuchen dieser Directorys schluckt unnötig Zeit und bremst den Programmstart. Dem will der Icon-Cache abhelfen – ein im Google Summer of Code gefördertes Projekt [7], dessen Code inzwischen von Pixmap-Cache [8] erbt. Letzterer taugt für jede SVG-Grafik oder andere zur Laufzeit erzeugten Bitmaps. Das Programm gibt nur noch den Namen des SVG-File und die gewünschte Größe an. Der Pixmap-Cache berechnet beim ersten Mal das passende Bitmap und speichert es zur künftigen Verwendung auf Platte.

Beschleunigte Grafik ist auch das Ziel von Quasar [9]. Zack Rusin will mit diesem Framework grafische Effekte anbieten und miteinander kombinieren. Als Anekdote am Rande sei erwähnt, dass die QT-Firma Trolltech im ersten halben Jahr ihres Bestehens Quasar Technologies hieß [10] und damit auch QT seinen Namen spendete. Heute steht QT freilich für cute (pfiffig).

Blitzartig

Da Quasar vor KDE 4.1 nicht fertig wird, springt ein anderer alter Bekannter aus der KDE-Szene ein, der einige Jahre lang untergetaucht war: Mosfet, der im bürgerlichen Leben Daniel M. Duley heißt und mit Pixie eine flotte Bilderverwaltung entwickelte. Er bündelte seine Erfahrung in einer Library namens Blitz [11]. Künftig sollen die Blitz-Routinen in Quasar einfließen.

Mosfet lobt in einem Interview mit dem KDE Commit Digest [12] auch die Verbesserungen der Klassen »QPainter« und »QImage«, die sogar MMX/SSE-beschleunigte Routinen verwenden. Schnelle Berechnung mit einfachem API ist auch das Ziel der Vektor- und Matrizenberechnungs-Library Eigen [13]. Sie stammt vom KDE-EDU-Team (Chemie-Software Kalzium), ist aber plattformunabhängig implementiert und kommt bereits in KSpread zum Einsatz. Eigen ist außerdem für Spiele-Entwickler und OpenGL-Programmierer gedacht.

Auch für Text hat KDE 4 eine Menge Neuerungen zu bieten. Zum Beispiel bei der lästigen Rechtschreibprüfung: Hier zieht mit Sonnet [14] eine neue Komponente ein, die das bisher genutzt KSpell 2 ersetzt. Als besonderes Schmankerl schafft es Sonnet, die Sprache automatisch zu erkennen, sogar wenn sie innerhalb eines Dokuments wechselt. Statt der sieben Komponenten von KSpell 2 ist Sonnet ein einzelnes Modul, dessen API die Entwickler einfach halten.

Passenderweise hat sich auch bei Font-Rendering und Textlayout eine Menge bewegt, nicht nur innerhalb von KDE, sondern über Projektgrenzen hinweg. Der Text Layout Summit [15] auf der Akademy-Konferenz in Glasgow im Juli 2007 brachte viele Projekte zusammen, die sich der qualitativ hochwertigen Textdarstellung widmen, speziell in Anbetracht der enormen Vielfalt von Schriftsystemen weltweit. Diese Techniken finden indirekt über QT, das zum Beispiel den Font-Renderer Harf Buzz [16] nutzt, Einzug in KDE. Hinzu kommt mit QT 4.4 ein neues Widget für komplexes Textlayout, von dem KDE ebenfalls regen Gebrauch machen wird.

Suchen und finden

Hinter der neuen Desktop-Suche von KDE, genannt Strigi [17], steckt ein ganzer Schwung interessanter Techniken. Es versucht gezielt Metadaten zu sammeln und eine schnelle Volltextsuche zu implementieren. Die KDE-Entwickler haben dabei den Xesam-Standard [18] für Desktop-Suchmaschinen im Blick und implementieren dessen APIs und Query-Sprache. Der Crawler, der die Informationen aus Dokumenten und Archivformaten extrahiert, bildet den Kern von Strigi. Ihn haben die Entwickler optimiert, um viele Datei- und Archivformate schnell zu durchforsten.

Dazu gesellt sich die KDE-Version von Nepomuk [19]. Das Projekt verfolgt als Ziel einen semantischen Desktop. Hinter dem etwas hochtrabenden Begriff stecken handfeste, praktische Dinge wie das Zusammenführen von Metadaten, die je nach Dateiformat an unterschiedlichen Stellen in wechselnder Kodierung liegen. Die Ideen gehen aber um einiges darüber hinaus, wie die Nepomuk-Homepage [20] erklärt.

Metadaten sammelt Nepomuk-KDE in Form eines RDF-Repositorys (Resource Description Framework). Es setzt dabei auf die RDF-Implementierung Soprano [21], die die zentrale Metadaten-Ablage übernehmen wird.

Webbrowser

Ebenfalls in QT 4.4 Einzug halten wird Webkit [22]. Dieser Code hat eine bewegte Historie hinter sich. Ursprünglich hatte sich Apple beim KDE-Projekt bedient und KHTML und KJS benutzt, um auf dieser Basis einen eigenen Browser namens Safari zu entwickeln. Ganz nach den Regeln für freie Software veröffentlichte Apple den eigenen Fork wieder unter der GPL – aber mit so vielen Änderungen, dass die KHTML-Entwickler nur einen Teil wieder in ihre eigene Codebasis aufnahmen.

Die Diskussion riss nie ab, ob KDE den eigenen Code zugunsten des Abkömmlings aufgeben sollte. Nach seinem Einzug in QT gibt es mindestens die Wahl zwischen Webkit und KHTML. Eine endgültige Entscheidung gegen KHTML ist aber noch nicht gefallen.

Eingebettet

Eine sehr flexible Komponententechnik für eingebettete Dokumente kommt vom Schwesterprojekt KOffice. Dessen neues Flake-System ([23] und Abbildung 1) erlaubt es, nicht nur rechteckige Objekte in ein Dokument einzubetten, sondern alle Formen. Ein Flake kann beliebigen Inhalt besitzen und darstellen – hier findet sich wieder das Model-View-Entwurfsprinzip. Sogar verschachteltes Einbetten ist möglich. Die meisten KOffice-Programme sind schon an Flake angepasst, es gibt sogar ein Plugin zur Notendarstellung mit Music ML.

Abbildung 1: Das Flake-API bettet fremde Komponenten in Dokumente ein. Es basiert auf einer Plugin-Architektur mit Shapes für die Datenhaltung und Darstellung sowie Tools zum Verändern der Daten.

Sinnvoll wäre Flake auch innerhalb von KDE, um zum Beispiel ODF-Dokumente mit Hilfe eines KOffice-Moduls in dem neuen universellen Dokumentenbetrachter Okular [24] darzustellen. Okular ist die Weiterentwicklung von KPDF, liest aber weit mehr Dokumentenformate.

Aus KOffice ist bereits Kross [25] in das KDE-Hauptprojekt eingeflossen. Das Skripting-Framework gewährt den Sprachen Python, Ruby und Javascript Zugang zu KDE-Komponenten. Das früher von KDE verwendete KJSEmbed haben die Entwickler dagegen zugunsten von QT Script aufgegeben, das seit QT 4.3 bereits eine ähnliche, sprachspezifische Funktionalität implementiert. QT Script kommt auch in Plasma zum Einsatz – eine Kross-Anbindung für Plasma ist ebenfalls angekündigt.

Bei der Interprozess-Kommunikation hat KDE 4 gänzlich auf D-Bus umgesattelt [26]. Dieser Standard der Freedesktop-Gruppe ersetzt das bisher genutzte DCOP. Dank D-Bus ist die Integration mit HAL (Hardware Abstraction Layer) gleich mit dabei. Auf diesem Weg erfahren KDE-Applikationen nicht nur wichtige Informationen ihrer Schwesterprogramme, sondern merken auch, wenn der Benutzer einen USB-Stick anstöpselt, eine WLAN-Karte einsteckt oder seine Webkamera ausschaltet.

Weil es mit dem Wissen über Änderungen an der Hardware allein nicht getan ist, haben sich die KDE-Entwickler ein weiteres Framework ausgedacht und auf den vielversprechenden Namen Solid [27] getauft. Allen voran erspart es Anwendungsentwicklern, sich um Details der Hardware-Anbindung zu sorgen: Selbst wenn auf einer Plattform kein HAL verfügbar ist, kümmert sich Solid um Alternativen, die dann wieder allen Applikationen zugutekommen.

Solide Arbeit

Ein Artikel auf KDE Dot [28] beschreibt die Vorzüge und Aufgaben von Solid sehr ausführlich. Er erwähnt auch die Verwandtschaft mit Phonon [29]. Diese Bibliothek löst KDE-Applikationen von einem konkreten Soundsystem. War das seit KDE 2 genutzte Arts [30] bei seiner Einführung noch fortschrittlich, haben ihm heute etliche andere Multimedia-Frameworks den Rang abgelaufen. Zu allem Überfluss wird Arts seit Längerem nicht mehr weiterentwickelt.

Das KDE-Projekt musste Arts daher ersetzen und wollte sich nicht erneut in die Abhängigkeit von einem Soundserver begeben. Dank Phonon kann sich jede Distribution nun selbst entscheiden, welchen Soundserver sie einsetzt. Das könnte sogar wieder Arts sein, wenn gleichzeitig KDE-3-Programme laufen sollen. Nur recht anspruchsvolle KDE-4-Audioprogramme werden direkt ein oder mehrere Multimedia-Frameworks einbinden müssen, das Gros der KDE-Applikationen kommt mit Phonon zurecht (Abbildung 2).

Abbildung 2: Phonon dient als Brücke zwischen Applikation und Soundserver, hier NMM (Network-integrated Multimedia Middleware). Das dynamisch nachgeladene Phonon-Backend entscheidet, welches Multimedia-Framework es anspricht. Die Applikation muss sich um keine Besonderheiten des Soundservers sorgen.