Unix & Shell-Programmierung: X-Windows

Eigenschaften
Fenstersystem	für
	Grafik-Bildschirm
	Tastatur
	Maus
	weitere Eingabegeräte
Netzwerk	in einem Netzwerk transparent einsetzbar
	mehrere Rechner von einem Bildschirm aus bedienbar
	Anwendungen können an beliebiger Stelle im Netz laufen
unabhängig	von Herstellern und Rechnerarten
portabel

Architektur

client server	Konzept
	bei X client und server vertauscht
service	grafische Ein- und Ausgabe
client	ein Anwendungsprogramm
	ein server kann viele clients aus dem Netz bedienen
server	ein UNIX-Prozess
	der einzige Prozess, der auf die Grafik-Hardware und Software zugreift
	die clients sind systemunabhängig und portabel

Architektur im Detail

X-lib	ist verantwortlich für
	reine Grafikaufgaben
	zeichnen von Rechtecken, Linien, Punkten, ...
	Textausgabe, Fontauswahl
	Farbverwaltung: sw, 256 Farben, 16k Farben, ...
GUI-toolkits	liefern
widget sets	labels, buttons, menues, scrollbars, Textfenster, popup menues, ...
	komplexe grafische Objekte
	oft mit hierarchischem Aufbau
	Verteilung der Eingaben gemäß der (Unter-)Fensteranordnung widget Hierarchie
event loop	Schleife, die die Eingaben (Ereignisse, events) vom X-server verarbeitet
dispatcher	Ereignisverteiler: Zuordnung von events zu widgets

Aufgabenteilung

X	legt nicht die Benutzungsschnittstelle fest
	flexibel: jeder kann nach seinem eigenen Geschmack arbeiten
	uneinheitlich: kein durchgängiges "Sehen und Fühlen" (look and feel)
GUI-toolkits	legen das Aussehen der grafischen Elemente durch das implementierte widget set fest
	legt aber nicht die Verwaltung der verschiedenen Anwendungen auf dem Bildschirm fest
window manager	eine X-Anwendung mit erweiterten Rechten
	bestimmt die Verwaltung der verschiedenen Anwendungen
	unterschiedliche WMs: Motif: mwm Linux: fvwm kde: kwm Gnome ...
Aufgabenteilung	Grafik-Funktionen grafische Objekte Fensterverwaltung

Ereignisgesteuerte Programmierung

Charakteristika
	Was ist das?
	Was ist anders als bei "gewöhnlicher" Programmierung?
	Was ist gleich?
Einordnung	in Programm-Klassen

(a) batch	cc -c prog.c
	keine Interaktion mit dem Benutzer während des Programmlaufs
	fast kein Aufwand für die Entwicklung der Ein- und Ausgabe
	gibt es heute noch (wieder: server)

(b) shell	in einer Interpretationsschleife werden Kommandos sequentiell abgearbeitet
	Interpretationsschleife wie in einer CPU: Instruktion holen Instruktion dekodieren Instruktion in Abhängigkeit des Typs interpretieren
	nur eine Stelle im Programm, an der eine Eingabe gemacht wird
	nur ein Ereignis tritt ein: Eingabe einer Zeile
	während der Abarbeitung eines Kommandos verhält sich das Programm wie ein batch-Programm

Programm-Schema: shell

finished := false;
 
while not finished do
 
  cmd := readLine();
 
  cmdType, args := parseCommand(cmd);
 
  case cmdType of
    t1 : interpret_t1_command(args);
    ...
    t2 : interpret_t2_command(args);
    ...
    tn : interpret_tn_command(args);
    ...
    quit : finished := true
 
  end case
 
end while

(c) ereignisgesteuert	in einer Interpretationsschleife werden alle Ereignisse sequentiell abrearbeitet
	Programmfluss wie bei dem shell-Programm
	die Eingabeinformation ist viel feiner gestückelt:
	ein Tastendruck
	ein Mausklick
	eine Mausbewegung
	die Verteilung der Eingaben ist sehr, sehr viel aufwendiger
	während der Abarbeitung eines Ereignisses verhält sich das Programm, der event handler, wie ein batch-Programm
	die Konstruktion der event loop bildet die Hauptaufgabe bei der Entwicklung die eigentliche Anwendung ist (manchmal) nur noch nebensächlich
	Produktivität ???

Programm-Schema: event loop

finished := false;
 
while not finished do
 
  event := getEvent();
 
  eventType,
  eventPos,
  eventVal := analyseEvent(event);
 
  widget := selectWidget(eventType, eventPos);
 
  case widget of
    w1 : case eventType of
           t1 : interpret_w1_t1_command(eventVal);
           ...
           tn : interpret_w1_tn_command(eventVal);
         end case
    ...
 
    w2 : case eventType of
           t1 : interpret_w2_t1_command(eventVal);
           ...
           tm : interpret_w2_tm_command(eventVal);
         end case
    ...
 
    wk : case eventType of
           t1 : interpret_wk_t1_command(eventVal);
           ...
           tp : interpret_wk_tp_command(eventVal);
         end case
 
  end case
 
end while

GUI-toolkits	Werkzeugkasten für grafische Benutzungsschnittstellen
	enthalten eine allgemein einsetzbare event loop einschließlich dispatcher zur Verteilung und Interpretation der Ereignisse
	keine feste case-Anweisung, sondern eine Datenstruktur für die grafischen Objekte und deren event handler
Kommunikation	Anwendung <=> toolkit
.1	Anwendung fordert widget bei dem toolkit an
	oft in der Initialisierungsphase
.2	Anwendung muss Reaktion auf Ereignisse (events) bestimmen
	Ereignis-Behandlungs-Routinen (event handler) aus Anwendung der GUI-Bibliothek (dem toolkit) bekannt machen
	call back Routinen
Ereignisgesteuerte Programmierung	Erstellen von vielen kleinen Prozeduren, den event handlern, die auf gemeinsamen globalen Daten, den widgets, arbeiten
	jede Routine ändert den Zustand des Programms
	ganz gewöhnliche imperative Programmierung
	das Hauptprogramm befindet sich im GUI-toolkit

X-Windows

Das X-System

Architektur

Architektur im Detail

Aufgabenteilung

Ereignisgesteuerte Programmierung

Programm-Schema: shell

Programm-Schema: event loop