Der erste KDE-4-Beta gewährt einen Einblick in die zahlreichen innovativen Konzepte der nächsten K-Desktop-Generation.

Schon zu Beginn der Entwicklung weckte das KDE-Projekt hohe Erwartungen: Der Desktop werde nicht nur erheblich attraktiver aussehen und anders funktionieren, sondern auch erheblich schneller sein als der Vorgänger, schallte es aus den Blogs der Entwickler. Wenige Monate vor der Release und kurz nach der Veröffentlichung der ersten Beta-Version prüfen wir, wie das KDE-Projekt sich schlägt.

Neue Kleider

Wer die KDE-4-Beta zum ersten Mal startet, dem fällt zuerst die veränderte Oberfläche auf: Bereits seit der ersten Alpha-Version gibt es die Oxygen-Icons, Abbildung 1 zeigt sie mit dem neuen Dateimanager Dolphin. Im Gegensatz zu ihren Vorgängern, den Crystal-Icons der KDE-3-Serie, erscheinen sie weniger comicartig und zugleich differenzierter: Den sehr einfach gehaltenen Icons in der Symbolleiste stehen die restlichen, strukturierteren Symbole gegenüber. Außerdem richtet sich das Icon-Set jetzt, ebenso wie die Tango-Icons des Gnome-Projektes, nach der Icon-Spezifikation von Freedesktop.org [1]. Das Künstlerteam arbeitet noch an einem neuen Stil für die Widgets, der den bisherigen Standard “Plastik” ablöst. Da aber noch Elemente im Oxygen-Stil fehlen, taucht er noch nicht in der ersten Beta-Version auf.

Abbildung 1: Die Oxygen-Icons in KDEs neuem Dateimanager Dolphin. Der komplette Dolphin-Stil fehlt in der ersten Beta-Version allerdings noch.

Eine weitere grundsätzliche Änderung: Der klassische Desktop gehört der Vergangenheit an. Von nun an übernimmt Plasma die Herrschaft über den Bildschirmhintergrund. Darauf können Sie kleine Applets, so genannte Plasmoids, ablegen (Abbildung 2). Das Konzept ähnelt dem von Superkaramba – was nicht von ungefähr kommt, denn einige Superkaramba-Entwickler gehören dem Plasma-Team an.

Abbildung 2: KDE 4 mit vier Plasmoids: Digitaluhr, Batteriestandsanzeige, Wörterbuch und Twitter-Frontend.

Um das Entwickeln von Plasmoids für Gelegenheitsbastler attraktiver zu gestalten, spalten die Plasma-Entwickler die Applets in zwei funktionale Teile: Die so genannte Data Engine beschafft die Daten, das Plasmoid selbst stellt diese nur noch da. Somit genügt beispielsweise eine Data Engine zum Entwickeln verschiedener Uhr-Plasmoids. Da sich Plasmoids neben C++ auch in Javascript programmieren lassen und Plasma ein einfaches API für Grafikeffekte und SVG-Grafiken mitbringt, können Sie sich auch als Anwender mit geringer Programmiererfahrung kreativ entfalten. Nicht zuletzt deswegen gibt es schon heute über 30 Plasmoids in der KDE-Code-Basis.

Auch die KDE-Kontrollleiste “Kicker” soll dem Plasma-Konzept weichen. Mit der nächsten Beta tritt “Raptor”, ein neues auf Plasma basierendes Panel, die Kicker-Nachfolge an.

Effektvoll

Der KDE-Fenstermanager KWin gilt als einer der soliden Grundpfeiler von KDE. Seine Entwickler trimmen das gute Stück bereits seit langer Zeit auf den korrekten Umgang mit vielen Anwendungen. Mittlerweile feiern jedoch OpenGL-basierte Fenstermanager wie Compiz Fusion große Erfolge, die Fenster und Desktop durch eine als Compositing bekannte Technik mit allerlei Effekten aufpeppen. Somit stellte sich die Frage nach der Zukunft des guten alten KWin.

Compiz kommt als Ersatz nicht in Frage, weil das instabile API für Compiz-Plugins nicht den Kriterien für KDE-Bibliotheken entspricht. Eine Codeanalyse ergab zudem, dass es wesentlich aufwändiger wäre, die komplette KWin-Funktionalität nach Compiz zu portieren, als das Compositing direkt in KWin einzubauen. Zuletzt das K.O.-Kriterium: Compiz läuft nur mit modernen Grafikkarten und selbst dort (mit Ausnahme von Intel-Grafikchips) nur mit proprietären Treibern. KWin verfügt hingegen über drei Modi: Im OpenGL-Modus arbeitet es ähnlich wie Compiz mit den 3D-Fähigkeiten der Grafikkarte. Fehlen die 3D-Treiber, springt der Composite-Modus ein, der das Compositing in 2D über eine eigens dafür geschaffene X-Erweiterung realisiert. Geht auch das nicht, setzen Sie KWin wie unter KDE 3 gewohnt ein. Zumindest auf aktuellen Rechnern bringt KWin nun also auch Funktionalität wie Schatten, Transparenz und animierte Übersichten der virtuellen Desktops mit. Einziger Wermutstropfen: Die Performance entspricht – noch – nicht der von Compiz.

