%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                                    %
% Diplomarbeit von Sven Muessig                                      %
% angefangen am 13-okt-92                                            %
%                                                                    %
% Universitaet Hamburg                                               %
% Fachbereich Informatik                                             %
% Arbeitsbereich DBIS                                                %
%                                                                    %
% Kapitel: Kommerzielle Dienste einer speziellen Anwendungsumgebung  %
%                                                                    %
% Version vom 03-jul-94                                              %
%                                                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\cleardoublepage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Kommerzielle Dienste einer speziellen Anwendungsumgebung}
\label{Kap. Kommerzielle Dienste einer speziellen AU}

In diesem Kapitel wird eine Anwendungsumgebung mit ihren kommerziellen 
Diensten vorgestellt. Die Umgebung stellt die Entwicklungsplattform f"ur 
die in den nachfolgenden Kapiteln vorgestellten generischen Bibliotheken
dar. Die Zusammensetzung der Entwicklungsplattform ergibt sich zum einen 
aus der am Arbeitsbereich DBIS vorhandenen Hard- und Software und zum
anderen aus dem Ergebnis der Suche nach einem geeigneten 
Entwicklungswerkzeug f"ur graphische Benutzerschnittstellen in Kapitel
\ref{Kap. Entwicklungswerkzeuge fuer graphische Benutzerschnittstellen}.

Die Erstellung graphischer Benutzerschnittstellen f"ur die 
\ow-An\-wen\-dungs\-um\-ge\-bung wird durch verschiedene Werkzeuge und 
Dienste unterst"utzt. Unterschieden wird dabei zwischen \x- (\e{X Window
System Version 11}\,) und \n- (\e{Network extensible Window System}\,) 
basierten Werkzeugen. Grundlage des netzwerkf"ahigen Fenstersystems \n\ 
ist die Seitenbeschreibungssprache \ps\ und das damit verbundene, gegen"uber
\x\ m"achtigere Graphikmodell. Daraus ergeben sich eine Reihe von Vorteilen 
f"ur \n-basierte Werkzeuge. Ein spezielles Werkzeug ist das \tnt\ (\e{The
NeWS Toolkit}, TNT). Es implementiert viele Schnittstellenkomponenten der
\ol-Spezifikation f"ur graphische Benutzerschnittstellen. Dieses Kapitel
stellt alle aufgef"uhrten Dienste ausf"uhrlich vor und beschreibt deren
Zusammenspiel.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Die Seitenbeschreibungssprache PostScript}
\label{Abs. Die SBS PS}

Die Sprache \ps\ \cite{PSLRM90} ist eine von \asi\ seit 1982 entwickelte,
dynamische, kellerspeicherbasierte und interpretative 
Seitenbeschreibungssprache. Die Sprache erm"oglicht die ger"ate- und 
aufl"osungsunabh"angige Beschreibung von \e{Seiten} f"ur Ausgabeger"ate wie
Drucker oder Bildschirme. Dazu enth"alt die Sprache neben graphikspezifischen
Operatoren auch eine Reihe allgemeiner Operatoren, die \ps\ zu einer 
vielseitig verwendbaren allgemeinen Programmiersprache (\e{general purpose
programming language}\,) machen.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Graphikmodell}
\label{Abs. Graphikmodell}

Die Seitenbeschreibungssprache \ps\ basiert auf dem \e{stencil/paint imaging
model}, einem graphischen Modell, das dem Malen mit Farbe auf Papier 
nachempfunden ist. Graphiken werden in diesem Modell durch Pfadkonstruktionen,
Mal- und Transformationsfunktionen beschrieben. Durch die Beschreibung aller
auf einer Seite vorhandenen Informationen als Folge von abstrakten graphischen
Objekten wird die Unabh"angigkeit vom Ausgabeger"at und der Aufl"osung erreicht.

Graphische Objekte sind \zB\ Buchstaben, Texte, geometrische Figuren und
gerasterte Bilder. Au"ser den gerasterten Bildern sind alle graphischen
Objekte, also auch die Buchstaben der Zeichens"atze (\e{fonts}\,), aus
mathematischen Pfaden (\e{paths}\,) in ger"ateunabh"angigen 
Koordinatensystemen aufgebaut. Solche durch Pfade beschriebene Objekte
k"onnen ohne Qualit"atsverlust verschiedenen Transformationen unterzogen 
werden. Nach Ausf"uhrung aller Transformationen wird der Pfad des Objekts
mit einer Linie beliebiger St"arke im Zielkoordinatensystem des 
Ausgabeger"ats nachgezogen. Anschlie"send kann das Objekt noch wahlweise
mit unterschiedlichen Mustern in beliebigen Farben gef"ullt werden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Programmierung}
\label{Abs. Programmierung PS}

Wurde \ps\ ehemals haupts"achlich als Seitenbeschreibungssprache konzipiert,
so er\-m"og\-li\-chen die in \ps\ enthaltenen Merkmale von allgemeinen
Programmiersprachen, wie Polymorphismus, Funktionen h"oherer Ordnung und
die dynamische Erweiterbarkeit, den Einsatz von \ps\ als vollwertige 
Programmiersprache. Daneben l"a"st sich \ps\ als interaktives System 
zur Bedienung von Ausgabeger"aten einsetzen und hat sich im Graphikbereich
als Datenaustauschformat zwischen verschiedenen Anwendungsprogrammen
etabliert.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Interaktionsmodelle}

Aus der Anwendung von \ps\ ergeben sich unterschiedliche Interaktionsmodelle.
Zwei Modelle sind in Abbildung \ref{Abb. PS IM} dargestellt. Grundlegendes 
Modell ist das \e{Drucker-Modell} (\e{printer model}\,). Darauf aufbauend 
gibt es das \e{interaktive Modell} (\e{interactive programming language 
model}\,).

