Die Anatomie grafischer Oberflächen

Aus Programmierersicht ist eine grafische Oberfläche eine bibliotheksartige Sammlung von Funktionen. Diese sind schichtweise angeordnet, wobei höhere Schichten selbst auf Funktionen niederer Schichten zugreifen. Die Kenntnis dieser Strukturen hilft bei der Programmierung, einen Überblick über die Vielzahl der Funktionen zu erhalten. Die Namensgebung ist in den verschiedenen Oberflächen sehr unterschiedlich. Die folgende Unterteilung ist etwas grob und die Namen sind allgemein gehalten.

Desktop
Applikation

Objektverwaltung
Grafikschicht
grafische Treiber
Betriebssystem

Unter dem Stichwort Nomenklatur werden im Folgenden die Namen der vergleichbaren Schichten der verschiedenen Oberflächen genannt. Manche Systeme versehen die Funktionen mit einem Präfix, der kennzeichnet, aus welcher Schicht sie stammt. Da dies für das Lesen der Beispielprogramme sehr hilfreich sein kann, sind diese hier angeführt.

Betriebssystem

Das Betriebssystem dient vor allem als Lieferant von Ressourcen für die Schichten der grafischen Oberfläche. So wird die Verwaltung des Speichers, des Druckers, der Tastatur oder der Maus durch das Betriebssystem erledigt. Der Einfluß des eigentlichen Betriebssystems ist unterschiedlich stark. Während bei MS-Windows die Schwächen des zugrunde liegenden MS-DOS durch die grafische Oberfläche ausgebügelt werden sollen, ist beim Macintosh das Betriebssystem auf die grafische Oberfläche hin konzipiert worden. Der Rückgriff auf das zugrunde liegende Betriebssystem ist demzufolge bei unterschiedlichen Systemen unterschiedlich zu werten. Während bei MS-Windows ein Zugriff auf MS-DOS spätestens in der Zukunft Probleme bringen wird und beim X Window System das Problem besteht, daß dieses nicht unbedingt auf einer UNIX-Basis realisiert sein muß, ist zum Beispiel beim Macintosh kein Grund zu sehen, warum man die Funktionalität des Betriebssystems nicht nutzen sollte. Als Faustregel kann man davon ausgehen, daß wenn eine Funktionalität des Betriebssystems von einer höheren Schicht angeboten wird, in jedem Falle die Verwendung der höheren Schicht Priorität haben sollte.

Nomenklatur

Unter OS/2 sind alle Aufrufe an das Betriebssystem mit dem Präfix Dos versehen. Beim Macintosh gilt die Regel, daß alle Systemaufrufe und -variablen mit einem Großbuchstaben anfangen. Der Programmierer ist dazu aufgefordert, die applikationseigenen Namen mit Kleinbuchstaben zu beginnen.

Grafische Treiber

Grafische Treiber sind eine interne Schicht der grafischen Oberflächen. Wie die Treiber in Betriebssytemen bilden sie die Verbindung zwischen der Hardware und dem System. Sie verbergen die Besonderheiten der zugrundeliegenden Grafikbausteine des Bildschirms bzw. die Ansteuerung des Druckers gegenüber dem System und bieten diesem meist einfache grafische Primitive, aus denen dann die eigentliche Grafikschicht des Systems die dem Programmierer angebotene Grafikschnittstelle zusammenstellt. Die grafischen Treiber im Gegensatz zu den Einheitentreibern nicht den Betriebssystemen untergeordnet, sondern fordern selbst Leistungen des Betriebssystem an.