Umsteigen bitte!

Als große Stärke von KDE gilt seit Version 2.0 die Interprozesskommunikation. Die regelt das KDE-eigene DCOP-Protokoll, über das sich KDE-Anwendungen miteinander unterhalten. Auch via Kommandozeile stellt es eine ideale Möglichkeit dar, um Programme über Skripte zu steuern. Nahezu jede KDE-Anwendung bietet derzeit DCOP-Dienste an. Doch das Protokoll basiert auf Qt und der ICE-Bibliothek, die zu den Bibliotheken des X-Server gehört. Es reagiert daher wenig flexibel auf den Einsatz außerhalb von KDE, eine Interaktion mit Nicht-KDE-Anwendungen fehlt.

Die Lösung liegt im so genannten D-Bus-Protokoll, dessen geistige Väter nicht nur dem KDE-, sondern auch dem Gnome- und dem Kernel-Lager angehören. So war die Hardware-Abstraktionsschicht (Hardware Abstraction Layer, HAL) das erste Programm für den Linux-Kernel, das mit D-Bus “redete”. Weitere, wie der Network Manager zum dynamischen Verwalten von Netzwerkverbindungen, folgten. Das klappt, weil D-Bus auch einen Systemmodus besitzt, in dem es von einer ganz normalen Benutzersitzung aus beschränkten Kontakt mit Systeminstanzen wie HAL und Network Manager unterhält. Wie das genau funktioniert, verrät Abbildung 3.

Abbildung 3: D-Bus-Instanzen für normale Benutzer arbeiten sitzungsorientiert und dürfen begrenzt mit Anwendungen der Systeminstanz kommunizieren.

Für KDE 4 konvertierten die Entwickler die DCOP-Schnittstellen vollständig nach D-Bus, für normale Anwender ändert sich daher nichts. Wer jedoch Skripte braucht, die sich auf DCOP-Aufrufe verlassen, muss diese nun in D-Bus-Aufrufe übersetzen, die sich jedoch nicht stark unterscheiden (Abbildungen 4, 5). Das dazu notwendige Basiswissen liefert die KDE-Techbase [2].

Abbildung 4: Wer bislang DCOP verwendet, muss sich künftig an andere Interface-Namen gewöhnen. Trotzdem ähneln sich die Interfaces stark…

Abbildung 5: …wie das Beispiel von KWin zeigt. Links sehen Sie KDEs DCOP-Browser und rechts die Qt-Version des D-Bus-Viewers.

Solide Sache

Der Umgang mit Hardware fällt Anwendungen bislang schwer. Selbst um an einfache Informationen zu kommen, wie etwa den Füllstand der Batterie, müssen die Applikationsentwickler ihr System genau kennen. KDE-4-Anwendungen greifen daher auf die Hardware-Informationsschicht “Solid” zurück, die ein Anfrage-Interface für Hardware anbietet. Solid kommuniziert dabei unter Linux über das D-Bus-Protokoll mit HAL. Für die Interaktion mit Netzwerk-Hardware verlässt sich Solid auf den Network Manager: Der Systemdienst übernimmt in nahezu allen Linux-Distributionen die Netzwerkverwaltung. Plattformen, die HAL oder Network Manager nicht einsetzen, liefern dank des Plugin-Prinzips alternativ einfach ein eigenes Solid-Backend mit, um KDE-Anwendungen über die Hardware und den Umgang mit dem Netz zu informieren.

Musik einfach

Der Multimedia-Hardware widmet das KDE-Projekt eine zusätzliche Schicht namens Phonon (Abbildung 6). Deren Spezialität ist das Leidensthema vieler Linux-Benutzer: Die Sound- und Videoausgabe. KDE 3 verließ sich bisher auf den Multimedia-Soundserver Arts, der im wesentlichen die Audioströme verschiedener Programme mischte. Technisch wäre er zudem auch in der Lage gewesen, Sounds über das Netzwerk auszugeben, was aber niemand ernsthaft nutzte. Vielmehr fiel Arts durch einige Probleme wie hörbare Verzögerungen bei der Sound-Ausgabe negativ auf. Als zuletzt auch ein Maintainer fehlte, musste Ersatz her.