\begin{figure}[hbt]
  \psbild{0.8#1}{dienste}{PostScriptModell.ps}
  \caption{\ps-Interaktionsmodelle \protect\cite{PSLRM90}}
  \label{Abb. PS IM}
\end{figure}

Im Drucker-Modell werden die Seitenbeschreibungen nicht von Anwendern,
sondern von Anwendungsprogrammen, wie Text- oder Graphikprogrammen, 
automatisch erzeugt. Die Beschreibung einer Seite (\e{page description}\,)
wird komplett an ein Ausgabeger"at "ubermittelt. Der \ps-Interpreter im
Ausgabeger"at erstellt dann anhand der Befehle zum \e{Konstruieren} und 
\e{Malen} von Graphiken ein \e{ger"ateabh"angiges} Rasterbild, welches
anschlie"send ausgegeben wird.

Das interaktive Modell unterscheidet sich vom Drucker-Modell dahingehend,
da"s Daten nicht einmalig vom Anwendungsprogramm zum Ausgabeger"at, sondern
in einer Sitzung (\e{session}\,) fortw"ahrend in beiden Richtungen
"ubertragen werden. Daf"ur mu"s zun"achst eine Verbindung zwischen dem
Anwendungsprogramm und dem \ps-Interpreter im Ausgabeger"at aufgebaut werden.
In einer solchen Sitzung wird der \ps-Interpreter direkt durch die von der
Anwendung ausgegebenen Befehle angesprochen. Er f"uhrt sie sofort aus und 
gibt bei Bedarf entsprechende R"uckmeldungen an das Anwendungsprogramm. Diese 
Vorgehensweise ist nicht nur f"ur Test- und Experimentierarbeiten g"unstig.
Sie ist die Voraussetzung f"ur den Einsatz von \ps\ als Programmiersprache
f"ur Benutzerschnittstellen.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Kellerspeicher und Postfixnotation}

\ps\ ist kellerspeicherbasiert, \dh\ zur "Ubergabe und Speicherung von 
Objekten werden polymorphe Kellerspeicher (\e{stacks}\,) verwendet. Ein 
polymorpher Kellerspeicher ist ein Teil des Speichers, in dem Objekte
verschiedener Typen abgelegt und in einer LIFO-Reihenfolge (\e{last-in
first-out}\,) wieder abgerufen werden k"onnen. Daraus ergibt sich eine 
Notation (\e{postfix notation}\,), die von der in anderen 
Programmiersprachen verwendeten Infixnotation abweicht. Bei der 
Postfixnotation werden zun"achst alle Argumente auf einem Kellerspeicher
abgelegt. Erst anschlie"send wird der betreffende Operator aufgerufen.
Ein einfaches Beispiel ist die Addition zweier Zahlen:

\begin{xple}
     40 60 \k{add}
\end{xple}

Die beiden Objekte \s{40} und \s{60} werden auf dem Kellerspeicher
abgelegt. Nachdem alle Argumente f"ur den Operator \k{add} auf dem 
Kellerspeicher liegen, kann der Operator ausgef"uhrt werden. Er holt sich
die beiden Argumente vom Kellerspeicher, addiert sie und legt das Ergebnis
wieder dort ab.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Konzepte}

Alle Objekte in \ps\ haben einen Typ. Dazu gibt es ein reiches Typsystem.
Neben den von anderen Programmiersprachen her bekannten konventionellen
Datentypen gibt es in \ps\ noch weitere spezielle Datentypen, wie \zB\
W"orterb"ucher (\e{dictionaries}\,) und Dateien (\e{files}\,), sowie einen 
polymorphen Nulltyp. 

Die Sprache \ps\ stellt verschiedene Kontrollstrukturen zur Steuerung des
Pro\-gramm\-ab\-laufs zur Verf"ugung. Es gibt Operatoren zur Programmierung 
von bedingter Aus\-f"uh\-rung, typabh"angigem Verhalten, Schleifen und 
Ausnahmesituationen. Auch rekursive Programmierung ist m"oglich.

Eine Reihe von polymorphen Operatoren und Funktionen h"oherer Ordnung
erlauben die Beschreibung typunabh"angigen Verhaltens. Zum Beispiel kann
mit dem Operator \k{forall} sowohl "uber W"orterb"ucher als auch "uber 
Felder iteriert werden und mit dem Operator \k{put} k"onnen Zeichen in
einer Zeichenkette, Objekte in einem Feld sowie Paare aus Schl"ussel und
Wert in einem W"orterbuch gespeichert werden.

Weitere "uber den Umfang dieses Abschnitts hinausgehende Informationen 
sind in \cite{PSLRM90,PSLTC91,PSLPD88} und in \cite{Holz90,KiMu92} zu
finden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Das Fenstersystem NeWS}
\label{Abs. Das FS NeWS}

\n\ ist ein von \sm\ ab 1984 entwickeltes netzwerkf"ahiges Fenstersystem
\cite{NPG92,GRA89}. Es macht das m"achtige Graphikmodell der 
Seitenbeschreibungssprache \ps\ einem verteilten Fenstersystem zug"anglich.
\n\ ist unabh"angig von der verwendeten Hardware und dem Betriebssystem. 
Im Gegensatz zum nur statisch vom Anbieter erweiterbaren Fenstersystem
\x\ \cite{Jones89,DDRS92} kann die Funktionalit"at des \n\ von
Anwendungsprogrammen durch Hinzuf"ugen von Kode (\e{download}\,) dynamisch
erweitert werden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Grundbegriffe}
\label{Abs. Grundbegriffe NeWS}

In diesem Abschnitt werden die im Zusammenhang mit \n\ h"aufig verwendeten
Begriffe \e{canvas}, \e{class}, \e{process}, \e{event} und \e{package}
kurz erl"autert.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Canvas}

Ein Canvas ist eine nicht notwendigerweise rechteckige und zusammenh"angende
Fl"ache auf einem Bildschirm, in der Anwendungsprogramme Informationen
darstellen k"onnen. Solche Fl"achen k"onnen sowohl ineinander verschachtelt
sein, als sich auch "uberlappen. Durch eine hierarchische Struktur k"onnen
die Beziehungen zwischen den Ausgabefl"achen einer Anwendung abgebildet werden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Class}

\n\ stellt einen flexiblen objektorientierten Klassenmechanismus zur 
Verf"ugung. Er erlaubt die eigene Definition von Klassen und die 
Verwendung vorhandener Klassenbibliotheken, wie \zB\ des \tnts\
(\VAS\ \ref{Abs. Das NeWS Toolkit}). Es werden sowohl Einfach- als auch
Mehrfachvererbung unterst"utzt.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Process}

\n-Prozesse sind leichte Prozesse (\e{lightweight processes}\,). Sie laufen
im \xns\ ab. Die Erzeugung solcher Prozesse verbraucht wenig Ressourcen,
wie CPU-Zeit und Hauptspeicher. Alle leichten Prozesse teilen sich einen
gemeinsamen Adre"sbereich.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Event}

Ereignisse (\e{events}\,) repr"asentieren Nachrichten zwischen \n-Prozessen.
Ereignisse werden entweder durch die Interaktion eines Benutzers vom \xns\
oder durch andere \n-Prozesse generiert. Wie in Abbildung \ref{Abb. XNS} auf
Seite \pageref{Abb. XNS} zu sehen ist, werden Ereignisse \zB\ von der Tastatur
oder der Maus ausgel"ost. Die Nachrichten beinhalten Informationen "uber die
Art des Ereignisses, \zB\ Tastendruck oder Mausklick, den Ausl"oser des 
Ereignisses, \zB\ Taste \s{a} oder \s{rechte} Maustaste sowie die 
Ausl"oseposition und den Ausl"osezeitpunkt.

Ereignisse sind mit den Ausgabefl"achen von Anwendungen in einer Liste
(\e{interest list}\,) assoziiert. Alle anfallenden Ereignisse werden in 
eine globale Warteschlange (\e{event queue}\,) eingereiht. Von dieser werden
sie auf die lokalen Warteschlangen der am Ereignis interessierten
Anwendungen verteilt und dort ausgewertet.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Package}

Der Paketmechanismus (\e{package mechanism}\,) dient der Modularisierung
des Namensraums im \xns. Der Mechanismus "ahnelt dem \e{shared library}
Konzept des Betriebssystems \sos. Auf dem \n\ aufbauende Werkzeuge, wie \zB\
das \tnt, sind in externe Pakete ausgelagert. Sie m"ussen bei Bedarf explizit
hinzugeladen werden (\VAS\ \ref{Abs. Das NeWS Toolkit}).


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Programmierung}
\label{Abs. Programmierung NeWS}

