17.9.2009

Netzwerkprodukte (28) - Userinterfaces (2)

(Themenanfang)

Wenn man sich dafür entscheidet, ein Programm mit einem grafischen Userinterface (GUI) zu schreiben, muß man deutlich mehr Zeilen Code schreiben, als für dessen Version für die Kommandozeile.

Ein ganz gutes Gefühl für das Ausmaß dieses „Mehr” bekommt man, wenn man das grundlegende Skelett einer Applikation schreibt - das klassische „Hello World”, das eben diese beiden Wörter auf den Bildschirm bringt. In reinem „C” mit einer Textausgabe auf die Konsole sind das keine zehn Zeilen Code. Wenn man die gleiche Ausgabe in ein Fenster z.B. unter Windows machen will, sind es plötzlich mehrere hundert Zeilen, in denen u.a. ein ohne das Studium umfangreicher Dokumentationen kaum nachvollziehbares Zwiegespräch mit dem Betriebssystem geführt werden muß.

Um ein wenig besser nachvollziehbar zu machen, über was für Schwierigkeiten man stolpert, wenn man ein GUI implementieren will, schildere ich kurz, wie die Verwaltung von Fenstern auf dem Desktop geschieht. Dreh- und Angelpunkt ist die sog. „Eventloop”. Die eigene Applikation übermittelt dem Betriebssystem ein Stück Code, das immer dann aufgerufen wird, wenn der User eine Aktion ausführt - wenn er die Maus bewegt, mit der rechten oder linken Maustaste klickt, Eingaben auf der Tastatur macht, aber auch, wenn ein Fenster verschoben oder geschlossen wird, so daß der Inhalt anderer, dahinter verborgener Fenster restauriert werden muß.

Das Problem ist ja, daß die gegenseitig sich verdeckenden Fenster denselben Bildschirm teilen - die Hierarchie übereinander liegender Dokumente ist lediglich eine Illusion für den User, die aufrecht erhalten wird, indem ein hinten liegendes Fenster stets auf Überlappungen Rücksicht nimmt und Ausgaben in scheinbar „verdeckte” Bereiche unterdrückt.

Jedes Betriebssystem löst dabei die Aufgabe anders, zu verhindern, daß vermeidlich verdeckte Bereiche versehentlich übermalt werden, wobei in unterschiedlichem Ausmaß die Programme an dieser Aufgabe beteiligt sind. Auf dem Atari ST war es beispielsweise den Programmierern überlassen, Überlappungen bei der Restauration von Fensterinhalten zu berücksichtigen, wobei das Betriebssystem lediglich eine Rechteckliste der neu zu zeichnenden Bereiche lieferte. Das Design des MacOS war immerhin schon ganz zu Beginn elegant genug, den Applikationen Grafikausgaben auch in eigentlich unsichtbare Bereiche zu erlauben, wobei das Betriebssystem dann verhinderte, daß solche „unzulässige” Grafik auf dem Bildschirm erschien. Usf.[1]

Das ist nur ein kleiner Teil der Aufgaben, die man lösen muß, wenn Programmausgaben nicht direkt auf dem Bildschirm, sondern in einem virtuellen Fenster erscheinen sollen. Es dürfte aber einleuchten, daß die Komplexität eines Programms, das ein GUI implementiert, erheblich größer ist als dessen Version für die Kommandozeile, obwohl es letztlich - die einfachere Bedienbarkeit außer acht gelassen - nicht mehr leistet als dieses.

Das bedeutet zunächst Dreierlei. Das Programm wird teurer, und zwar drastisch teurer, weil es schlicht länger - drastisch länger - dauert, es zu entwickeln. Zum zweiten frißt es mehr Ressourcen in Form von Rechenleistung und Speicherplatz. Außerdem ist es - drittes - deutlich anfälliger für Programmfehler, Bugs.

Viertens aber - und das ist m.E. der eigentliche Schlüssel - sind die Metaphern eines GUI oft nur begrenzt belastbar - entweder, weil das Vorbild aus der realen Welt Dinge erlaubt, die für sein virtuelles Gegenstück technisch schlicht nicht umsetzbar sind, oder aber, weil in der Realität Konzepte praktisch sind, die, auf den Computer übertragen, nur teilweise oder überhaupt nicht funktionieren.

Die Fenster auf dem Computerbildschirm lassen sich nicht - wie ein Stück Papier - falten oder zusammenrollen, und Knöpfe lassen sich an einem Radio wunderbar mit Daumen und Zeigefinger anfassen und verstellen, sind an seinem virtuellen Gegenstück mit der Maus jedoch schlicht unbedienbar.

  1. [1] Heute sieht das auf den ersten Blick sehr viel entspannter aus, weil - zumindest unter Windows und OS X - jedes Fenster einen eigenen Speicherbereich zur Verfügung hat, der bei Bedarf ohne Zutun durch die Applikation vom Betriebssystem auf den Bildschirm kopiert wird. Dabei handelt man sich andere Probleme ein - z.B. unter Windows das außerordentlich unangenehme Phänomen, daß sich urplötzlich Task-Prioritäten zugunsten des GUI verschieben, weil Windows die Restauration von Fensterinhalten wichtiger findet, als die ungestörte Wiedergabe einer Audiodatei (um nur ein beliebiges Beispiel zu nennen).
(Kommentarfunktion z.Zt. deaktiviert.)