Portland: Linux-Desktop aus einem Guss

Das Problem ist bekannt: Es fehlt an Anwendungen für den Linux-Desktop. Vor allem für ISVs (Independent Software Vendors) scheint der Linux-Desktop kein attraktives Ziel zu sein. Ob Branchenlösungen oder Edutainment, ob "WISO Sparbuch" oder Lotus-Notes-Client, ob AutoCAD oder Shareware-Tools: Der unübersehbaren Fülle an Windows-Programmen steht eine eher bescheidene Sammlung an Anwendungen für den Linux-Desktop gegenüber – sieht man von einigen prominenten Großprojekten wie Firefox oder OpenOffice, den Tools der Desktops KDE und Gnome und einigen X11-Klassikern ab.

In seinem Artikel Wo bleibt der Linux-Desktop? nennt Chris Schläger, ehemaliger Entwicklungschef bei Suse und Novell und KDE-Entwickler, unter anderem die unübersichtliche Situation für Softwareentwickler als Ursache für den Mangel an Desktop-Anwendungen. Wo unter Windows die meisten Programmierer mit den Sprachen, Tools und Bibliotheken von Microsoft entwickeln und sehr genau wissen, in welcher Umgebung ihre Anwendungen später laufen werden, stehen unter Linux zahlreiche Programmiersprachen, mehrere GUI-Bibliotheken (Toolkits) und mindestens zwei verbreitete Desktop-Umgebungen – KDE und Gnome – nebst einigen Exoten zur Auswahl. Dazu kommen die Unterschiede zwischen den verschiedenen Distributionen.

Das Problem

Anwendungen für den Linux-Desktop interagieren auf verschiedenen Ebenen mit dem System. Die Schnittstellen des Betriebssystems sind weitgehend durch die Linux Standard Base (LSB) der Free Standards Group standardisiert, einer Spezifikation des Application Binary Interface (ABI). LSB-konforme Anwendungen laufen auf jeder LSB-konformen Distribution.

Hinsichtlich des GUI hält sich die LSB allerdings bedeckt. Sowohl das Gtk+-Toolkit – Grundlage des Gnome-Desktop – als auch das Qt-Toolkit – Basis für KDE – werden in der Desktop-Spezifikation genannt. Die beiden Toolkits sind in unterschiedlichen Sprachen programmiert (C und C++, auch wenn Bindings zu verschiedenen Skript- und Programmiersprachen zur Verfügung stehen) und verfolgen unterschiedliche Programmiermodelle. Sowohl Qt als auch Gtk+ stellen GUI-Primitive wie Buttons, Menüs, Dialogboxen und so weiter zur Verfügung.

Soll eine Anwendung aber wirklich in den Linux-Desktop integriert sein, muss sie sich zudem auf eine Desktop-Umgebung festlegen; Gnome und KDE sind die wesentlichen Alternativen. In den Desktop-Bibliotheken finden die Entwickler "höhere" GUI-Funktionen wie einheitliche Dateiauswahl- und Druckdialoge. Zudem stellen die Desktops Methoden bereit, um Programme via Icon oder Eintrag im Startmenü über die grafische Oberfläche zu starten, bieten Mechanismen zum Datenaustausch und zur Kommunikation zwischen Anwendungen, bringen eigene Tools für bestimmte Aufgaben – Anzeigen einer URL, Verschicken einer E-Mail, Verwaltung von Terminen und Adressen, Online-Hilfe – zur Verfügung. Verkompliziert wird die Angelegenheit dadurch, dass die verschiedenen Linux-Distributionen eigene Anpassungen der Desktops vornehmen und vielleicht auch unter KDE den Gnome-Mailer Evolution an Stelle des integrierten KMail verwenden.

Zwar laufen Gnome-Anwendungen auch unter KDE und umgekehrt, wenn man die Basisbibliotheken der jeweils anderen Umgebung installiert, aber die "Fremd-Anwendungen" sind nur wenig integriert: Sie sehen anders aus, verhalten sich anders, sind über andere Tools zu konfigurieren und nutzen unterschiedliche Hilfsprogramme. Eine für den Gnome-Desktop geschriebene Anwendung wird auf dem KDE-Desktop immer ein Fremdkörper bleiben; um so mehr, je tiefer sie in "ihren" Desktop integriert ist und dessen Funktionen nutzt.