Den Zugriff auf diese Schicht, der in einigen Systemen möglich ist, sollte man bei der Entwicklung von Applikationen, wenn irgend möglich, vermeiden. Man gerät zu leicht in die Abhängigkeit von Versionsänderungen oder Besonderheiten der Hardware. Beispielsweise wurde beim Atari der grafische Treiber durch die sogenannte Line-A Bibliothek realisiert. Dabei handelt es sich um CPU-Opcodes, die nicht verwendet werden, sondern eine Softwareunterbrechung (Exception) auslöst. Ihren Namen erhalten diese Opcodes dadurch, daß sie in ihrer hexadezimalen Darstellung mit einem A beginnen. Motorola hat diese exceptionauslösenden Opcodes z. B. für die Einbindung von Coprozessoren vorgesehen. Die Line-A Grafikbibliothek ist gut dokumentiert und wurde von einigen Programmierern als die Möglichkeit gefeiert, ihre grafischen Ausgaben erheblich zu beschleunigen. Da aber die einfachen Funktionen der darüberliegenden Grafikschicht mehr oder weniger nur an die Grafiktreiber direkt durchgereicht werden, ist der Geschwinigkeitsgewinn zumindest bei neueren Versionen des GEM nur gering. Dafür handelten sich diese Programme erhebliche Probleme mit neueren Grafikkarten ein, die diesen Mechanismus nicht verwenden. Schließlich unterstützte Atari bei Erscheinen des TT-Modells dieses Verfahren selbst nicht mehr. Die Konsequenzen sind leicht vorstellbar.

Grafikschicht

Die Grafikschicht stellt dem Programmierer Funktionen zur Ausgabe von grafischen Elementen und Text zur Verfügung. Sie basiert auf den grafischen Treibern. Die höheren Schichten verwenden sie, um die von ihnen verwalteten Objekte darzustellen. Ihre besondere Bedeutung liegt in der Standardisierung von Grafikausgaben. Gegenüber dem Programm werden alle Hardwareabhängigkeiten verdeckt. Damit ist die Treibervielfalt, die früher bei grafischen Applikationen mitgeliefert werden mußte, gestoppt worden. Die Grafikschicht bietet in erster Linie Funktionen zur Darstellung von Text, Linien, Rechtecken, Kreisen und Polygonen. Die geschlossenen Figuren sind gefüllt oder als Rahmenlinie verfügbar. Insgesamt sind es hauptsächlich Funktionen, die man von anderen Grafikbibliotheken her kennt. Durch die Orientierung an der Vektorgrafik ist eine Vergrößerung oder Verkleinerung leicht möglich. Ein weiterer Vorteil liegt in der Möglichkeit, höhere Auflösungen optimal unterstützen zu können. Daneben werden auch Pixelgrafiken unterstützt. Diese wird zur Darstellung von Piktogrammen benötigt. Eine weitere wichtige Funktion ist das Verschieben und Kopieren von Rechtecken, die bei Fenstermanipulationen gebraucht werden. Dazu bieten die Grafikschichten an, einen gewöhnlichen Speicherbereich als Bildschirmbereich interpretieren zu können. Neben den Zeichenfunktionen stellt die grafische Schicht Funktionen zur Einstellung der Darstellungsart zur Verfügung. Diese betreffen Linienstärke, Muster und Farbe bei grafischen Objekten oder Schriftart, Schriftstil und Größe bei Texten. Ein wichtiger Bereich sind die Anfragefunktionen. Damit sind Parameter der Grafikumgebung zu ermitteln. Hier finden sich wichtige Informationen wie die der Bildschirmdimension (bzw. Druckerauflösung), die Anzahl der verfügbaren Farben und das Größenverhältnis von X- und Y-Punkten, damit ein Quadrat immer wie ein Quadrat aussieht.

Nomenklatur

System Name der vergleichbaren Schicht Präfix
Macintosh QuickDraw
GEM Virtual Device Interface (VDI) v
MS-Windows Graphic Device Interface (GDI)
OS/2 Graphics Programming Interface Gpi
X Xlib X

Objektverwaltung

