Viele neue Features in KDE 4 setzen direkt auf spezifische Funktionen der QT-Version 4 auf. Dieser Artikel zeigt am Beispiel des Plasma-Desktops, des Dateimanagers Dolphin und der KOffice-Suite, wie die Kooperation des GUI-Toolkits und der Desktop-Umgebung in vierter Generation ausfällt.

Eine der zentralen Änderungen in KDE 4, die viel Zeit in Anspruch genommen hat, ist der Port auf QT 4 [1]. Hinter den Kulissen ist aber noch mehr passiert. Von Anfang an am objektorientierten Paradigma ausgerichtet, lag im KDE-Projekt der Fokus immer auf Architekturdesign. Die Umstellungen des von Ohloh.net mit fast 1700 Personenjahren Entwicklungsaufwand bewerteten Projekts kosteten daher viel Zeit.

Dies ist auch einer der Gründe, warum der Wechsel auf die neue QT-Version erst etwa zwei Jahre nach deren Erscheinen erfolgt. KDE 3 war lange Zeit die Branch, die das Interesse von Desktop- und Anwendungsentwicklern an sich zog. Beide wollten verständlicherweise für die KDE-Version entwickeln, bei der ihre Neuerungen auch beim Benutzer ankamen. Der Preis dafür war, dass sie auf neue Features wie SVG-basiertes Rendering oder andere Neuerungen in QT 4 verzichten mussten. Im Laufe der Zeit allerdings wurde der technische Abstand zwischen der neueren, QT-4-basierten Plattform und KDE 3 dann immer größer (Abbildung 1).

Abbildung 1: Genuss ohne Reue: Auf der Basis von QT 4 gibt es in KDE 4 Kantenglättung und Desktopeffekte, die die CPU nicht mehr über Gebühr belasten.

Was der Nutzer von einer neuen KDE-Version erwartet, mag im Detail umstritten sein. Geschwindigkeit, das Vorhandensein leistungsfähiger Anwendungen, das Aussehen und eine ergonomische Bedienung gehören aber sicherlich dazu. Gelohnt hat sich das Redesign also nur, wenn KDE 4 hier punktet.

Tuning-Kit

Üblicherweise werden Softwarepakete mit jeder Version größer und schwerfälliger. Beim Sprung von KDE 3 auf KDE 4 ist dies jedoch nicht der Fall. Speicherbedarf und CPU-Belastung sind sogar spürbar zurückgegangen. Dies ist zum größten Teil auf QT 4 zurückzuführen.

Zum einen hat Trolltech die Innereien von QT umfassend profilert – Q-Objects brauchen weniger Speicher, Signal-Slot-Verbindungen weniger CPU-Operationen, Widgets malen schneller auf dem Bildschirm und so weiter. Da diese Elemente das Einmaleins jeder QT-Anwendung sind, haben sie großen Einfluss auf die Gesamtperformanz.

Zum anderen ist der Leistungsumfang der GUI-Bibliothek gewachsen. Sie unterstützt jetzt Model-View-Programmierung, ist wesentlich Thread-sicherer, bietet mehr Widgets und mehr Tool-Bibliotheken. Daher wird die Codebasis von KDE 4 schmaler, die Module lassen sich leichter pflegen. Beispielsweise bietet QT 4 Zeichenoperationen, die Transparenz berücksichtigen. Eine der großen Herausforderungen für die Entwickler unter KDE 3 entfällt damit.

Zugegebenermaßen ist auch ein gegenläufiger Effekt zu verzeichnen: Da das Zeichnen mit Transparenz nun wesentlich leichter geworden ist, nutzen es die Entwickler auch häufiger. So nimmt zum Beispiel die Zahl der zum Hintergrund hin ausgeblendeten Elemente mit KDE 4 stark zu. Zugunsten einer ansprechenden Optik geht so der Performance-Vorteil zu einem guten Teil wieder verloren. Immerhin steigt der Ressourcenverbrauch nicht, die aufpolierte Optik setzt nicht die neueste und schnellste Hardware voraus, im Vergleich mit Windows Vista bleibt die Performance auf schwachen PCs also akzeptabel.

Zeichenoperationen sind jedoch nur ein Aspekt der Veränderungen an der Schnittstelle zwischen den KDE-Bibliotheken und den Anwendungen. Die zahlreichen Neuerungen betreffen viele Aspekte und lassen sich daher nur schwer zusammenfassend beschreiben. Dieser Artikel stellt daher einige prominente Beispiele vor.

