Die Flagge des Marasek

Dekostreifen

English

Aktuell Texte Der Comic Impressum Kalender Suche PHP-Klassen Container-Wizard main.s21

Kategorien

Buch
Computer
Computerspiele
Film
Geschichte
Gesellschaft
Idee
Kunst
Natur
Persönlich
Politik
Programmieren
Religion & Philosophie
Weblog
Weltpolitik
Weltsicht
{{login}}

Grafische Oberflächen

Permalink
Vorheriger: PHP und TypenNächster: Blautopf, Mittelaltermarkt in Blaubeuren
Eingeordnet in: Computer, Programmieren

Programme mit einer grafischen Oberfläche zu schreiben ist ein sehr hoher Aufwand. Ich pflege zu sagen, dass die Funktionalität eines Programms sehr schnell hergestellt ist, der Rest besteht daraus, alle möglichen Fehler abzufangen, die auftreten können. Da ein Programm mit einer grafischen Oberfläche schon von vorneherein interaktiv ist - dass heisst, sobald es ausgeführt wird, interagiert es mit dem Benutzer - können viele Zustände und mithin auch viele Fehler auftreten.

Die Grundlagen

Das reale Leben

Ich kann die Welt durch meine Sinne wahrnehmen und mit Hilfe meines Körpers beeinflussen. Hebe ich einen Stein auf, verändere ich den Zustand der Welt. Maschinen bieten mir mehr Möglichkeiten, die Welt zu verändern; ein Auto beispielsweise bewegt mich vorwärts. Das Auto besteht aus Einzelteilen, die Funktionen erfüllen. Diese Funktionen steuere ich, in dem ich Signale an sie gebe. Drehe ich den Zündschlüssel, wird der Anlasser als kleine Maschine in Bewegung gesetzt. Betätige ich den Blinker, wird ein Mechanismus in Gang gesetzt, der fortan selbstständig blinkt; ebenso bei dem Scheibenwischer, dem ich noch dazu eine Stufe geben kann. Wische langsam, wische schnell.

Die grafische Oberfläche

Ein Grundgedanke der grafischen Oberfläche (Graphical User Interface, GUI) ist es, die Interaktion des Menschen mit einem Computerprogramm an seine übliche Interaktion mit der Welt anzupassen. Auf einer Linux-Kommandozeile verschiebe ich eine Datei mit einem bestimmten Befehl, der einer Syntax folgt: "mv <Quelle> <Ziel>. Unter z. B. Windows XP ergreife ich die Datei - symbolisiert als kleines Bild - mit dem Mauszeiger und schiebe sie von einem Ordner'' in den anderen. Dies ist eine Metapher, die meinem realen Leben ähnelt: dort nehme ich ein Buch und stelle es in ein anderes Regal.

Die Umsetzung

Das Betriebssystem

Grundsätzlich hat der Computer keine Welt. Aber jetzt bei Bits & Bytes anzufangen wäre etwas langwierig, daher soviel: ein Betriebssystem wie Windows XP ist bereits eine grundlegende Welt, die dem Programmierer Komponenten des Computers in einer verallgemeinerten, standardisierten Form bereitstellt. Mit einer Programmiersprache kann ich Windows befehlen, bestimmte Tätigkeiten für mich zu tun: etwas auf die Festplatte zu speichern oder einen Ton abzuspielen. Das erspart mir schon einen Großteil der Arbeit, da ich mich um Details der Maschine (etwa, von welcher Firma die Soundkarte hergestellt wurde) niemals kümmern muss. Alle Grundelemente einer grafischen Oberfläche - Schaltflächen, Checkboxen, Dropdowns, Scrollbalken, Textfelder usw. usf - existieren schon, so dass ich dem System nur befehlen muss, einen Button mit der Aufschrift "OK" zu zeichnen.

Schaltflächen, Signale und Callbacks