Die Grundlage der \n-Sprache bildet die in Abschnitt \ref{Abs. Die SBS PS}
vorgestellte Sprache \ps. Sie wird verwendet, um Texte und Bilder auf einem
Bildschirm auszugeben. Daneben sind in der Sprache viele Erweiterungen zu
finden, die der Interaktion (Bildschirmausgaben sowie Maus- und 
Tastatureingaben) und der Mehrproze"sf"ahigkeit in einem Fenstersystem
Rechnung tragen. Die \n-Programme werden vom \xns\ interpretiert und 
ausgef"uhrt.

Es gibt zwei Programmierschnittstellen zum \n. Die eine ist das \cci,
eine \cc-Bibliothek. Die andere ist das objektorientierte \tnt, das 
im Abschnitt \ref{Abs. Das NeWS Toolkit} ausf"uhrlich beschrieben wird. 
In diesem Abschnitt wird die Funktion einiger grundlegender Operatoren
beschrieben, die notwendig sind, um Methoden aufzurufen und Daten zwischen
einem Anwendungsprogramm und dem \xns\ auszutauschen.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Modularisierung}

\n\ benutzt zur Modularisierung einen Paketmechanismus. Aus diesem Grund 
m"ussen nach einem Verbindungsaufbau zwischen Anwendungsprogramm und
\xns\ zuerst die ben"otigten Pakete, \zB\ \s{NeWS} geladen werden. In 
diesem Paket befinden sich alle \n-spezifischen Operatoren. 

\begin{xple}
    /NeWS 3 0 \k{findpackage} \k{beginpackage}
\end{xple}

Der Operator \k{findpackage} l"adt das Paket mit der gew"unschten
Versionsnummer und \k{beginpackage} macht es zug"anglich. Vor dem Abbau
einer Verbindung zum \xns\ sollten die geladenen Pakete mit dem
\k{endpackage} Operator wieder aus dem Speicher entfernt werden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Methodenaufruf und Pseudovariablen}

In objektorientierten Sprachen werden Unterprogramme (Methoden) nicht 
durch Pro\-ze\-dur\-auf\-ru\-fe sondern durch das Versenden von Nachrichten 
an Objekte aufgerufen. Zum Versenden von Nachrichten gibt es den Operator
\k{send}.

\begin{xple}
    args meth obj \k{send}
\end{xple}

Diese Sequenz ruft die Methode \s{meth} in dem Objekt \s{obj} mit den
Parametern \s{args} auf.

Es gibt zwei \e{Pseudovariablen}, die f"ur spezielle Empf"anger von
Methoden benutzt werden. Die Empf"anger solcher so versandten Methoden
ergeben sich aus dem Aufrufkontext. Soll eine Methode aus dem gleichen
Objekt aufgerufen werden, so wird die Pseudovariable \k{self} benutzt.

\begin{xple}
    args meth \k{self} \k{send}
\end{xple}

Die andere Pseudovariable (\k{super}) dient dazu, eine in der Subklasse
"uberschriebene Methode der Superklasse aufzurufen.

\begin{xple}
    args meth \k{super} \k{send}
\end{xple}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\minisec{Kommunikation}

F"ur jede Verbindung eines Anwendungsprogramms zum \xns\ wird ein eigener
\n-Proze"s erzeugt. Dieser liest die vom Anwendungsprogramm kommenden 
typisierten Daten als \n-Programme und f"uhrt sie aus. In der Gegenrichtung
k"onnen beliebige Daten versendet werden. Dazu existieren die beiden
Operatoren \k{typedprint} und \k{tagprint}.

\begin{xple}
    20 \k{typedprint}
    (Peter) \k{typedprint}
\end{xple}

Der polymorphe Operator \k{typedprint} schickt dem eigentlichen Wert einen
Typidentifizierungskode vorweg. Anhand dieses Kodes kann das 
Anwendungsprogramm den nachfolgenden Wert aus der Standardrepr"asentation
extrahieren. Zum besseren Verst"andnis sei noch angemerkt, da"s Zeichenketten
in \ps\ nicht durch Anf"uhrungszeichen, sondern durch runde Klammern begrenzt
werden.

\begin{xple}
    t17 \k{tagprint}
\end{xple}

Mit dem Operator \k{tagprint} werden Assoziatoren (\e{tags}\,) zum 
Anwendungsprogramm "uber\-tra\-gen. Assoziatoren dienen der 
Identitifizierung von Aktionen (\e{callbacks}\,) im Anwendungsprogramm
(\VAS\ \ref{Abs. Kommunikation und Ereignisverwaltung}). Anwendungen 
der vorgestellten Mechanismen sind in Kapitel
\ref{Kap. Graphische Benutzerschnittstellen in Tycoon} zu finden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Die OPEN LOOK Benutzerschnittstelle}
\label{Abs. Die OPEN LOOK Anwenderschnittstelle}

Die \ol-Benutzerschnittstelle entspricht den von \sm\ und \att\ entwickelten
Stilrichtlinien (\e{style guides}\,) \cite{Open90FS,Open90ASG} f"ur die
Gestaltung einer "uber verschiedene Hardwareplattformen, Betriebssysteme und
Anwendungen hinweg konsistenten, effizienten und mit Maus und Tastatur 
einfach zu bedienenden graphischen Benutzerschnittstelle. Ziel einer solchen 
Spezifikation ist einerseits die vollst"andige Beschreibung des graphischen 
Erscheinungsbildes von Typen von Objekten (\e{look}\,), die ein Anwender auf
dem Bildschirm sieht. Andererseits beschreibt eine Spezifikation auch das
Verhalten des Systems (\e{feel}\,) auf Interaktionen des Anwenders, \dh\ wie
dieser mit den Objekten arbeiten kann. 

Der Unterschied zu anderen Benutzerschnittstellen, \zB\ \om\ \cite{Motif90},
\ns\ \cite{NeXT91} \msw\ \cite{Windows92} oder dem \fin\ \cite{Finder92}
liegt im "au"seren Erscheinungsbild und der Funktionalit"at der Fenster und 
Interaktionselemente \cite{HuSh93,Ammo94}.

Die \ol-Schnittstellenkomponenten (\e{widgets}\,) lassen sich in drei 
Klassen unterteilen, den Bildschirmhintergrund (\e{framebuffer}\,), die
Interaktionselemente (\e{controls}\,) und die Fenster (\e{windows}\,).
In den nachfolgenden Abschnitten werden einige f"ur die Visualisierung
verwendete Klassen mit ihren Elementen genauer beschrieben.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Bildschirmhintergrund}
\label{Abs. AR}

Der Bildschirmhintergrund stellt den Untergrund dar, auf dem die
Anwendungen gestartet werden. Die Anwendungen erscheinen auf dem 
Bildschirmhintergrund entweder als Fenster oder als Piktogramme 
(\e{icons}\,). Piktogramme symbolisieren gestartete Anwendungen, 
die \zZt\ nicht ben"otigt werden. Ihre Verwendung f"ordert die
"Uberschaubarkeit des Bildschirmhintergrundes.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Interaktionselemente}
\label{Abs. IE}

Interaktionselemente sind vom Anwender manipulierbare 
Schnittstellenkomponenten. Durch die Manipulation, \zB\ Dr"ucken eines 
Knopfes oder Eingeben eines Textes, gibt der Anwender Eingaben an das 
System. Eine "Ubersicht "uber die wichtigsten Interaktionselemente der 
\ol-Benutzerschnittstelle ist in Abbildung \ref{Abb. IE} zu finden, die
dazugeh"orige Funktionalit"at wird in der nachfolgenden Aufstellung 
beschrieben.