Daten im Griff

Auf den ersten Blick haben Veränderungen in den Anwendungen oft bestenfalls indirekt mit dem neueren Toolkit zu tun. Dies gilt zum Beispiel für die Entscheidung, den kombinierten Dateimanager und Browser Konqueror in zwei eigenständige Anwendungen aufzuspalten. Das geschah vorwiegend infolge der Überlegung, dass im Dateisystem und im Web browsen unterschiedliche Tätigkeiten sind, die sich besser mit zwei eigenständigen Anwendungen erledigen lassen. Die Änderungen unter der Haube stehen dann aber doch wieder in Zusammenhang mit QT 4 – so hat Dolphin (Abbildung 2) eine effiziente Model-View-Architektur für den Zugriff auf die (virtuellen) Dateisysteme, die auf QTs Interview-Klassen aufbaut.

Abbildung 2: Getrennte Wege: Der Dateimanager in KDE 4 heißt Dolphin, Konqueror ist ab sofort nur noch für das Browsen im Web zuständig.

Die Verschmelzung von Modelldaten und Benutzeroberfläche war ein typisches Design-Manko des KDE-2- und KDE-3-Zeitalters. Nicht selten war die gesamte Programmlogik um ein »KMainWindow«-Objekt gestrickt. Dieser Ansatz hat nicht nur den Nachteil, dass der Code schnell unübersichtlich wird. Er führt außerdem dazu, dass es nahezu unmöglich ist, Teile der Programmlogik unabhängig von den GUI-Operationen automatisch zu testen.

Das Model-View-Framework Interview in QT 4 motiviert nun Entwickler dazu, ihr Datenmodell strikt von der Benutzeroberfläche zu trennen. Ein angenehmer Nebeneffekt ist erneut eine verbesserte Performance. Das liegt daran, dass Model-Daten für die Darstellung einer anderen Ansicht lediglich referenziert, nicht mehr kopiert werden müssen.

Breite Basis

Eine Neuerung, die bereits öfter die Gemüter erhitzt hat, ist die Webengine in KDE. Heute setzt Konqueror ausschließlich KHTML ein. Mit QT 4.4 wird jedoch der HTML-Renderer Webkit als Bestandteil von QT verfügbar sein. Webkit ist sozusagen das erwachsen gewordene Kind von KHTML. Die Engine liegt auch Apples Browser Safari zugrunde. Die Beziehungen zwischen Vater und Sprössling waren von Hochs und Tiefs geprägt, haben sich aber in letzter Zeit gebessert. Konqueror zumindest wird in der Lage sein, beide Engines einzusetzen.

Die Entscheidung, welche standardmäßig zum Einsatz kommt, ist offiziell noch offen und liegt letztlich in der Hand der Distributoren. Die Entwicklung von KHTML geriet für das KDE-Team deshalb so sehr zu einer Herausforderung, weil stets sie den Schwarzen Peter zugeschoben bekamen, wenn Konqueror eine Seite nicht richtig anzeigte. Webstandards entwickeln sich jedoch ständig weiter, allzu viele Seiten ignorieren sie zudem von vornherein. Mit Webkit steht nun eine Engine bereit, hinter der eine viele größere Nutzerbasis steht. Sie bringt damit mehr Gewicht auf die Waagschale, um Webdesigner zu motivieren ihre Seiten mit ihr zu testen.

All inclusive

KOffice, dessen KDE-4-basierte Version bald nach KDE 4 final erscheinen soll, setzt auf QTs Richtext-Layout-Engine Scribe. Sie stellt bereits die meisten Funktionen, die eine Textverarbeitung für die Anzeige braucht, zur Verfügung. Dass dies hilft, den Codeumfang von KOffice zu reduzieren, liegt auf der Hand. Als Nebeneffekt fällt auch noch die Unterstützung für von rechts nach links laufenden Text ab.

Auch der Umstieg vom KDE-eigenen Kommunikationsprotokoll DCOP auf D-Bus, einem von Freedesktop.org initiierten Desktop-übergreifenden Standard, hängt direkt mit QT 4 zusammen. Über D-Bus können sowohl Anwendungen, die zu anderen Desktop-Umgebungen gehören, als auch Desktop-unabhängige Dienste wie der Druckerspooler mit KDE-Programmen kommunizieren.