Ein interaktives Programm ist üblicherweise so beschaffen, dass es ewig läuft, bis es abgebrochen wird. Startet man Firefox, wird Firefox im Idealfall solange laufen, wie das Betriebssystem selbst läuft. Während dieser Zeit "hört" das Programm alles, was mit dem Rechner gemacht wird: Tastendrücke und Mausklicks. In seiner Grundform reagiert es aber ebensowenig, wie ich auf einen fremden Namen reagiere. Es besteht noch überhaupt nichts.
Als Programmierer muss ich Schaltflächen definieren, beispielsweise Datei->Abspeichern oder Lesezeichen->Lesezeichen hinzufügen. Klicke ich dann auf diese Schaltflächen, passiert noch nichts. Es wird nur ein Signal gesendet: auf Datei->Abspeichern wurde ein Mausklick registriert. Oder ein Rechtsklick oder Doppelklick. Je nach Schaltfläche auch "es wurde Text ausgewählt", "es wurde ein Balken verschoben" und so weiter. Dies sind wie gesagt Funktionen, die meist schon von der Oberfläche, für die ich programmiere, bereitgestellt werden.
Von diesem Signal mache ich ein "Callback" abhängig: ich schreibe eine kleines Unterprogramm, dass eine bestimmte Aufgabe erledigt und einen Rückgabewert ausgibt. Beispielsweise, dass der Inhalt eines grossen Textfeldes in einer Datei gespeichert wird. Dieses Unterprogramm - eine Funktion, hat einen Rückgabewert, etwa "Erfolg/Fehlschlag". Ich kann Funktionen auch ineinanderschachteln, also eine Funktion die nächste aufrufen lassen: so kann eine Funktion ein Eingabefeld und einen OK-Button erzeugen, und diese Funktion gibt dann beispielsweise "15" zurück, wenn der Benutzer 15 in das Eingabefeld eingegeben hat.

Die Schwierigkeit

Die enorme Herausforderung liegt in der Interaktivität. Als Beispiel möchte ich mir einen einfachen Texteditor vorstellen, in den der Benutzer Text eintragen kann. Jetzt möchte der Benutzer das Programm verlassen.
Hierfür muss ich eine Schaltfläche - beispielsweise ein Knopf "Exit" - definieren. Wenn der Benutzer darauf rechtsklickt, soll eine Funktion aufgerufen werden, die das Programm beendet. Gesagt getan. Der Nutzer schreibt, klickt auf Exit - und weg sind zwei Stunden Arbeit.
Nun gut. Ich kann registrieren, dass in ein Feld etwas eingegeben wird. Sobald dies geschieht, soll ein Wert auf "Wahr" gesetzt werden. In der Exit-Funktion wird dann überprüft, ob in dem Feld etwas geändert wurde. Was dann?
Dann muss der übliche Dialog "Speichern? Ja/Nein/Abbrechen" her. Dieser Dialog besteht aus drei neuen Knöpfen, die wieder Signale senden und die drei erneute Callback-Funktionen erfordern:

  1. Ja: Datei abspeichern
  2. Nein: Verlassen
  3. Abbrechen: Zurück zum Programm

Bei Ja muss ich mich erneut entscheiden: ist es ein neuer Text oder eine bereits geöffnete Datei? im letzten Fall kann ich speichern und beenden, im ersten Fall muss ich einen ganz neuen Dialog aufbauen, in dem ich in Verzeichnissen navigieren muss. Das ist schon eine Leistung für sich, da ich dort unzählige weitere Schaltflächen habe: Ordner hoch, Laufwerk wechseln, Dateityp ändern...
Es ist allerdings so, dass Windows sowohl den Drei-Knöpfe-Dialog als auch den Dateidialog schon selbst bereitstellt. Ich muss also nur noch diesen Dialog aufrufen und bekomme eine entsprechende Antwort oder einen Pfadnamen geliefert. Es gibt aber auch andere Systeme, bei denen ich mir das selbst programmieren darf.
Nun habe ich einen Dateinamen. Nehmen wir aber an, der Nutzer hat ein CD-Rom-Laufwerk ausgewählt. Wenn ich jetzt einfach speichere und das Programm verlasse, schlägt der Vorgang fehl und die Daten sind weg. Also muss ich überprüfen, ob ich dort, wo ich schreiben will, auch schreiben kann. Glücklicherweise auch eine Arbeit, die ich an das Betriebssystem delegieren kann. Falls nicht, muss dem Benutzer eine Wahrnung präsentiert werden, in Form eines Dialogfeldes ("Kann nicht gespeichert werden, OK"). Nächstens muss ich überprüfen, ob die Datei schon existiert - Benutzer sind schusselig und überschreiben am Ende ihre Diplomarbeit mit einer Einkaufsliste. Also erwartet der Benutzer einen Dialog mit zwei Knöpfen, "Überschreiben, JA/NEIN". Klickt der Benutzer "JA", muss ich speichern. Und prüfen, dass tatsächlich gespeichert wurde, erst dann darf ich das Programm verlassen.
Wenn er nein klickt, zurück zum Dateidialog oder zurück zum Programm an sich.

Was ich eben beschrieben habe, ist schon eine nette Ansammlung an Code. Ein durchschnittliches Programm hat aber weitaus mehr Funktionen, bei denen natürlich noch viele Fehler mehr auftreten können.

Kommentieren

Bitte beachten: Kommentare sind nicht sofort sichtbar, sondern werden erst nach einer kurzen Prüfung freigegeben, sofern keine rechtliche Beanstandung vorliegt.
Rechtlich bedenkliche Inhalte werden entweder entschärft oder nicht veröffentlicht.

* Titel  
* Nickname  
* Kommentar