Matthias Kretz, einer der federführenden KDE-Multimedia-Entwickler, hob daher Phonon aus der Taufe. So müssen sich Entwickler von KDE-Anwendungen keine Gedanken mehr um die technischen Details der Audio- und Videoausgabe ihrer Programme machen: Die Distributoren liefern einfach ein oder mehrere Phonon-Backends mit, und die Anwendungen verwenden wahlweise Gstreamer, Xine oder NMM, um Musik und Videos abzuspielen. Wer will, wählt sein bevorzugtes Backend sogar selbst.

Abbildung 6: Solid und Phonon bieten KDE-Programmen eine einheitliche Schnittstelle, um auf Hardware zuzugreifen.

Entdeckungsreisen

Bis vor wenigen Jahren gab es in der Unix-Welt zum Finden von Dateien fast nur find und locate. Mittlerweile indizieren diverse Desktop-Suchen die Inhalte auf der Festplatte. Auf dem Linux-Desktop gilt Beagle von Novell als De-facto-Standard. Es arbeitet jedoch langsam – was nicht zuletzt damit zusammenhängt, dass es zur Indizierung von Spezialdateien externe Programme heranzieht. Die neue KDE-Desktop-Suche Strigi verwendet, wo immer möglich, eigene Analysetools, die wesentlich flinker zu Werke gehen. Ein weiterer Bonus: Dank einer speziellen Technologie findet Strigi Daten in beliebig verschachtelten Containern wieder, etwa innerhalb mehrerer Zip-Container. Außerdem setzt das Tool für alle Dateitypen auf eigene Analyse-Module, was die Indizierung zusätzlich beschleunigt. So verwundert es kaum, dass Strigi in einem Benchmark von Sun die Konkurrenz selbst in trivialen Tests meist weit hinter sich ließ [3]. Als grafisches Frontend für Strigi dient bislang nur der sehr minimalistische Strigiclient, die Entwickler feilen noch an einer besseren Integration.

Im Kontext

Genau wie bei Strigi entwickelt sich der semantische Desktop in Form von Nepomuk (siehe Kasten “Das Nepomuk-Projekt”) nur zaghaft: So besitzt der Dateimanager Dolphin eine Rating- und Tagging-Funktion für einzelne Dateien (Abbildung 7). Dank automatisiertem Tagging, etwa anhand von bestehenden Meta-Daten, finden die Anwender ihre Dateien so präziser als bisher. Zukünftig soll nicht nur die Tagging-Funktion von Digikam direkt auf Nepomuk zugreifen, auch Amaroks Tagging-System ließe sich mit der Technologie realisieren. Dieser “Tag Pool” stellt dann die Daten für alle Programme bereit, die Nepomuk nutzen.

Abbildung 7: Mit Hilfe von Nepomuk erlaubt Dolphin die Kategorisierung und Bewertung jeder Datei.

Eintauchen ins Dateisystem

Mit Dolphin (Abbildung 1) erfüllen die Entwickler den oft geäußerten Wunsch vieler Anwender nach einem einfachen Tool, um Dateien zu verwalten. Die Anwendung bringt eine sehr einfache Oberfläche mit: Links finden Sie die vom Dateidialog gewohnten “Places”, also die favorisierten Ordner. Rechts blendet Dolphin detaillierte Angaben über die aktuell gewählte Datei ein. Im zentralen Bereich wählen Sie eine von drei Ansichten für Verzeichnisse aus: Neben der Symbol- und der Listenansicht gibt es neuerdings auch eine Finder-ähnliche Spaltenansicht, in der sich für jede Verzeichnisebene eine neue Spalte öffnet.

Sie navigieren in Dolphin mit einer Adresszeile in Brotkrumenform. Klicken Sie auf einen freien Bereich oder drücken Sie [Strg]+[L], zeigt Dolphin wieder die gewohnte Eingabezeile. All dies trägt dazu bei, dass Dolphin wesentlich aufgeräumter wirkt als Konqueror.

Auf dem Weg zum Web 2.0

Die Entwickler von Konqueror widmen sich nun verstärkt dessen Aufgaben als Webbrowser. Zwar entbrannte vor einiger Zeit eine heiße Diskussion um Apples Webkit – ein Fork von KHTML – doch mittlerweile arbeitet Apple mit KDE und Firmen wie Nokia und Adobe in einem offenen Repository an Webkit, auch Trolltech will es in Qt 4.4 aufnehmen. Als KPart soll die Technologie dann in Konqueror einfließen. Benutzer von Web-2.0-Seiten – mit denen Webkit wesentlich besser umgeht als KHTML – müssen auf die Technik allerdings noch etwas warten: Standard in KDE 4.0 bleibt KHTML.