Bis die Mehrzahl der Anwendungen auf KDE 4 portiert ist, liegt noch viel Arbeit vor den Entwicklern. Denn schließlich ist die neue Plattform erst seit kurzer Zeit im Feature Freeze und damit eindeutig festgelegt. Dennoch hat die Portierung entweder schon begonnen oder die Entwickler stehen in den Startlöchern. Da jedoch die neue Plattform mit ihrem Design zu einer sauberen Umsetzung der Anwendungen anregt, sollte sich die Wartezeit für die Benutzer auszahlen.

Das sieht gut aus!

Das User-Interface von KDE 4 wird sich gegenüber KDE 3 wesentlich verändern. Hier besteht ein sehr enger Zusammenhang mit den Fähigkeiten des GUI-Toolkits. Bisher gab es zwei grundlegende Verfahren, um grafische Elemente auf dem Bildschirm darzustellen: Entweder die Software zeichnet sie elementweise selbst. Dann bestimmt der Funktionsumfang der Paint-Engine des Toolkits, was möglich ist. Oder die Anwendung platziert vorher entworfene Grafiken in einem Stück auf dem Bildschirm. Dann hängt die Qualität hauptsächlich vom Können des Designers ab.

Beide Wege haben ihre Berechtigung: Bei dynamischen Elementen behält der Programmierer genauere Kontrolle darüber, was dargestellt wird. In vorgefertigte Kontrollelemente fließt dagegen das Können von Designern ein. QT 4 bietet einen Weg, um die Vorteile beider Verfahren zu vereinen: Die neue Paint-Engine Arthur setzt SVG-Grafiken ein, die Designer mit ihren Zeichenprogrammen erstellen, ohne den Programmcode der Anwendung verstehen zu müssen. Die Grafiken müssen lediglich Elemente, die die Programmierer später einzeln manipulieren möchten, durch Layer trennen.

Malers Kunst

Da SVG-Grafiken ein offen dokumentiertes XML-Format nutzen, lassen sich die Grafiken nicht nur einfach als Ganzes darstellen. Die Software kann sie auch parsen und einzelne Elemente verändern. Praktischerweise liefert QT 4 sowohl Module für die Verarbeitung von XML als auch einen Renderer für SVG-Objekte mit. So passt der Programmierer zum Beispiel Text innerhalb einer Grafik an. Das Layout des Grafikers, zum Beispiel der Schlagschatten des Textes, bleibt dabei erhalten.

Besonders die Plasmoids, also die grafischen Desktopelemente, die der Nutzer frei platzieren kann und die unterschiedlichste Daten visualisieren, nutzen diese Verfahren. Bisher existieren unter anderem Plasmoids für analoge oder digitale Uhren, zum Ankündigen neuer E-Mails oder für die Batteriestandanzeige.

Alle Plasmoids arbeiten nach dem gleichen Prinzip: Eine SVG-Grafik legt die Grundstruktur fest. Darin gibt es XML-Elemente, die der Programmierer anhand ihrer ID referenziert (Listing 1, zum Beispiel die Zeilen 2, 9 und 19). Beim Digitaluhr-Plasmoid müssen sich die Ziffernfelder der Zeitanzeige verändern. Dazu sind die Ziffern von 0 bis 9 in der SVG-Datei abgelegt. Der C++-Code, der die in der Grafikdatei abgelegten Ziffern referenziert, fällt dank QT 4 einfach aus (Listing 2).

01 <g
02        id="e1-p1"
03        inkscape:label="#g5384">
04       <rect
05          y="27.726421"
06          x="-484.36288"
07          height="19.178221"
08          width="25.970121"
09          id="rect4125"
10          style="opacity:1;fill:#242424;fill-opacity:1;stroke:#000000;strokestroke-linecap:-width:0.60
000002;round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:1.0877
9998;stroke-opacity:1" />
11       <path
12          style="font-size:39.04310608px;font-style:normal;font-weight:normal;line-height:125%;opac
ity:1;fill:#d7d7d7;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:
miter;stroke-opacity:1;font-family:Liberation Sans"
13          d="M -421.3125,43.9375 C -421.56939,46.052991 -422.35575,47.528842 -423.625,48.375 C
-424.87917,49.221212 -426.992,49.625026 -429.96875,49.625 L -430.28125,49.625 L -430.28125,54.1875 L
-422.53125,54.1875 L -422.53125,59.28125 L -416.09375,59.28125 L -416.09375,43.9375 L -421.3125,43.9375 z "
14          transform="translate(-50.642093,-12.384679)"
15          id="path4161" />
16     </g>