Während die Grafikschicht lediglich dafür zuständig ist, geometrische Gebilde darzustellen, befaßt sich die nächste Schicht mit der Verwaltung von Objekten wie Applikationen, Fenstern, Symbolen, Knöpfen, Menüs und anderen Elementen. Sie verwaltet also abstrakte Gebilde und bestimmt bei sichtbaren Objekten deren Aussehen. Dazu bedient sie sich der Zeichenfunktionen der Grafikschicht. In dieser Schicht werden die Applikationen und Fenster angemeldet und die Nachrichten bezüglich der diversen Ereignisse verteilt. Die Ereignisse werden empfangen, interpretiert und weitergeleitet. So empfängt diese Schicht zum Beispiel vom Betriebssystem die Interrupts, die die Maus auslöst. Bei einem Maustastenklick stellt sie die Bildschirmposition fest und prüft, welches Objekt an dieser Stelle vorliegt. War dies zum Beispiel ein Druckknopf einer Dialogbox, wird die Applikation ermittelt, die diesen Druckknopf auf den Bildschirm gebracht hat, und ihr das Ereignis, daß der Druckknopf angewählt wurde, mitgeteilt. In den meisten Fällen erfährt die Anwendung nicht, ob dieser durch die Maus oder durch die Tastatur gewählt wurde. Befinden sich zum Beispiel mehrere Fenster verschiedener Applikationen auf dem Bildschirm und ein zu unterst liegendes Fenster ist angeklickt worden, wird ein Taskwechsel ausgeführt. Die bisherige Applikation verliert die Kontrolle, das aktivierte Programm erhält eine Nachricht darüber, daß das Fenster nach vorn gekommen ist und das der Inhalt restauriert werden muß. Das Restaurieren des Rahmens wird direkt ausgelöst. An diesen Beispielen ist erkennbar, daß dies die Schicht ist, die das Herzstück einer grafischen Oberfläche bildet.

Nomenklatur

System Name der vergleichbaren Schicht Präfix
Macintosh Control Manager / Window Manager
GEM Application Environment System (AES) je nach Aufgabe
OS/2 Presentation Manager Gpi
X X Toolkit Intrinsics Xt

Unter GEM sind die Funktionen des AES nach folgenden Aufgabengebieten unterteilt:

Präfix Aufgabengebiet
appl Applikationsverwaltung
evnt Ereignisabfrage
form Dialogboxhandhabung
graf Grafikelemente des AES
menu Menüverwaltung
objc Objektzugriffe
rsrc Handhabung der Ressourcen
scrp Clipboard
wind Fensterverwaltung

Desktop

Der Desktop ist die Oberfläche, auf der alle Applikationen optisch aufsetzen. Allerdings stehen seine Funktionen dem Programmierer nicht bibliotheksartig zur Verfügung. Vielmehr handelt es sich um eine eigenständige Anwendung. Die Besonderheit des Desktops liegt darin, daß es das erste Applikationsprogramm ist, das gestartet wird und damit die grafische Oberfläche initialisiert. Ferner wird der physikalische Bildschirm mehr oder weniger deutlich als Fenster des Desktops betrachtet, in dem sämtliche Applikationen ihre Fenster quasi als Unterfenster aufbauen. In seiner Funktion als Elternprozeß aller Applikationen hat der Desktop zusätzlich eine wichtige Funktion als Kommunikationspartner der Anwendung.

Eine Sonderstellung hat der Desktop des X Window Systems, wo er Window-Manager genannt wird. Dieser übernimmt die Rahmengestaltung der Fenster, die damit nicht direkt durch das Programm beeinflußt werden kann. Da es unterschiedliche Window-Manager gibt, ist die Unterstützung der Rahmenelemente verschieden. Wegen der Austauschbarkeit des Window-Managers gibt es sogar die Möglichkeit, daß der X-Server nur ein Anwendungsprogramm eines anderen Systems ist. Für OS/2 wird ein solches Programm mit dem TCP/IP-Kommunikationspaket mitgeliefert. Dabei übernimmt der Presentation Manager die Aufgaben des Window-Managers. Damit laufen X-Window-Programme parallel zu PM-Anwendungen in einem gewöhnlichen PM-Fensterrahmen.

Bei Macintosh und GEM ist der Desktop vergleichbar mit der Shell unter UNIX. Von ihm aus werden die Programme gestartet. Zusätzlich integriert er einen Datei-Manager, mit dem die alltäglichen Arbeiten, wie Kopieren und Löschen von Dateien ausgeführt werden.

Anatomie des X Window Systems