Fremde Welten

KDE 4 soll auch unter Windows und Mac OS laufen. Da dem Projekt allerdings Entwickler für die Portierung fehlen, trägt KDE 4.0 für diese Plattformen den Zusatzvermerk “Preview-Version”. Die Anwendungen spielen Sie bequem über eine einfache Installationsroutine auf beide Plattformen. Durch den Einsatz von Qt erhalten sie ein weitgehend natives Aussehen, lediglich die Icons erinnern an KDE. Über einfache Anwendungen hinaus wollen die KDE-Entwickler den Desktop allerdings nicht portieren. Ihr Ziel besteht darin, umstiegswilligen Unternehmen die Migration zu erleichtern.

Die Kraft der zwei Herzen

Wer nur ein Programm betreibt, der nutzt unter KDE 3 meist nur einen Prozessorkern. Dank der verbesserten Thread-Unterstützung von Qt 4 sowie der Threadweaver-Bibliothek von Mirko Böhm ändert sich das nun: Threadweaver verpackt die anstehenden Aufgaben in Jobs, die sich an die Kerne verteilen lassen. Die Resultate der Bemühungen verschickt Threadweaver dann an die zuständigen Programme. Entwickler müssen also nicht mehr direkt mit Threads arbeiten, können aber trotzdem die Vorteile von Mehrprozessorsystemen nutzen.

PIM überall

Auch im Bereich des Personal Information Managements (PIM) haben die KDE-Entwickler viel vor: Frustriert von Engpässen im aktuellen Konzept ersannen sie einen Dienst, der sich speziell als Offlinespeicher für PIM-Daten eignet und auf den Namen Akonadi hört. Das Konzept lehnt sich an den Evolution Data Server an, aber Akonadi verwaltet auch E-Mails und verwendet zur Kommunikation D-Bus sowie ein IMAP-ähnliches Protokoll. Akonadi arbeitet komplett getrennt vom Frontend und die KDE-Entwickler hoffen, dass sich so auch andere Projekte aus dem PIM-Bereich für Akonadi begeistern. Auch Groupware-Hersteller könnten von der Architektur profitieren: Wer eine Akonadi-Anbindung für seine Groupware schreibt, muss dies nur einmal tun. Auch eine Strigi-Integration ist in Arbeit, um Mails, Termine und Adressen schnell wiederzufinden.

Weil die Entwickler den benutzerspezifischen Dienst und die grafischen Frontends konsequent trennen, lassen sich PIM-Daten für Plasma-Applets oder eigene Anwendungen einfach aufbereiten. Eine KDE-Bibliothek für den bequemen Zugriff auf Akonadi gibt es auch. Trotzdem wird das PIM-Projekt vermutlich erst unter KDE 4.1 aufblühen, denn zur Zeit portieren die Entwickler noch die bestehende Technologie. In einem zweiten Schritt, der vermutlich auf die KDE-4.0-Release folgt, übersetzen sie die Programme für Akonadi oder ersetzen sie durch neue Lösungen.

Fazit

Sobald es auf dem Linux-Desktop bunter zugeht, heißt es, dass die Entwickler ein zweites Windows oder Mac OS basteln. Tatsächlich entspringt Plasma der Super-Karamba-Idee, die entstand, lange bevor sich OS X und Windows Vista mit Widgets und Gadgets brüsteten.

Technologien wie Nepomuk und Strigi haben das Potential, den KDE-Desktop in einigen Bereichen ganz weit nach vorne zu bringen. Zudem übertrifft der grafische Stil von KDE 4 den des Vorgängers, auch wenn das Aussehen an einigen Stellen noch Raum für Verbesserungen bietet. Der Schritt hin zu D-Bus und Techniken wie Akonadi zeigt den Willen der KDE-Entwickler, mit anderen Projekten zu kooperieren, ohne dass KDE dazu seine Identität aufgäbe.

Akonadi gibt aber zugleich ein Beispiel dafür ab, dass einige Technologien es wohl noch nicht in KDE 4.0 schaffen werden: Der Desktop hebt sich einige Neubauten für die nächsten Releases auf. Ob KDE 4.0 angesichts der vielen Baustellen termingerecht im Oktober oder November erscheint, steht momentan noch in den Sternen. Zwar geht die Entwicklung in großen Schritten voran, aber auch das KDE-Projekt kocht nur mit Wasser. Das allerdings unter hohem Druck, und damit kocht sichs bekanntlich schneller.