\begin{figure}[p]
  \psbild{0.84#1}{dienste}{OPENLOOK.ps}
  \caption{Wichtige \ol\ Interaktionselemente}
  \label{Abb. IE}
\end{figure}

\begin{description}
  \item [Kn"opfe:]
        In der Darstellung von Kn"opfen wird zwischen normalen Kn"opfen
        (\e{buttons}\,) und Abk"urzungskn"opfen (\e{abbreviated buttons}\,)
        unterschieden. Beide Arten lassen sich weiter unterteilen. Mit
        einfachen Kn"opfen werden Aktionen (\e{actions}\,) aufgerufen und
        Men"ukn"opfe (\e{menu buttons}\,) dienen dem Anzeigen von Men"us.
        Sie unterscheiden sich von einfachen Kn"opfen durch ein kleines
        Dreieck im Knopf, das die Richtung angibt, in der das Men"u
        angezeigt wird. Schlie"slich gibt es noch Fensterkn"opfe
        (\e{window buttons}\,). Sie dienen dem Aufruf von Aufklappfenstern.

  \item [Men"us:]
        Men"us fassen mehrere "ahnliche Aktionen zusammen. Es gibt drei
        Arten von Men"us. Am h"aufigsten werden Knopfmen"us
        (\e{button menus}\,) benutzt. Des weiteren gibt es noch Aufklapp-
        (\e{popup menus}\,) und Submen"us (\e{submenus}\,). Die Eintr"age
        in Men"us (\e{menu items}\,) dienen, genau wie einfache Kn"opfe,
        dem Aufruf von Aktionen. Alle Men"us k"onnen mit einer Stecknadel
        (\e{push pin}\,) auf dem Bildschirmhintergrund angepinnt werden.

  \item [Auswahlfelder:]
        Bei den Auswahlfeldern (\e{settings}\,) wird zwischen zwei Arten
        unterschieden. Aus Exklusivauswahlfeldern (\e{exclusive settings}\,)
        kann nur ein Eintrag gleichzeitig ausgew"ahlt werden und aus
        Mehrfachauswahlfeldern (\e{nonexclusive settings}\,) k"onnen mehrere
        Eintr"age gleichzeitig ausgew"ahlt werden. 

  \item [Ja/Nein-Felder:]
        Die Ja/Nein-Felder (\e{check boxes}\,) k"onnen nur zwei m"ogliche
        Werte annehmen, \e{ja} oder \e{nein} bzw.\ \e{wahr} oder
        \e{falsch}. Der Wert \e{wahr} wird durch einen Haken im Feld
        repr"asentiert.

  \item [Eingabefelder:]
        Eingabefelder (\e{input fields}\,) dienen der Dateneingabe. Dabei
        wird zwischen numerischen (\e{numeric fields}\,) und
        alphanumerischen (\e{text fields}\,) Eingabefeldern unterschieden.
        Numerische Eingabefelder haben optional zwei Abk"urzungskn"opfe am
        rechten Ende des Feldes, mit denen der angezeigte Wert schrittweise
        in- bzw.\ dekrementiert werden kann.

  \item [Rollbalken:]
        Ein Rollbalken (\e{scrollbar}\,) erlaubt es, den momentan sichtbaren
        Ausschnitt von Daten in einem speziellen Bereich (\e{pane}\,) zu
        verschieben. Am Rollbalken existieren daf"ur eine Vielzahl von
        Angriffspunkten. Der sichtbare Ausschnitt kann \zB\ zeilen- oder 
		seitenweise verschoben werden.

  \item [Festtexte:]
        Festtexte (\e{labels}\,) sind nicht-ver"anderbare Informationstexte.

  \item [Datenaustauschfelder:]
        Datenaustauschfelder (\e{drop targets}\,) dienen dem Austausch von
		Daten "uber Anwendungsgrenzen hinweg. Ein ausgef"ulltes Feld
		repr"asentiert austausch\-f"a\-hi\-ge Daten in einer Anwendung.

\end{description}

Eine "uber diese Einf"uhrung hinausgehende Beschreibung der vorgestellten
sowie eine Beschreibung weiterer Interaktionselemente ist in 
\cite{Open90FS} zu finden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Fenster und Fensterelemente}
\label{Abs. Fenster und Fensterelemente}

In verteilten Fenstersystemen geben Anwendungsprogramme ihre Informationen 
auf virtuellen Bildschirmen, sogenannten Fenstern aus. Jedes
Anwendungsprogramm hat ein Grundfenster (\e{base window}\,). In Abbildung 
\ref{Abb. Grundfenster} ist das Grundfenster des \ow-Dateimanagers 
(\e{file manager}\,) abgebildet. Wird das Fenster geschlossen, so wird es
als Piktogramm auf dem Bildschirmhintergrund dargestellt. Weitere Fenster
einer Anwendung sind Aufklappfenster (\e{popup windows}\,). Sie werden
nur auf Anforderung des Anwenders oder der Anwendung ge"offnet und 
verschwinden wieder, sobald die entsprechende Funktion ausgef"uhrt ist.

\begin{figure}[htb]
  \psbild{0.84#1}{dienste}{Grundfenster.ps}
  \caption{Grundfenster (\ow\ Dateimanager)}
  \label{Abb. Grundfenster}
\end{figure}

Jedes Fenster hat eine Kopfzeile, die neben dem Titel des Fensters und dem
Namen des bearbeiteten Objekts noch weitere, von der Art des Fensters
abh"angige, Komponenten enth"alt (\VAB\ \ref{Abb. Fenstermerkmale}). 
Grundfenster enthalten \zB\ einen Men"uknopf (\e{window menu button}\,), 
"uber den ein Men"u aufrufbar ist. In der Kopfzeile von Aufklappfenstern
ist hingegen eine Stecknadel zu finden. Sie dient dem permanenten Anpinnen
von Aufklappfenstern auf dem Bildschirmhintergrund. Wird die Stecknadel 
durch ein weiteres Anklicken herausgezogen, so verschwindet das Fenster
wieder vom Bildschirmhintergrund.

\begin{figure}[htb]
  \psbild{0#1}{dienste}{Aufklappfenster.ps}
  \caption{Merkmale von Fenstern}
  \label{Abb. Fenstermerkmale}
\end{figure}

Innerhalb der Fenster befindet sich in der Regel ein Kontrollbereich
(\e{control area}\,) und ein eingerahmter Bereich (\e{pane}\,). Der
Kontrollbereich dient zur Aufnahme von Interaktionselementen
(\VAS\ \ref{Abs. IE}). In dem eingerahmten Bereich werden die
Anwendungsinformationen wie Texte oder Graphiken dargestellt. Hat der 
Bereich vertikale und horizontale Rollbalken, so kann der sichtbare 
Bildausschnitt verschoben werden. Dadurch ist es m"oglich, Bilder 
darzustellen, deren Ausma"se gr"o"ser sind als der sichtbare 
Bildausschnitt.

Viele weitere Elemente der Fenster sind optional. Ein Fenster kann
spezielle Ecken haben, mit denen seine Gr"o"se ver"andert werden kann
(\e{resize corners}\,) oder eine Fu"szeile (\e{footer}\,), in der Fehler
oder Mitteilungen f"ur den Anwender ausgegeben werden k"onnen.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{R"uckmeldungen}
\label{Abs. Rueckmeldungen}

Neben den in den vorherigen Abschnitten beschriebenen 
Schnittstellenkomponenten wird in den \ol-Stilrichtlinien auch die Form
der graphischen R"uckmeldung (\e{feedback}\,) "uber den aktuellen Zustand
einer Anwendung festgelegt.

Zum Beispiel werden Voreinstellungen (\e{defaults}\,) in Men"us und
Auswahlfeldern besonders gekennzeichnet. Ausgew"ahlte Elemente werden
hervorgehoben (\e{highlighted}\,) und nicht anw"ahlbare Elemente werden als
nicht aktiv (\e{inactive}\,) gekennzeichnet. Kann eine Anwendung momentan
keine Eingaben entgegennehmen, so wird sie als belegt (\e{busy}\,)
gekennzeichnet. Auch der Mauszeiger nimmt in Abh"angigkeit vom
Bearbeitungszustand einer Anwendung und von seiner Position spezielle
Formen an.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Das NeWS Toolkit}
\label{Abs. Das NeWS Toolkit}

Das \tnt\ \cite{TNT92,NPG92} ist ein auf der Sprache \ps\ basierendes,
objektorientiertes Werkzeug zur Erstellung von Benutzerschnittstellen 
f"ur das Fenstersystem \n. Das Werkzeug implementiert viele der 
\ol-Schnittstellenkomponenten. \cc-basierte Bibliotheken zur Kommunikation
zwischen Anwendungsprogramm und Fenstersystem sowie zur Ereignisverwaltung
erm"oglichen den Einsatz des Werkzeuges unter Verwendung verschiedener
Programmiersprachen. Zum \tnt\ geh"ort auch ein einfacher Texteditor 
(\s{jot}\,). Auch hierf"ur steht eine \cc-Bibliothek zur Verf"ugung.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Organisation}
\label{Abs. Organisation des Werkzeuges}

Der Einsatz eines objektorientierten Werkzeuges zur Erstellung von
Benutzerschnittstellen hat folgende Vorteile. Die grundlegenden Ziele der
objektorientierten Programmierung, Vererbung (\e{inheritance}\,), 
Wiederverwendung (\e{polymorphism}\,) und Kapselung (\e{encapsulation}\,),
decken sich mit den Anspr"uchen von Werkzeugen zur 
Benutzerschnittstellenerstellung (\VAS\ \ref{Abs. Klassenbibliotheken}).

Zur Erstellung von \ol-konformen Benutzerschnittstellen sind im \tnt\
"uber 30 Klassen vordefiniert. In Abbildung \ref{Abb. TNT Klassenhierarchie}
sind alle Klassen des Werkzeuges in ihrer Hierarchie dargestellt. Von diesen
Klassen k"onnen je nach Anwendung entweder Subklassen oder Instanzen erzeugt 
werden. 

\begin{figure}[htb]
  \psbild{0.55#1}{dienste}{TNTKlassen.ps}
  \caption{Hierarchie vordefinierter Klassen im \tnt\ \protect\cite{TNT92}}
  \label{Abb. TNT Klassenhierarchie}
\end{figure}

Die folgende alphabetische Aufz"ahlung stellt die wichtigsten im \tnt\
definierten Klassen vor und beschreibt kurz ihren Verwendungszweck.

\begin{description}
  \item [ClassObject:]
        Die Klasse \s{ClassObject} ist die Wurzel der Klassenhierarchie.
        Sie beinhaltet die Basismethoden des \n\ (\VAS\
        \ref{Abs. Grundbegriffe NeWS}).

  \item [ClassCanvas:]
        Die Klasse \s{ClassCanvas} stellt die Grundfunktionalit"at f"ur
        ihre Subklassen zur Verf"ugung. Diese Funktionalit"at besteht \zB\
		darin, da"s sie sich selbst auf dem Bildschirm anzeigen und
        restaurieren sowie Operationen wie Gr"o"senver"anderungen
		selbst ausf"uhren k"onnen. Das Aussehen eines Canvases ist 
		durch eine nicht notwendigerweise rechteckige Fl"ache gekennzeichnet.
        Canvases beinhalten auch F"ahigkeiten zur Ereignisbehandlung.

  \item [ClassBag:]
        Ein \s{Bag} ist eine Art Beh"alter. Er wird verwendet, um mehrere
        Klienten, Canvases oder Regions, f"ur Layoutzwecke oder Operationen
        zusammenzufassen.

  \item [ClassBorderBag:]
        Ein \s{BorderBag} kann bis zu f"unf Klienten an fest vordefinierten
        Positionen verwalten. Die Klienten k"onnen sich in der Mitte und an
        den vier R"andern befinden. Diese Positionen sind \zB\ f"ur den
        Aufbau von Fenstern sinnvoll.

  \item [ClassPanel:]
        Ein \s{Panel} ist wie ein Bag eine Art Beh"alter. Im Gegensatz zum
        Bag stehen f"ur ein Panel mehrere Layoutstrategien zur Verf"ugung.
        Durch die Layoutstrategien wird die Anordnung der Klienten im
        Panel bestimmt.

  \item [ClassItemGroup:]
        Die Klasse \s{ClassItemGroup} stellt Methoden zur Verwaltung von
        mehreren gleichen Klienten zur Verf"ugung. Sie hat den Zweck, die
        Anzahl von Klienten, die in Beh"alter eingef"ugt werden, zu
        reduzieren. Genau wie f"ur Panels gibt es mehrere Layoutstrategien.

  \item [ClassControl:]
        Die Klasse \s{ClassControl} wird per Mehrfachvererbung an alle
        Klassen vererbt, die vom Benutzer manipulierbare 
		Schnittstellenkomponenten definieren. Sie beinhaltet \ua\ Methoden 
		zur Definition von Benachrichtigungsprozeduren 
        (\e{notify procedures}\,).

  \item [ClassLayout:]
        Die Klasse \s{ClassLayout} wird per Mehrfachvererbung an alle
        Klassen vererbt, die Klienten mit Layoutstrategien plazieren. Es
        gibt vier Layoutstrategien. Beim \s{spaced placement} sind keine
        weiteren Layoutinformationen notwendig. Die Klienten werden 
		automatisch so plaziert, da"s der minimalste Platz belegt wird. Beim
        \s{grid placement} werden die Klienten zeilen- bzw.\ spaltenweise
        plaziert. Beim \s{absolute placement} werden die Klienten durch
        die zus"atzliche Angabe von absoluten Koordinaten plaziert und beim
        \s{calculated placement} wird die Plazierung der Klienten durch
        Ausf"uhrung eines Kodefragmentes berechnet.

\end{description}

Aufbauend auf diesen vom Aussehen der Benutzerschnittstelle unabh"angigen 
Klassen gibt es im \tnt\ eine Vielzahl von Klassen, die die meisten der
\ol-Schnitt\-stel\-len\-kom\-po\-nen\-ten implementieren. Stellvertretend
f"ur alle anderen Klassen werden hier die Klassen \s{ClassBaseWindow} und
\s{ClassMenuButtons} aufgef"uhrt.

\begin{description}
  \item [ClassBaseWindow:]
        Instanzen dieser Klasse sind \ol-Grund\-fen\-ster
		(\VAS\ \ref{Abs. Fenster und Fensterelemente}).

  \item [ClassMenuButtons:]
        Instanzen dieser Klasse sind 
		\ol-Me\-n"u\-kn"op\-fe (\VAS\ \ref{Abs. IE}). Eine Instanz 
		stellt dabei eine Menge von Men"ukn"opfen zur Ver\-f"u\-gung,
		deren Anordnung durch die gew"ahlte Layoutstrategie bestimmt
		wird.

\end{description}

Eine genaue Beschreibung aller vom \tnt\ definierten Klassen ist in
\cite{TNT92} zu finden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Kommunikation und Ereignisverwaltung}
\label{Abs. Kommunikation und Ereignisverwaltung}

Bestandteil des \tnts\ ist der \ws, eine \cc-Bibliothek, die eine 
bidirektionale Kommunikation zwischen Anwendungsprogrammen und dem \xns\ 
erm"oglicht. In der Bibliothek sind Funktionen zum Auf- und Abbau von
Verbindungen zum \xns\ und Funktionen zum Assoziieren von 
Schnittstellenkomponenten und Ereignissen auf der \n-Seite mit Namen
und Aktionen auf der Seite des Anwendungsprogramms zu finden. Dar"uber
hinaus sind in der Bibliothek auch Funktionen zur Abhandlung von 
synchroner und asynchroner Kommunikation zu finden. Einzelne wichtige
Funktionen werden in Abschnitt 
\ref{Abs. Kommunikation und Ereignisverwaltung 2} noch ausf"uhrlich
beschrieben.

In der Kommunikation zwischen einem Anwendungsprogramm und dem \xns\ 
wird zwischen drei Kommunikationsarten unterschieden. Im einfachsten 
Fall sendet nur das Anwendungsprogramm\ \n-Kodefragmente zum \xns\ und 
erwartet keine R"uckgabewerte. Diese Art der Kommunikation wird \zB\
verwendet, um Eigenschaften von Schnittstellenkomponenten zu ver"andern.

Bei der \e{synchronen} Kommunikation sendet das Anwendungsprogramm
\n-Kode\-frag\-men\-te zum Server und wartet auf die R"uckgabewerte.
Dabei wird die Programmausf"uhrung so lange unterbrochen (\e{blocked}\,),
bis die R"uckgabewerte vom Server angekommen sind. Die synchrone
Kommunikation wird \zB\ verwendet, um Eigenschaften von 
Schnittstellenkomponenten abzufragen und die Ergebnisse dann im 
Anwendungsprogramm weiter zu verwenden.

Auch bei der \e{asynchronen} Kommunikation sendet das Anwendungsprogramm 
\n-Kode\-frag\-men\-te zum Server, wartet aber im Unterschied zur synchronen 
Kommunikation nicht auf die R"uckgabewerte. Diese Art der Kommunikation 
wird verwendet, um Funktionen des Anwendungsprogramms mit 
Interaktionselementen der Benutzerschnittstelle zu assoziieren. Wird dann
ein Interaktionselement manipuliert, \zB\ ein Knopf gedr"uckt, so sendet 
der \xns\ eine Nachricht an das Anwendungsprogramm. Dieses kann anhand 
des Assoziators in der Nachricht die dazugeh"orige Aktion identifizieren
und aufrufen. Die aufgerufene Funktion ist f"ur die Behandlung evtl.\ 
vorhandener R"uckgabewerte selbst zust"andig.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Textbearbeitung}
\label{Abs. Textbearbeitung}

Mit dem \tnt\ wird neben dem \ws\ noch ein weiteres Paket geliefert, das
\jo-Textpaket. Es stellt Datenstrukturen und Funktionen zur interaktiven
Behandlung von Texten zur Verf"ugung. Das Paket besteht im wesentlichen
aus den drei Teilen \jote, \jovi\ und \jo. In diesem Abschnitt werden nur
die Grundkonzepte des Paketes beschrieben, weitere Informationen zum 
\jo-Textpaket sind in \cite{TNT92} zu finden.

Die Funktionalit"at des Textpakets korrespondiert mit dem von \st\ 
bekannten \e{model-view-controller} Paradigma \cite{GoRo83,Hues93}.
Das Paradigma unterteilt eine Anwendung in die Komponenten Datenobjekt
(\e{model}\,), welches die Information der Anwendung enth"alt, die Sicht
(\e{view}\,), die das mit ihr assoziierte Datenobjekt graphisch 
repr"asentiert und den Verwalter (\e{controller}\,), der als Schnittstelle
zwischen dem Eingabeger"at und dem Datenobjekt fungiert. Er erm"oglicht
dem Benutzer die Interaktion mit dem Datenobjekt "uber die Sicht. 

Ein \jote\ entspricht dem Datenobjekt, das die Information der Anwendung,
\idR\ einen mehrzeiligen Text, enth"alt. Der \jote\ selbst ist nicht sichtbar.
Er ben"otigt zu seiner Darstellung einen \jovi. Der \jovi\ repr"asentiert
die Daten des \jote\pn{es} graphisch und erm"oglicht eine bestimmte Sicht
auf sie. Da es sinnvoll sein kann, verschiedene Sichten auf ein 
Da\-ten\-ob\-jekt zu haben, sieht \n\ auch die M"oglichkeit der Erzeugung
mehrerer \jovi\pn{s} f"ur denselben \jote\ vor. 

Zus"atzlich ist es m"oglich, kleine Regionen (\e{spans}\,) auf dem \jote\
zu definieren. Eine Region wird durch ihre Ursprungsposition und L"ange
beschrieben. Der Positionsparameter pa"st sich automatisch an, wenn
Zeichen vor der Region eingef"ugt oder gel"oscht werden. Ebenso ver"andert
sich der L"angenparameter der Region automatisch, wenn innerhalb ihrer
Begrenzungen Zeichen hinzugef"ugt oder entfernt werden. Jeder \jote\
verwaltet eine Liste, der mit ihm verkn"upften Regionen. 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Datenaustausch}
\label{Abs. Moeglichkeiten des Datenaustauschs}

Das \tnt\ unterst"uzt den Datenaustausch auf der Ebene der 
Benutzerschnittstelle. Einfache Daten, wie \zB\ Zeichenketten und Zahlen,
k"onnen selektiert und direkt mit der Maus aufgenommen (\e{drag}\,) 
werden. Aufgenommene Daten k"onnen "uber den Bildschirm bewegt und "uber
einem anderen Feld fallengelassen (\e{drop}\,) werden. Die bewegten
Daten werden dann in dieses Feld eingef"ugt. Komplexere Daten, wie \zB\
l"angere Texte oder Bilder, k"onnen meist nicht direkt mit der Maus
selektiert werden. Der symbolische Austausch solcher Daten ist "uber
Datenaustauschfelder (\VAB\ \ref{Abb. IE}) m"oglich. Datenaustauschfelder
sind Instanzen der Klasse \s{ClassDropTarget}. 

Dabei ist das Anwendungsprogramm f"ur den eigentlichen Datenaustausch 
selbst verantwortlich. Das \tnt\ benachrichtigt das Programm nur "uber
den Start, das Bewegen und das Ziel des Austauschs. Benutzerdefinierte 
Klassen m"ussen demnach bestimmte Methoden zur Verf"ugung stellen, die
auf Ereignisse, wie Aufnehmen und Fallenlassen, reagieren k"onnen.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Anwendungsentwicklung}
\label{Abs. Anwendungsentwicklung}

Die Anwendungsentwicklung mit dem \tnt\ besteht aus zwei Teilen in 
unterschiedlichen Programmiersprachen. Der Server-Teil wird in der
objektorientierten \n-Sprache geschrieben. Der Klienten-Teil, das
Anwendungsprogramm, kann \zB\ in \cc\ oder \cpp\ geschrieben werden. Er
enth"alt die \n-Aufrufe. Im Gegensatz zu \x-Anwendungen, k"on\-nen 
Teile der \n-Anwendungen auch im Server ablaufen. Die Erstellung des 
Server-Teils besteht im allgemeinen aus vier Schritten:

\begin{enumerate}
  \item Definition der vom Anwendungsprogramm benutzen Subklassen.

  \item Instanziierung der im ersten Schritt erzeugten Subklassen.

  \item Zusammensetzen der instanziierten Objekte. Dazu werden die Objekte
        meistens in Beh"altern gruppiert. Die Beh"alter werden anschlie"send
        in Fenster eingef"ugt.

  \item Festlegen der Gr"o"se von Fenstern und Plazieren der Fenster,
        Aktivieren der Ereignisverwaltung und schlie"slich Anzeigen der
		Fensters.

\end{enumerate}

Im Klienten-Teil werden f"unf Schritte unterschieden:

\begin{enumerate}
  \item Aufbauen einer Verbindung mit dem \xns.

  \item Definition von Aktionen (\e{callback functions}\,), die durch
        Nachrichten (\e{notifier}\,) von den Interaktionselementen
		angesto"sen werden. Vielen der \ol-Schnitt\-stel\-len\-kom\-po\-nen\-ten
		k"onnen Benachrichtigungsprozeduren zugewiesen werden, die
		Nachrichten an das Anwendungsprogramm senden, wenn sie
        manipuliert werden. 

  \item Definition von Assoziatoren (\e{tags}\,) und Identifikatoren
        (\e{tokens}\,). Assoziatoren dienen der Assoziierung von 
		Interaktionselementen mit Aktionen, w"ahrend Identifikatoren
		Namen f"ur \n-Objekte sind.

  \item Initialisierung, Ausf"uhren des Server-Teils.

  \item Warten auf Nachrichten vom \xns.

\end{enumerate}

Bei statisch "ubersetzten \cc-Programmen sind die hier aufgef"uhrten
Schritte der Anwendungsentwicklung in dieser Form zu finden. F"ur andere,
dynamische Programmiersprachen, wie \zB\ \tl, k"onnen sich sowohl die
Reihenfolge der Schritte "andern, als auch Schritte des Server-Teils im
Anwendungsprogramm durchgef"uhrt werden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Die OpenWindows Anwendungsumgebung}
\label{Abs. Die OpenWindows Anwendungsumgebung}

\ow\ ist genau wie \n\ ein verteiltes Fenstersystem. Die wesentlichen
Komponenten der \ow-Anwendungsumgebung sind der \xns\ und Werkzeuge zur 
Erstellung von \ol-konformen Benutzerschnittstellen, sowohl f"ur das \x- 
als auch f"ur das \n-Protokoll. Daneben existieren diverse fensterbasierte 
Hilfsmittel (\e{deskset tools}\,) \cite{DDRS92,OWRM93,SUG93}, \zB\ zum
Editieren von Texten (\e{text\-edit}\,), zum Schreiben und Versenden von 
Briefen (\e{mailtool}\,) und zur Dateibehandlung (\e{file manager}, \VAB\
\ref{Abb. Grundfenster}), auf die in diesem Zusammenhang aber nicht 
weiter eingegangen werden soll.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Der X11/NeWS Server}
\label{Abs. Der X11/NeWS Server}

