Linux' Erfolg auf dem Desktop wird stark von der Verfügbarkeit
gängiger Standardapplikationen und deren Integration in das
Desktop-Environment abhängen. Das KOffice-Projekt entwickelt
ein freies, komponentenbasiertes Office-Paket für Unix-Systeme, das
sich in Flexibilität und Funktionalität nicht hinter kommerziellen
Lösungen verstecken muss.
Inhalt
Linux auf dem Desktop ?
Das Ganze und die Summe seiner Teile
Auf der Suche nach der Schwachstelle
Von Knöpfen und Schaltern
Kommerzielle Software: Fluch oder Segen?
KOffice
KOM - KDE Komponenten Modell
OpenParts - Einbetten von Komponenten
Multi-Plattform
Erweiterbarkeit
Trading
Scripting
K(r)ampf der Dateiformate
Stand der Entwicklung
Links
Linux beherrscht in letzter Zeit nicht nur die Diskussion von Technik-Begeisterten und Unix-Freaks, sondern findet sich auch in den Mainstream-Magazinen wieder. Einen guten Teil seiner Popularität verdankt Linux sicherlich seiner Eignung als Server-Betriebssystem. Das ist auch der Grund aus dem sich große Firmen wie IBM, Dell, Compaq, Oracle, SAP und viele andere für Linux interessieren.
Seinen Einzug in die Massenmedien hielt Linux aber auch als Alternative zum herkömmlichen Desktop-System, das für gewöhnlich unter MS-Windows betrieben wird. Während Linux' Vorzüge im Server-Bereich unbestritten sind, ist es immer noch eine heiß diskutierte Frage, ob es sich für den Einsatz auf dem Desktop wirklich eignet, denn eigentlich waren die X11-basierten Oberflächen herkömmlicher Unix-Systeme traditionsgemäß nicht so ansprechend gestaltet wie die Macintosh- oder MS-Windows-Oberfläche. Zudem mangelte es an Standardsoftware. Die Bereiche Büroanwendungen und Spiele waren lange Zeit kein großes Thema unter Linux. Daher griffen die Anwender doch lieber zu einem instabilen System aus Redmond, welches eine ganze Reihe von komfortablen Büroanwendungen anzubieten hatte, anstatt garantiert absturzfrei TeX-Steuerkommandos in Emacs einzugeben.
Die steigende Popularität von Linux einerseits und die Unzufriedenheit vieler Hersteller mit Microsoft andererseits führte schließlich dazu, dass auch Büroanwendungen für Linux erschienen. StarDivision gibt StarOffice in der neuesten Version gar kostenlos an Privatanwender ab, Corel portiert seine Applikationen nach und nach und Applix bietet ebenfalls ein komplettes Office-Paket an.
Den mangelnden Charme herkömmlicher Linux-Desktops konnten diese Pakete aber auch nicht ausbügeln. Drag&Drop von einer Anwendung auf den Desktop, einfaches Konifgurieren von Farben und Schriften - applikationsübergreifend versteht sich - war lange Zeit nicht möglich. Das freie Desktop-Environment KDE trat schließlich an, diesen Missstand zu beseitigen. KDE-Applikationen verfügen über ein einheitliches Look&Feel, lassen sich komfortabel konfigurieren und können Daten mittels Drag&Drop miteinander austauschen. Die Oberfläche lässt sich so flexibel konfigurieren, dass alte Unix-Hasen, MS-Windows-Gepeinigte und abtrünnige Macintosh-User sich gleichermaßen mit dem System anfreunden können.
Einer alten griechischen Weisheit folgend, müsste das Ganze mehr als die Summe seiner Teile sein. Nimmt man also ein sehr stabiles Betriebssystem, eine ansprechende grafische Oberfläche und eine Office-Suite und schüttelt gut, dann sollte das Endresultat besser als die Summe seiner Teile sein. Anscheinend irren die alten Griechen in diesem Fall, denn gemäß obiger Überlegung müsste Linux längst das erfolgreichste Desktop-System aller Zeiten geworden sein.
Anstatt die Schuld auf längst verstorbene große Geister abzuwälzen sollte allerdings auch bedacht werden, ob eines der Teile vielleicht nur unzureichend ist. Der Linux-Kernel selbst ist über jeden Tadel erhaben, und die Bedienerfreundlichkeit von KDE kann sich problemlos mit der jedes anderen Desktops messen. Das bewies neben einer riesigen Menge begeisterter Anwender auch die letzte CeBIT, auf der KDE der Preis der Innovation des Jahres im Bereich Software verliehen wurde.
Es bleibt also zu untersuchen, ob die Büroanwendungen vielleicht doch nicht so gut sind wie ihre MS-Windows-Kollegen. Viele Pakete leiden bis heute an Instabilität. Der Linux-Kernel kann hier selbst nicht helfen. Er garantiert lediglich, dass eine abstürzende Anwendung nicht das ganze System mit ins digitale Nirwana zieht. Im Gegensatz zu MS-Windows darf aber davon ausgegangen werden, dass das zugrunde liegende System stabil ist, und die Fehler in den Anwendungen zu beheben sind, ohne vorher ein Vertraulichkeitsvereinbarung mit Microsoft abzuschließen. Während die neuesten Versionen der Office-Pakete zum Teil schon sehr stabil laufen, fällt doch zugleich ihre lange Ladezeit auf. Sind die Festplattenzugriffe zu langsam oder die Applikationen unter Linux einfach größer? Letzteres dürfte wohl zutreffend sein. MS-Windows stellt Anwendungen vielfältige Dienste zur Verfügung. Angefangen von grundlegenden Dingen wie Bibliotheken zum Erstellen von Benutzeroberflächen und einer abstrakten Druckerschnittstelle bis hin zu Drag&Drop und Bibliotheken zum Verwalten und Speichern von Verbunddokumenten. Über die Qualität der Implementierung dieser Bibliotheken lässt sich streiten, aber da sie vom System bereitgestellt werden, müssen sie nicht im Applikationscode enthalten sein. Zudem lässt sich sehr gut definieren, wie ein MS-Windows auszusehen hat, da niemand außer Microsoft ein solches zusammenstellt. Linux hingegen gibt es in vielen verschiedenen Geschmacksrichtungen. Das ist an sich ja recht wünschenswert, allerdings haben die Hersteller es bisher nicht geschafft, sich in zentralen Fragen wie dem Aufbau des Dateisystems und der Lage von Konfigurationsdateien einig zu werden, obgleich eine solche Initiative zur Zeit im Gange ist. Somit stehen kommerzielle Office-Pakete ziemlich im Nebel. Sie müssen nicht nur grundlegende Dinge selbst implementieren - etwa das Zeichnen eines simplen Knopfes - sondern auch auf den unterschiedlichsten Linux-Konfigurationen zurecht kommen. Es mag vielleicht überraschen, dass das beschriebene Problem vornehmlich bei kommerziellen Programmen auftritt, die den Quelltext nicht preisgeben. Ist der Quelltext erhältlich, so übernehmen die Linux-Distributoren die Arbeit, das Programm an die eigene Distribution anzupassen, so dass es sich problemlos installieren und starten lässt.
Warum muss eine Büroanwendung selbst das Zeichnen eines einfachen Knopfes selbst implementieren? Die Entwickler von X11 - dem unter Unix üblichen Fenstersystem - wollten sich nicht darauf festlegen, wie ein solcher Knopf auszusehen habe, und entwickelten ein sehr abstraktes Fenstersystem. Das Zeichnen eines Buttons oder eines Menüs wurde an weitere Bibliotheken delegiert. Leider konnte man sich auf keine einheitliche einigen. Die bisher gängigste Bibliothek heißt Motif. Dieses Monster ist nicht nur langsam und schwer zu programmieren, sondern alleine der Besitz ist kostenpflichtig. Und was würde ein freies Betriebssystem mit kostenloser Büroanwendung nutzen, wenn für eine solche Bibliothek dreistellige DEM-Beträge den Besitzer wechseln müssten? Um dem zu entgehen wird die Bibliothek mit der Anwendung untrennbar zusammengefügt oder es kommt eine Eigenentwicklung zum Einsatz. Das Resultat ist einerseits enormer Speicherhunger. Da Produkte unterschiedlicher Hersteller jedesmal eine Kopie einer solchen Bibliothek mitschleppen, wird diese nicht von allen Anwendungen gemeinsam genutzt. Das verschlingt natürlich mächtig Speicher und verlangsamt das Startup. Zum anderen unterscheidet sich das Look&Feel aller Anwendungen sehr. Was soll ein Benutzer von einer Oberfläche halten, auf der sich drei verschiedene Scrollbars tummeln, die nicht nur verschieden aussehen, sondern auch noch unterschiedlich zu bedienen sind?
Ein weiteres Problem ist Skripting. Manche kommerziellen Produkte bringen eine eigene Skriptsprache mit. An sich ist es ja erfreulich, dass die Programme überhaupt Skripting anbieten, aber leider kocht auch hier ein jeder sein eigenes Süppchen. Das applikationsübergreifende Skripting, wie etwa unter MS-Windows mit Visual Basic mölich, ist ausgerechnet unter Unix, dem System für das die meisten Skriptsprachen entwickelt wurden, nicht möglich.
Und wie sieht es mit der Erweiterbarkeit der verfügbaren Büroanwendungen aus? Selbst unter MS-Windows kann ein Entwickler - wenn er sich denn von OLE und COM nicht abschrecken lässt - neue Komponenten entwickeln und in seine Office-Applikationen einbauen. Unter Unix: Fehlanzeige.
Das Erscheinen kommerzieller Software für Linux ist sicherlich eine sehr gute Sache und auch zwingend notwendig, damit es so erfolgreich wird, wie es sich seine Schöpfer wünschen. Man darf jedoch nicht vermuten, dass kommerzielle Hersteller grundlegende Designfehler beheben helfen oder der Gemeinde der Entwickler freier Software neue Technik zur Verfügung stellen. Zwar passiert auch das von Zeit zu Zeit, aber warum sollte man beispielsweise den Code zum Ansteuern der Drucker freigeben und damit der Konkurrenz eine monatelange Entwicklung ersparen? Zur Zeit werden immer noch sehr viele Pakete von MS-Windows auf Linux portiert. Bei der Portierung wird vorhandene Technik genutzt. Dort wo Linux Lücken im Vergleich zu MS-Windows lässt, werden sie entweder mit einer eigenen Lösung notdürftig gefüllt, oder das fragliche Feature entfällt ganz. Leider gilt der Umkehrschluss in aller Regel nicht. Das heißt, dass die Vorteile, die Linux gegenüber anderen Systemen hat, leider nicht genutzt werden, da die Software nicht grundlegend auf Linux zugeschnitten wurde. Das legt also nahe, dass es die Aufgabe der freien Entwickler ist, Software zu schreiben, welche auch die Stärken von Linux zu nutzen weiß. Gleichzeitig lassen sich dann auch die oben erwähnten Lücken ein für allemal schließen. Damit wird die Messlatte angehoben, und es ist zu erwarten, dass die kommerziellen Hersteller nicht zurückstehen und die neuen Techniken ebenfalls einsetzen werden.
Wie anfangs schon erwähnt, ist KDE der zur Zeit erfolgreichste Desktop für Linux. Was liegt also näher, als eine Office-Suite auf Basis von KDE zu entwickeln. Viele der oben aufgeführten Kritikpunkte entfallen damit. Zum Beispiel nutzt KOffice die Bibliotheken mit den restlichen KDE-Anwendungen gemeinsam. Das reduziert den Speicherhunger enorm und ermöglicht ein schnelleres Starten des Office-Paketes. Zudem gliedert sich KOffice hervorragend in das Look&Feel des Desktops ein. Auch das Problem des Druckens wird schon von KDE und der Qt-Bibliothek gelöst.
Eine weitere Technik, die sich KOffice mit KDE teilt, ist KOM. Dabei handelt es sich um ein auf CORBA basierendes Komponentenmodell, welches es ermöglicht, dass Anwendungen miteinander kommunizieren können. Spezielle Mechanismen wie Signals&Slots und Events ermöglichen das Zusammenstöpseln von unabhängig voneinander entwickelten Bausteinen zur Laufzeit.
Anstatt beispielsweise jeder Anwendung das Verschicken von E-Mail beizubringen, verwendet eine KOM-Applikationen einfach eine der installierten Mail-Komponenten. Das gibt dem Anwender die Möglichkeit, stets den Mail-Client einzusetzen, der ihm am besten gefällt. Die grundlegende Idee ist also, dass der Anwender sich einen Satz von Komponenten zusammensucht und installiert. Die Aufgabe von KOM ist es dann, diese Komponenten so miteinander zu verbinden, dass der Anwender das Gefühl hat, es mit einer Applikation aus einem Guss zu tun zu haben, die speziell auf seine Wünsche hin maßgeschneidert wurde.
KOM hat mit grafischen Oberflächen nichts zu tun. Es kümmert sich lediglich um die Kommunikation zwischen den einzelnen Bausteinen. Ein OpenPart ist nun nichts anderes als eine KOM-konforme Komponente mit einer visuellen Repräsentation. Eine der wichtigsten Eigenschaften der OpenParts ist das Einbetten einer Komponente in eine andere. Zum Beispiel kann der Dateimanager des in Entwicklung befindlichen KDE 2.0 einen Image-Viewer einbetten, wenn er selbst mit dem Format nicht zurechtkommt. Für den Anwender sieht es hingegen so aus, als wäre der Image-Viewer integraler Bestandteil des Dateimanagers, zumal er in dessen Fenster erscheint und auch dessen Menüzeile benutzt.
Genau diese Funktionalität wird aber auch in einer Office-Suite benötigt. Wird beispielsweise eine Tabelle in ein Textdokument eingebettet, dann sollte es doch möglich sein, die Tabelle an Ort und Stelle - also innerhalb des Textdokumentes - zu editieren. Das wird auch Inplace-Editing genannt. Aktiviert der Anwender die Tabelle, so sollten sich Toolbars und die Menüzeile so anpassen, dass das Editieren der Tabelle möglich wird. All das und noch einiges mehr ist Aufgabe der OpenParts-Bibliothek.
Da der Quelltext für KOffice frei verfügbar ist, ergeben sich noch weitere Vorteile. Zum einen kann ein jeder KOffice an seine speziellen Bedürfnisse anpassen, und zum anderen kann man KOffice auf verschiedenen Plattformen übersetzen. Linux selbst ist mittlerweile auf vielen Hardware-Architekturen zu Hause. Allerdings unterstützen die kommerziellen Hersteller meist nur die Intel-Version. Besitzer einer unter Linux laufenden Alpha- oder PowerPC-Maschine schauen derweilen in die sprichwörtliche Röhre. Kommerzielle Unternehmen werden jede Plattform unterstützen, die eine entsprechende Zahl potentieller Anwender aufzuweisen hat. Aber wie soll man erstmal tausende Anwender dazu bringen, etwa einen Alpha-PC zu kaufen, wenn es dafür noch keine Software gibt? Ein Teufelskreis entsteht, an dessen Ende das Wintel-Konsortium sich über neue Kunden freut.
Die Verfügbarkeit der Sourcen gibt aber auch Sicherheit. Wer kann im schnelllebigen EDV-Markt schon vorhersagen, welcher Hersteller sein Produkt in einem Jahr auf welcher Plattform anbietet? Hat man den Quelltext zur Hand, so kann man sich zumindest sicher sein, dass die eingesetzte Software auch in zwei Jahren noch einsetzbar ist.
Wer hat sich bei den großen Office-Paketen nicht schon einmal gewünscht, einzelne Komponenten auszutauschen oder zusätzliche installieren zu können? Aber die Bürolösungen sind wie große monolithische Blöcke. Da lässt sich nicht so auf die Schnelle die Komponente zum Anzeigen von Diagrammen durch eine bessere austauschen oder durch ein Plug-in ein neuer Grafikfilter installieren. Entwickler haben leider wenige bis gar keine Möglichkeiten, mit den Bordmitteln ihres Linux-Systems bewaffnet, Erweiterungen und Ergänzungen zu entwickeln.
Gerade aber das ist das Ziel von KOffice. Das Office-Paket für KDE wird mit der Zielsetzung entwickelt, so modular und erweiterbar wie nur irgend möglich zu sein. Erweiterbar heißt in diesem Zusammenhang aber nicht, dass man - bewaffnet mit Emacs, egcs und gdb - am Quelltext von KOffice basteln muss, um KOffice eine neue Komponente hinzuzufügen. Denn spätestens nach der nächsten Release des Paketes wären diese Änderungen von neuem anzubringen. Auf die Dauer kann es ziemlich lästig werden, wenn ein Entwickler zusätzlich zum eigentlichen Entwicklungsstrang eine modifizierte Version eines Programms weiterentwickeln wollte.
Aber vor allem ist es dem Anwender nicht zuzumuten, dass er sich für den PNG-Import-Filter und die Charting-Engine mit logarithmischer Achsenskalierung den Patch koffice230899 und koffice250999 installieren, danach in den Zeilen 1464 und 1687 ein paar Änderungen einfügen und das Ganze dann auch noch compilieren muss. Das mag vielleicht gestandene Entwickler mit schnellen Rechnern begeistern, aber der durchschnittliche Anwender wäre völlig überfordert.
Deshalb treibt die KOffice-Architektur einen nicht zu unterschätzenden technischen Aufwand, um das Installieren von Komponenten und Plug-ins zum Kinderspiel werden zu lassen. Zum Einsatz kommt dabei CORBA, eine Technik für verteilte Objekte, die einigen Informatikstudenten sicherlich schon während ihres Studiums begegnet ist. KOffice besteht aus einer Menge von Komponenten, wie etwa KSpread, KPresenter, KIllustrator und KWord. Hinzu kommen Plug-ins für alle Lebenslagen. Rechtschreibkorrektur, Taschenrechner mit Anbindung an die Tabellenkalkulation oder der KOffice-Makro-Rekorder sind als Plug-ins realisiert. Sogar die einzelnen Import- und Export-Filter sind als Plug-ins implementiert, so dass sich neue Filter im Handumdrehen installieren lassen.
Und was passiert nun, wenn der Systemadministrator gleich mehrere Komponenten für denselben Zweck installiert hat? KOffice erlaubt es dem Benutzer, die einzelnen Bausteine mit Noten zu versehen. Über einen Dienstvermittler sucht sich KOffice dann immer die Komponenten heraus, die der Anwender bevorzugt. Auch hier kommt wieder KDE-Technik zur Anwendung. Sowohl die CORBA-Bibliothek (MICO), welche KOffice benutzt, als auch der Dienstvermittler werden auch von anderen KDE-Anwendungen benutzt. In der Tat wurden CORBA und der Trader (Dienstvermittler) zuerst in KOffice erprobt und dann in KDE integriert. Das unterstreicht die These, dass ein freies Office-Paket im Gegensatz zu einem kommerziellen auch Linux im Allgemeinen weiterhilft.
Was wäre Unix ohne seine zahlreichen Skriptsprachen. Fast jede Aufgabe lässt sich damit automatisieren. Jede? Leider doch nicht jede. Schreiben Sie doch mal ein Skript, welches eine Anfrage bei Ihrer Datenbank macht, um säumige Kunden herauszufinden. Dann soll das Skript die Textverarbeitung fernsteuern, um eine Mahnung aufzusetzen und das Ganze ausdrucken. Ein solches Kunststück gelingt höchstens mit Hilfe der in das Office-Paket integrierten Skripsprache. Aber diese Lösung lässt sich nur denkbar schlecht von einem Cron-Job aus starten.
KOffice macht auch das möglich. Es offeriert seine komplette Funktionalität via CORBA. Eine CORBA-Anbindung für Python und TCL erlaubt es damit, die Office-Komponenten von einem Skript aus fernzusteuern. Da KOffice eine strikte Trennung zwischen Dokument und Ansicht durchhält, wäre obige Aufgabe sogar zu bewältigen, ohne dass auch nur ein einziges Fenster auf dem Bildschirm erscheinen müsste.
Microsoft hat uns vorgeführt, wie so etwas harmloses wie etwa ein Dateiformat als wirkungsvolle Waffe einzusetzen ist. Das Einlesen oder Erzeugen eines zu MS-Office kompatiblen Dokumentes ist wohl die Fortsetzung der Alchemie mit neuen Mitteln. Bei MS-Office soll es zuweilen sogar vorkommen, dass besagtes Produkt seine eigenen Dateien nicht mehr lesen kann oder ohne erkennbaren Grund dasselbe Dokument einmal so und das nächste mal anders speichert. Wie schön wäre es doch, wenn man mit einem einfachen Skript ein Textdokument oder eine Tabelle generieren könnte, das sich dann problemlos von der Büroanwendung öffnen ließe. Und so mancher EDV-Verantwortliche wird schon an der Aufgabe verzweifelt sein, eine Menge von MS-Word-Dokumenten zu analysieren und nach Überschrift indiziert in eine Datenbank einzuspeisen. KOffice benutzt als Dateiformat XML. Für diese vom WWW-Konsortium standardisierte Sprache existieren eine Menge Parser für alle Sprachen von Python über Perl bis Java und C++. Das Einlesen und Generieren von KOffice-Dokumenten wird damit fast zum Kinderspiel.
Für KOffice existieren schon eine Menge brauchbarer Komponenten:
Eine weitere KOffice-Entwicklung ist KoShell. Dieses relativ kleine Programm demonstriert anschaulich die Flexibilität des KOffice-Designs. Es packt, vergleichbar mit StarOffice, alle KOffice-Komponenten unter eine Benutzerschnittstelle. Dazu benötigt es erstaunlich wenig Code. Da KDE und KOffice auf demselben Komponenten-Modell aufbauen, ist auch das Einbetten des KDE-Dateimanagers kein Problem. Damit verfügt KoShell über die wichtigsten Office-Anwendungen, erlaubt das Browsen des WWW und das Verwalten des Dateisystems und benötigt dazu weniger als tausend Zeilen Quelltext.
Obwohl KOffice im Ganzen noch im Alpha-Stadium steckt, ist es dennoch schon erstaunlich gut einsetzbar. KPresenter wurde schon auf einigen Konferenzen eingesetzt, KSpread diente schon zur Erstellung einer Inventur, und mit KWord lassen sich schon ganz anständige Briefe schreiben. Für den Endanwender ist KOffice sicherlich noch nicht zu gebrauchen, aber das Beta-Stadium ist nicht mehr weit entfernt, und erfahrungsgemäß laufen einige Beta-Versionen freier Software besser als die Endfassungen manch kostspieliger Produkte.
Während die meisten Komponenten schon über die nötige Grundfunktionalität verfügen, liegt der Schwerpunkt der Entwicklung zur Zeit auf der Einbindung weiterer Features, höherer Stabilität und Import-/Export-Filtern. Besonders das Importieren von Microsoft-Dokumenten ist sehr kompliziert. Eine erste Version zum Lesen von MS-Word-Dokumenten in KWord ist allerdings schon in Arbeit, gefolgt von einem RTF- und FrameMaker-Filter. Ansonsten versteht KOffice sich mit reinen ASCII-Formaten, HTML und natürlich mit dem eigenen XML-Format.
Wer schon immer mal an einer Office-Suite herumbasteln wollte, ist natürlich herzlich zur Mitarbeit eingeladen. Es werden nicht nur Programmierer benötigt. Auch eher künstlerich veranlagte Mitmenschen werden ebenso dringend benötigt wie Dokumentationsschreiber. Schließlich geht es bei freier Software nicht ums Schmarotzen kostenloser Software, sondern ums Mitmachen.