Die Anatomie des X Window Systems unterscheidet sich an einigen Stellen nicht unerheblich von denen der anderen Oberflächen. Der Grund liegt einmal in der Netzwerkfähigkeit von X und andererseits in der Verwendung der Widget-Sets.

X-Server

Der X-Server ist ein eigenständiges Programm, das die Hardware-Abhängigkeiten eines X-Terminals verbirgt und über das X-Protokoll angesprochen wird. Dieses Protokoll kann auf einer Interprozeß-Kommunikation oder auf einem Netzwerkprotokoll basieren. Der X-Server erhält alle Anforderungen zur Ausgabe über das X-Protokoll von der Anwendung, die in diesem Zusammenhang als X-Client bezeichnet wird. Neben dem Bildschirm verwaltet der X-Server die Tastatur und die Maus. Jede der Aktionen, die von dort ausgehen, sendet der X-Server wiederum an den Client. Da alle Aktionen über das Protokoll erfolgen, kann der X-Server sowohl auf der gleichen Maschine wie der X-Client laufen oder auf einem beliebigen anderen Computer im Netzwerk. Dabei muß der X-Server nicht einmal das gleiche Betriebssystem benutzen wie der X-Client.

Xlib

Eine Anwendung unter X muß das X-Protokoll selbst gar nicht beherrschen. Typischerweise wendet es sich dazu an die Xlib. Die Xlib enthält alle Bestandteile, die zu einer normalen Grafikschicht gehören. Alle Grafikausgaben werden über das X-Protokoll an den X-Server versandt. Die Xlib verfügt aber auch über einige Objekte. So kennt die Xlib beispielsweise Fenster und Mauszeiger. Die Xlib empfängt auch die Ereignisse vom X-Server und verteilt diese bereits auf die angemeldeten Fenster. Es ist möglich, Applikationen zu schreiben, die allein auf der Xlib basieren. Ein Beispiel dafür ist xcalc, der Taschenrechner, der bei jeder X-Auslieferung zum Standardumfang gehört.

X Toolkit Intrinsics

Die Intrinsics ist eine Bibliothek, die auf der Xlib aufsetzt und die Verwaltung von Widgets übernimmt. Sie stellt selbst keinen Widget-Set zur Verfügung, sondern nur die Grundwidgets und die Grundfunktionen zur Erstellung eines Sets. Daneben verwaltet sie die Eigenschaften der Widgets und stellt dem Anwendungsprogrammierer die Funktionen zum Erzeugen, Darstellen und Entfernen von Widgets zur Verfügung. Eine besondere Aufgabe liegt in der Verwaltung der Widget-Eigenschaften, der sogenannten Ressourcen. Die Eigenschaften der Widgets, wie Farbe, Ausdehnung, Beschriftung und Ereignisauslösung, können durch frei editierbare Dateien, die sogenannten Ressourcedateien, verändert werden. Die Verwaltung dieser Einstellungen wird durch die Intrinsics übernommen.

Widget-Sets

Bei X findet der Programmierer noch eine weitere Schicht in Form der Widgets vor. Diese bestehen aus Datenstrukturen und eingebauten Funktionen. Während die Kontrollelemente bei den meisten Oberflächen eng mit dem restlichen System verknüpft sind, werden diese bei X aus einem Rechteck aufgebaut, das die in seinem Geltungsbereich auftretenden Ereignisse empfängt. Durch Zusatz von Eigenschaften wie Aussehen und Reaktion auf die Ereignisse können neue Objekte erstellt werden. Dazu erhalten diese zusätzliche Datenstrukturen, um zum Beispiel das geänderte Aussehen festzulegen, und zusätzliche Routinen, die die hinzugekommene Funktionalität realisieren. Auf diese Weise ``kennt'' jedes Widget sein Aussehen und kann es jederzeit rekonstruieren. Zu den Kontrollelementen kommen noch Management Objekte hinzu, die Kontrollelemente und untergeordnete Management Widgets nach verschiedenen Strategien anordnen. All diese Objekte werden zu einer Widgetklasse zusammengenommen und bilden die Schnittstelle des Anwendungsprogrammierers.