Der \xns\ \cite{Scha89,GRA89,XNSG90} bildet die Grundlage f"ur die 
\ow-Anwendungsumgebung. Der \xns\ ist ein Fenstersystemmanager, der das 
\e{Client/Server-Modell} \cite{Tan87,NIPG90} implementiert, \dh\ es 
existiert eine klare Trennlinie zwischen Anwendungsprogramm (Klient) und 
Diensterbringer (Server). Klient und der Server k"onnen sich dabei auch auf
unterschiedlichen Knoten eines Netzwerkes befinden.

Bildschirm, Tastatur und Maus werden von einem Proze"s, dem Server, 
verwaltet. Die drei Hauptaufgaben des Servers sind, wie in Abbildung 
\ref{Abb. XNS} zu sehen ist, die Interpretation und die Ausf"uhrung von 
\n-Programmen, das Zuweisen von Bildschirmteilen und das Verteilen von
Eingaben an die Anwendungsprogramme. Der Server verbindet die Semantik
des \x- und des \n-Protokolls, so da"s Anwendungsprogramme "uber beide
Protokolle mit dem Server kommunizieren k"onnen.

\begin{figure}[htb]
  \psbild{0.7#1}{dienste}{X11NeWSServer.ps}
  \caption{Struktur des \xns\ \protect\cite{GRA89}}
  \label{Abb. XNS}
\end{figure}

Der \xns\ besteht, wie in Abbildung \ref{Abb. XNS} zu sehen ist, aus
mehreren Komponenten, die im folgenden kurz beschrieben werden. Der 
Server enth"alt die schon in Abschnitt \ref{Abs. Grundbegriffe NeWS}
beschriebenen leichten Prozesse. Der Scheduler verteilt die f"ur den Server
zur Verf"ugung stehende Rechenzeit auf diese Prozesse. Jeder Proze"s kann
unterschiedliche Operationen ausf"uhren und Nachrichten der Eingabeger"ate
und anderer Prozesse empfangen.

Der Fensterwald (\e{window forest}\,) ist eine Datenstruktur, in der alle
Fenster eines Bildschirms verwaltet werden. Dabei ist es egal, ob ein Fenster
durch das \x- oder durch das \n-Protokoll erzeugt worden ist.

Die Ereigniswarteschlange (\e{event queue}\,) hat die Aufgabe, alle von
den Eingabeger"aten ankommenden Nachrichten zu sammeln, mit einem
Zeitstempel zu versehen und zu serialisieren. Die Verteilung wird anhand 
von Beispielnachrichten (\e{interests}\,) durchgef"uhrt, die von den 
leichten Prozessen generiert werden. Sie werden als Muster f"ur den 
Vergleich herangezogen. Jeder leichte Proze"s, dessen Beispielnachricht
einer ankommenden Nachricht gleicht, bekommt eine Kopie der Nachricht.
Er leitet sie gegebenenfalls an das Anwendungsprogramm weiter, mit dem
er kommuniziert.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Der Developer's Guide}
\label{Abs. Developers Guide}

Mit Hilfe des \dg\ (\e{Developer's Graphical User Interface Design Editor},
\VAB\ \ref{Abb. Developers Guide}) \cite{DG92} ist es m"oglich, interaktiv
\ol-konforme Benutzerschnittstellen f"ur die \ow-Anwendungsumgebung zu 
erstellen. Das Ergebnis wird in einer GIL-Datei (\e{Graphics Interface
Language}\,) gespeichert. Diese Datei kann in \cc-Quelltextdateien sowie
die dazugeh"orige \e{Make}-Datei umgewandelt werden. Anschlie"send kann 
mit einem \cc-"Ubersetzter ein unter \ow\ lauff"ahiges Programm erzeugt
werden (\VAS\ \ref{Abs. Quelltext-Programmgeneratoren}).

\begin{figure}[htb]
  \psbild{0.65#1}{dienste}{DevGuide.ps}
  \caption{\ow\ Developer's Guide}
  \label{Abb. Developers Guide}
\end{figure}

Schon w"ahrend der Entwicklung mit dem \dg\ kann das endg"ultige Aussehen
und Verhalten der Benutzerschnittstelle in einem \e{Test-Modus} simuliert 
werden. Umfangreiche Dialogmanagementfunktionen (\e{connections}\,) 
erm"oglichen die Ansteuerung vieler Schnittstellenkomponenten auf der Ebene
der Benutzerschnittstelle, ohne da"s dieses Verhalten explizit in \cc\
kodiert werden mu"s.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Zusammenspiel der kommerziellen Dienste}
\label{Abs. Zusammenspiel der kommerziellen Dienste}

In Abbildung \ref{Abb. Zusammenspiel} ist das Zusammenspiel der 
in diesem Kapitel vorgestellten kommerziellen Dienste dargestellt. Alle
Dienste sind unter dem Betriebssystem \sos\ in der 
\ow-An\-wen\-dungs\-um\-ge\-bung lauff"ahig.

\begin{figure}[htb]
  \psbild{0.8#1}{dienste}{Zusammenspiel.ps}
  \caption{Zusammenspiel der kommerziellen Dienste}
  \label{Abb. Zusammenspiel}
\end{figure}

F"ur einen Anwendungsprogrammierer gibt es verschiedene M"oglichkeiten,
mit den vorgestellten Diensten Anwendungsprogramme zu erzeugen. Zum 
Beispiel ist es denkbar, ein Programm nur in \ps\ (\VAS\ 
\ref{Abs. Die SBS PS}) zu schreiben, da die Sprache neben 
graphikspezifischen Operatoren auch eine Reihe allgemeiner Operatoren
enth"alt und damit zu einer vielseitig verwendbaren allgemeinen 
Programmiersprache wird. Da auf dieser 
Ebene jedoch keine Schnittstelle zur Programmierung graphischer
Benutzerschnittstellen verf"ugbar ist, m"u"ste diese erst implementiert
werden. Auch stehen f"ur die Programmierung in \ps\ keine allgemein 
verwendbaren Bibliotheken zur Verf"ugung. Ein weiterer Nachteil ist die
erst zur Laufzeit erfolgende Typ"uberpr"ufung. Aus den genannten Gr"unden
ist von einer vollen Implementation von gr"o"seren Anwendungen in \ps\ 
abzuraten.

Als n"achste Ebene bietet sich die Implementation in \n\ (\VAS\ 
\ref{Abs. Das FS NeWS}) an. Da \n\ weitgehend auf \ps\ basiert, hat
diese Sprache auch "ahnliche Nachteile wie \ps. In der Sprache sind 
jedoch viele Erweiterungen zu finden, die der Interaktion 
(Bildschirmausgaben sowie Maus- und Tastatureingaben) und der 
Mehrproze"sf"ahigkeit in einem Fenstersystem Rechnung tragen. Dadurch
sind die Grundlagen geschaffen, Benutzerschnittstellen effizient zu
programmieren. In \n\ findet sich auch ein Bibliothekskonzept, das die
Wiederverwendung unterst"utzt. Genau wie auf der Ebene von \ps\ ist 
es auf der Ebene von \n\ nicht anzuraten, komplette Anwendungen zu 
schreiben. Zum einen fehlt auch hier die Unterst"utzung durch 
allgemeine Bibliotheken und zum anderen wird die Entwicklung und
Wartung von Programmen auf dieser Ebene nur ungen"ugend unterst"utzt.
Trotzdem kann es aus Effizienzgr"unden sinnvoll sein, kleinere 
Unterprogramme direkt im \xns\ und nicht im Klient ablaufen zu 
lassen. Vorstellbar sind \zB\ Prozeduren zur Manipulation von 
Schnittstellenkomponenten.

Auf dem Fenstersystem \n\ setzt mit dem \tnt\ ein objektorientiertes
Werkzeug auf (\VAS\ \ref{Abs. Das NeWS Toolkit}). Das Werkzeug
implementiert eine Klassenhierarchie zur effizienten Programmierung
graphischer Benutzerschnittstellen. Die Qualit"at der zugrundeliegenden
Sprache wird jedoch dadurch nicht gesteigert. Aus diesem Grund gilt
auch hier das eben f"ur \n\ Gesagte.

Einerseits ist die fehlertr"achtige direkte \n-Programmierung zu 
unsicher, andererseits ist die durch das \tnt\ zur Verf"ugung 
gestellte m"achtige Funktionalit"at unbestritten. Daher bietet es
sich an, auf dieser Ebene eine Schnittstelle zu einer Hochsprache
zu implementieren. Eine solche Schnittstelle hat folgende
Vorteile f"ur die  Erstellung von Benutzerschnittstellen. Funktionsaufrufe 
in einer Hochsprache sind parametrisierbar und typisierbar. Sie erm"oglichen
weiterhin, von der kellerspeicherorientierten Syntax der \n-Methodenaufrufe
zu abstrahieren und die sonst aufwendig zu programmierende Kommunikation, 
die zwischen einer Anwendung und dem \xns\ stattfindet, zu verbergen. 

Eine Anbindung des Werkzeuges an einen "Ubersetzter f"ur \cc\ oder \cpp\
erlaubt die Ausnutzung der eben aufgez"ahlten Vorteile. Es treten jedoch 
auch die typischen Nachteile von "Ubersetzern auf. Zum Beispiel ist es
nicht m"oglich, in einem "Ubersetzer interaktiv Funktionen oder Programme
auszuf"uhren, da ein Programm zur Laufzeit komplett "ubersetzt und gebunden 
vorliegen mu"s. In der Entwicklungs- und Testphase ist es jedoch von 
Vorteil, auch dynamisch Funktionen ausf"uhren und testen zu k"onnen.
Dadurch ist es dann m"oglich, Benutzerschnittstellen oder Teile davon
zu erzeugen und zu ver"andern (\VAS\ 
\ref{Abs. Dynamische Erzeugung von graphischen Benutzerschnittstellen}).
Auch die anderen in diesem Kapitel vorgestellten Dienste der 
\ow-Anwendungsumgebung, \zB\ der \dg\ und das \jo-Textpaket, lassen
sich "uber eine Schnittstelle von einer Hochsprache aus nutzen. In Kapitel 
\ref{Kap. Graphische Benutzerschnittstellen in Tycoon} wird
die Implementation einer solchen Schnittstelle zwischen der 
\ty-Entwicklungsumgebung und dem \tnt\ ausf"uhrlich vorgestellt.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% End of text                                                        %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