Die Lösung?

Die Freedesktop-Initiative versucht, durch allgemeine Mechanismen Abhilfe zu schaffen, die beide Desktops gleichermaßen nutzen können. Ein Beispiel ist D-Bus, ein generischer IPC-Mechanismus für die Kommunikation von Desktop-Anwendungen untereinander und mit dem Betriebssystem. Außerdem werden Standards entwickelt, die beispielsweise dafür sorgen, dass Copy&Paste zwischen Programmen aus unterschiedlichen Umgebungen funktioniert. Auch die Linux-Distributoren arbeiten an einer Vereinheitlichung, etwa indem sie für KDE- und Gnome-Anwendungen ähnliche Themes bauen, die für eine optische Angleichung sorgen.

Das Portland-Projekt, angestoßen von der Desktop-Arbeitsgruppe der Open Source Development Labs (OSDL), ist ein kleiner Baustein im Rahmen der Freedesktop-Initiative. Man möchte eine von der konkreten Desktop-Umgebung unabhängige Schicht schaffen, die häufig benötigte Aktionen so implementiert, dass sie auf jedem Desktop funktionieren. Auf der Todo-Liste stehen Dinge wie Desktop-unabhängige Dialoge für das Drucken oder das Öffnen einer Datei, das Hinzufügen eines Programms in das jeweilige Startmenü, eine übergreifende Konfiguration, das Starten des richtigen Hilfe-Browsers, das Verschicken von E-Mails mit dem konfigurierten Mailer und so weiter. Die Idee: Der Anwendungsentwickler ruft die Portland-Funktion auf, die dann die Desktop-spezifische Aktion auslöst. Portland soll Bestandteil zukünftiger LSB-Versionen werden.

ISVs müssen sich mit Portland keine Gedanken mehr machen, in welcher Desktop-Umgebung ihre Programme laufen: Distributoren, Desktop- und Portland-Entwickler sorgen dafür, dass die Portland-Funktionen unter Gnome, KDE und sonstigen Umgebungen auf Suse Linux, Red Hat, Debian und so weiter funktionieren. Die Hoffnung: Generische Desktop-Schnittstellen machen Linux für ISVs attraktiver, da ihre Anwendungen auf allen Distributionen und mit allen Desktops vernünftig funktionieren.

Die jetzt in der Version 1 veröffentlichen xdg-utils sind ein erster Schritt in diese Richtung. Sie bestehen aus einer Sammlung von Skripten, die eine Reihe von Aktionen unter Gnome, KDE und Xfce durchführen: das Erstellen einer Mail, das Öffnen einer URL, das Anlegen eines Eintrags im Startmenü, das Ablegen eines Icons auf dem Desktop und das Erfragen der für einen bestimmten Dateityp zuständigen Anwendung.

Die Skripte bestimmen dabei zunächst die laufende Desktop-Umgebung, um die passende Aktion auszuführen. Wird keiner der unterstützten Desktops gefunden, versuchen die Skripte eine generische Lösung, die auch ohne spezielle Desktop-Unterstützung funktioniert. Unter KDE wird beispielsweise zum Schreiben einer Mail und zum Öffnen einer URL auf kfmclient zurückgegriffen, unter Gnome auf gnome-open.

Von einem einheitlichen Datei-öffnen- oder Drucken-Dialog ist man damit zwar noch weit entfernt, aber die Skripte erlauben es einer Anwendung immerhin, die im laufenden Desktop konfigurierten Hilfsprogramme zu verwenden, ohne Details darüber zu wissen. Die Liste der anstehenden Aufgaben zeigt, wohin die Entwicklung gehen soll. Ein erster Schritt dorthin ist getan: Debian, Fedora und OpenSuse werden die xdg-utils in kommenden Versionen integrieren. (odi)