01     // 10-hours-digit
02     m_theme->paint(p, QRectF(leftOffset, upperElementTop, elWidth, elHeight), 'e'+hours[0]+"-p1");
03     m_theme->paint(p, QRectF(leftOffset, bottomElementTop, elWidth, elHeight), 'e'+hours[0]+"-p2");
04 
05     // 1-hour-digit
06     leftOffset = leftOffset + elWidth + elHorizontalSpacing;
07     m_theme->paint(p, QRectF(leftOffset, upperElementTop, elWidth, elHeight), 'e'+hours[1]+"-p1");
08     m_theme->paint(p, QRectF(leftOffset, bottomElementTop, elWidth, elHeight), 'e'+hours[1]+"-p2");
09 
10     // 10-minutes-digit
11     leftOffset = leftOffset + elWidth + elHorizontalSpacing*4; // There's a gap between hours and minutes
12     m_theme->paint(p, QRectF(leftOffset, upperElementTop, elWidth, elHeight), 'e'+minutes[0]+"-p1");
13     m_theme->paint(p, QRectF(leftOffset, bottomElementTop, elWidth, elHeight), 'e'+minutes[0]+"-p2");
14 
15     // 1-minute-digit
16     leftOffset = leftOffset + elWidth + elHorizontalSpacing;
17     m_theme->paint(p, QRectF(leftOffset, upperElementTop, elWidth, elHeight), 'e'+minutes[1]+"-p1");
18     m_theme->paint(p, QRectF(leftOffset, bottomElementTop, elWidth, elHeight), 'e'+minutes[1]+"-p2");

Das neue Zeichenverfahren ermöglicht es, die grafische Gestalt einer Anwendung in einem Stück zu entwerfen, ohne sie laufend neu kompilieren zu müssen. Das vereinfacht die Zusammenarbeit der bisher zu wenig kommunizierenden Artists- und Programmierer-Communitys. Außer SVG-Grafiken bietet QT 4 noch weitere Features, ohne die der Plasma-Desktop nicht denkbar wäre: Das »QGraphicsView«-API projiziert 2D-Szenen perspektivisch. Wichtig für die neue Optik sind auch Transformationen mit Antialiasing, also der Glättung des Treppeneffekts bei schräg verlaufenden Linien.

Abbildung 3: Neuer Look: Die Plasmoids genannten Desktop-Elemente, zum Beispiel die Uhren im Bild, basieren auf SVG-Grafiken, deren XML-Code die Software on the Fly verändert.

Festgefügtes Team

Zwischen den Neuerungen von KDE 4 und QT 4 besteht ein enger Zusammenhang, er durchzieht nahezu alle Bereiche von der Architektur des Desktopsystems über das Design einzelner Anwendungen bis hin zu konkreten Features. Ein Vorteil für KDE ist, das nicht die KDE-Community die Ressourcen für die Pflege des GUI-Toolkits aufbringen muss. Dass die Zusammenarbeit zwischen den KDE-Entwicklern und Trolltech gut klappt und auch beide Seiten am Austausch interessiert sind, zeigt sich schon an der Präsenz der QT-Entwickler auf den KDE-Entwicklertreffen.

Geben und nehmen

Um den Einfluss von QT auf die KDE-Entwickler zu bewerten, reicht es nicht aus, direkt vom Quellcode und den Implementierungsdetails auszugehen. Neben technischen Aspekten spielt auch Trolltechs Engagement bei Freedesktop.org, der Linux Standard Base und X.org oder bei der Entwicklung des Webkits eine große Rolle – alles gemeinsam mit der KDE-Community.

Dass QT nicht nur als freie Software vorliegt, sondern auch Gewinn erwirtschaften muss, führt dazu, dass die Entwickler auf eine zukunftsorientierte Strategie setzen. Sie liegen damit im Trend vieler anderer dual lizenzierter Softwareprojekte, die häufig zugleich zu den erfolgreichsten Open-Source-Anwendungen zählen. Vielleicht sorgt die kommerzielle Ausrichtung auch für eine bessere Kundenorientierung als bei den oft zu sehr auf Poweruser ausgerichteten freien Softwareprojekten.

Sicherlich profitiert KDE auch nicht einseitig von Trolltech. Die breite Anwenderbasis verhilft dem GUI-Toolkit aus Norwegen zu mehr Stabilität und stärkt das Vertrauen in seine Qualität. Dem Open-Source-Bereich sind auch schon viele Technologien entsprungen, die aus dem kommerziellen Umfeld heute nicht mehr wegzudenken sind – Linux selbst ist das beste Beispiel dafür. (pkr)