Zum Beispiel kann man einen Menübalken als eine Leiste von Knöpfen betrachten. Bei Drücken eines solchen Knopfes wird dann wiederum eine diesmal senkrechte Leiste erstellt, in der sich wiederum Knöpfe befinden. Natürlich kommen ein paar Besonderheiten hinzu, wie zum Beispiel die Frage, wann das Klappmenü wieder verschwindet. Aber prinzipiell ist ein Menü nicht viel mehr als die Zusammenstellung von Druckknöpfen.

Die ungeheure Flexibilität dieses Ansatzes hat mehrere solcher Objektklassen entstehen lassen. Lange Zeit schien sich OSF/Motif als Widgetklasse durchzusetzen. Es gibt daneben aber auch andere Klassen, wie etwa die Athena Widget Class, die zum Standardlieferumfang von X gehört. Ein Programm unter X basiert im Normalfall auf einer solchen Objektklasse, die damit zum wichtigen Bestandteil der Schnittstelle wird. Da aber Motif lizenzpflichtig ist, setzte es im unter Linux nie durch. Aus diesem Grund litt Linux lange unter der Unklarheit seiner grafischen API, die das Entstehen von Anwendungsprogrammen nachhaltig verzögerte. Man kann sicher sein, daß die Festlegung, die nun unter Linux getroffen wird, auch bald Standard bei anderen UNIX-Systemen sein wird.

Nomenklatur

Die Widgetklassen bestehen in erster Linie aus Datenobjekten, die nicht immer einer besonderen Nomenklatur folgen. Die von außen zugreifbaren Funktionen werden üblicherweise nach ihren Widgetklassen benannt. So haben Objekte und Funktionen des OSF/Motif den Präfix Xm und Funktionen des Athena Widget Set Das Thema Farbe bietet ein gutes Beispiel für die Verwendung der falschen Systemebene. Der Atari bietet eine XBIOS-Funktion Getrez an, die die Auflösung des Bildschirms liefert. Dabei bedeutet der Rückgabewert 0 eine Auflösung von 320 x 200 Pixel in 16 Farben, 1 eine Auflösung von 640 x 200 Pixeln in 4 Farben und 2 eine Auflösung von 640 x 400 Pixeln monochrom. Im Modus 1 verzerrt die Bildschirmausgabe, so daß ein Quadrat entsteht, wenn die Waagerechten doppelt so lang sind wie die Senkrechten. Die neueren Modelle von Atari haben inzwischen wesentlich leistungsfähigere Bildschirmmodi und selbst bei älteren Geräten ist eine Grafikerweiterung für wenig Geld erhältlich, die den Monochrommodus auf ca. 700 x 440 - je nach Leistung des Monitors - erweitert. Wendet sich das Programm an die Grafikschicht, wird es die genaue Auflösung, die Farbtiefe und das Größenverhältnis zwischen X- und Y-Achse präzise erfahren können. Entgegen der XBIOS-Routine sind diese Informationen nach wie vor für alle Geräte gültig.

Ein weiteres typisches Beispiel ist die Verwendung der MS-DOS-Funktionen zur Speicherverwaltung aus MS-Windows-Programmen. Da MS-DOS selbst nur den Speicher innerhalb der unteren 640KByte verwalten kann, stellt MS-Windows eigene Funktionen zur Verfügung, die auch auf den Rest des Speichers zugreifen kann. Damit eine vernünftige Speicherauslastung stattfinden kann, sollten die Speicheranforderungen an MS-Windows gerichtet werden. Das Vorhandensein von gleichartigen Funktionen auf verschiedenen Ebenen sollte den erfahrenen Programmierer dazu verleiten, die Funktion der höheren Ebene zu verwenden.

Der Begriff Ressourcen wird wird von den anderen Oberflächen anders belegt. Dort beschreiben die Ressourcen in erster Linie den Aufbau von Dialogboxen und Menüs.
Homepage - Inhaltsverzeichnis (C) Copyright 1993-1999 Arnold Willemer