Viele Programmierer klagen über zuwenig offizielle Richtlinien zu GEM-Programmen. Ein bißchen »Detektiv-Arbeit« fördert jedoch einige Literatur zutage.
In letzter Zeit haben mich viele Zuschriften erreicht, in denen nach meinen »Fliegenden Dialogen« gefragt wird. Diese sind eine C-Bibliothek, die für Tastatur-Shortcuts und einige andere Details in Programmen wie »Gemini«, »SCSITool«, »Rufus« oder »Scigraph« zuständig ist. Zur Zeit sind weder Objectcodes noch Quelltext erhältlich. Sobald sich etwas daran ändert, werde ich im »Atarium« darauf hinweisen. Daher bitte ich, von weiteren Anfragen abzusehen.
Aber nun zum Thema: Viele Programmierer klagen darüber, daß es zuwenig »offizielle« Richtlinien zur Gestaltung von GEM-Programmen gäbe. Tatsächlich hat es Atari hier versäumt, die Entwicklung mit dem nötigen Nachdruck in die richtigen Bahnen zu lenken. Nun kann man aber nicht sagen, in dieser Hinsicht fehlen überhaupt Unterlagen, man muß sie eben nur finden!
Ein wichtiges Hilfsmittel ist z.B. das »GEM-Programmier-Handbuch« [1] von Philip Balma und William Fitler, zwei ehemaligen Mitarbeitern von »Digital Research«. Neben einigen Lücken und Ungenauigkeiten zum AtariGEM findet man auch sehr viele wertvolle Detailinformationen. Weitere interessante Hinweise findet man in der Original-Dokumentation zum PC-GEM-Entwicklerpaket [2,3]. Diese Dokumente sind allerdings nicht separat erhältlich und somit für die Allgemeinheit nur schwer zugänglich.
Vorbild für GEM war bekanntlich das Betriebssystem des »Apple Macintosh«. So ist es nicht weiter verwunderlich, daß man im »Inside Macintosh« [4] (Kapitel: User Interface Guidelines) sehr viele Hinweise findet, die man problemlos auf GEM übertragen kann (und sollte). Primär sind hier die Vorgaben für Menüoptionen und das Blockkonzept von Interesse. Viel Theorie zur Benutzerführung findet man auch im Werk »Vom Anfänger zum GEM-Profi« [5] von Dieter und Jürgen Geiß. Und schließlich gab es im August 1989 unmittelbar vor der Atari-Messe Düsseldorf ein von Atari Deutschland organisiertes Entwicklertreffen, bei dem es um so verschiedene Dinge wie Standarddateiformate, das »XBRA-Verfahren« (wurde als »offizielle« Methode angenommen), die Handhabung des GEM-Klemmbretts [6, 7] und eben auch um Richtlinien zur GEM-Programmierung ging:
Daß ein »schönes« GEM-Programm natürlich nur ordentlich in Fenster ausgeben darf, ist mittlerweile wohl unumstritten. Viele Programmierer mißbrauchen allerdings den Opcode »WF_NEWDESK« der Funktion »wind_set«. Die Folge: Auf einem Großbildschirm wird oft nur die obere linke Ecke (schlecht!) oder gleich der ganze Bildschirm benutzt (ebenso schlecht). Nur echte GEM-Fenster geben den Benutzern die Flexibilität, die sie brauchen. Visitenkarte eines GEM-Programms sind natürlich die »Drop-Down-Menüs«. Zwei wichtige ergonomische Grundsätze lauten:
Die Reflexe der Anwender müssen geprägt und genutzt werden. Wenn derselbe Menüpunkt immer an derselben Stelle steht, wird man ihn nach kurzer Zeit auch in anderen Programmen ohne nachzudenken finden - man spricht in diesem Zusammenhang auch von »muscle memory«. Wer einmal mit PCGEM gearbeitet hat (dort steht das Accessory-Menü an der anderen Bildschirmecke), weiß, was gemeint ist.
Das menschliche Gehirn kann auf einen Blick nur etwa sieben Objekte gleichzeitig übersehen und erkennen. Daher sollte man nicht zu viele Menüs benutzen und unter Umständen innerhalb der Menüs Funktionsgruppen bilden.
Was für Konsequenzen ergeben sich daraus für die verschiedenen Menüs?
Beginnen wir mit dem ersten Menü. Digital Research hat mit »PC-GEM 2.0« eingeführt, daß dieses Menü immer den Titel des gerade aktiven Programms anzeigt. Dies hat nicht nur juristische Gründe (damals lagen Digital Research und Apple wegen allzugroßer Ähnlichkeiten zum Macintosh-Betriebssystem im Rechtsstreit). Der andere wichtige Aspekt ist, daß so sehr schnell erkannt wird, in welchem Programm man sich gerade befindet. Beim PC-GEM ist dies noch wichtiger, da auch Accessories eine eigene Menüleiste haben können. Der Menütitel gibt also darüber Auskunft, zu welchem Programm das oberste Fenster und damit auch die Menüleiste gehören. Diese auf der Atari-Entwicklerkonferenz als verbindlich festgeschriebene Konvention wird mittlerweile auch meist befolgt.
Das erste Menü trägt den Namen »Datei« und sollte folgende Unterpunkte kennen:
»Neu« öffnet ein leeres Fenster, das zunächst mit »NAMENLOS« bezeichnet ist. Falls mehrere Dokumenttypen möglich sind, muß der Benutzer natürlich zunächst den passenden Typ auswählen.
»öffnen ... « öffnet eine bestehende Datei. Falls der Benutzer in der Dateiauswahlbox den Namen einer nicht vorhandenen Datei angibt, sollte ihm die Möglichkeit zum Anlegen einer neuen Datei unter diesem Namen gegeben werden.
»Schließen« verfährt ebenso mit dem obersten Fenster, ohne zu speichern. Falls Änderungen vorgenommen, aber noch nicht gespeichert sind, fragt das Programm vorher noch einmal nach (»Änderungen verwerfen, speichern oder Abbruch?«).
»Sichern« speichert den aktuellen Zustand. Falls der Fenstertitel noch »NAMENLOS« ist, sollte dieser Menütitel natürlich nicht anwählbar sein.
»Sichern als ... « entspricht »Sichern« mit dem Unterschied, daß der Benutzer zunächst mit Hilfe der Dateiauswahlbox einen neuen Namen eingibt (der anschließend für das Dokument übernommen wird). Eine sinnvolle Erweiterung haben die Programmierer des Texteditors »EDISON« vorgenommen: Wenn gerade ein Block selektiert ist, fragt das Programm, ob nur der Block oder das gesamte Dokument gesichert werden soll.
Hierher würde auch ein Menüpunkt gehören, der in englischsprachigen Programmen üblicherweise »Abandon« oder »Revert to saved« genannt wird. Damit ist gemeint, daß alle Änderungen seit dem letzten Sichern der Datei wieder rückgängig gemacht werden können.
»Drucken« druckt das Dokument im aktiven Fenster aus. Dabei sind natürlich allerlei Variationen (Drucken in Datei, »OUTPUT.APP« starten etc.) möglich.
»Ende« oder »Beenden« ist wohl klar.
Das Menü »Bearbeiten« enthält Befehle, die sich auf das (oder die) gerade ausgewählte(n) Objekt(e) beziehen. Das können in einem Zeichenprogramm ein grafisches Objekt, in einer Tabellenkalkulation einige Zellen, in einem Texteditor ein Textblock sein.
Wie man Objekte auswählt, macht der Desktop bereits vor: einzelne Objekte durch einfaches Anklicken, mehrere Objekte durch Shift-Klick oder die Rubberbox. Eine spezielle Methode zum Auswählen ist das »Echtzeit«-Selektieren. Viele Programme wie »Wordplus«, »Edison« oder »Turbo-C« verfolgen dieses Verfahren. Kernpunkt ist, daß der aktuell ausgewählte Block bereits während der Mausbewegung invertiert wird (um so besser, wenn beim Erreichen des Fensterrandes auch automatisch gescrollt wird). Weitere Varianten erlauben das wortweise Markieren (Markiervorgang mit einem Doppelklick beginnen) und vieles mehr.
Bei Programmen, die diese im »Inside Macintosh« beschriebene Methode konsequent nutzen, gibt es immer nur einen Block oder einen Text-Cursor - nie aber beides gleichzeitig. Das ist kein Fehler, sondern im Konzept dieses Mechanismus begründet: Alles dreht sich um die aktuelle »Selektion« (damit ist der gerade markierte Block gemeint). Der Cursor (besser: die Einfügemarke) ist nur ein Sonderfall eines Blocks (nämlich einer mit der Länge 0).
Auch beim Einfügen gibt es keine Unterscheidung zwischen Blöcken und einzelnen Zeichen (ein Zeichen ist eben ein Block der Länge 1). Der einzufügende Block wird immer anstelle des gerade selektierten Blocks eingesetzt. Anschließend erscheint die Einfügemarke (also der »leere« Block) rechts vom eingefügten Block. Das gesamte Macintosh-Blockkonzept beruht somit auf dem Einfügen und Entfernen von Blöcken: Gute Ideen erkennt man daran, daß sie simpel sind!
Einige »Blöcke«, die man einfügt, haben natürlich besondere Funktionen. »Backspace« und »Delete« löschen den selektierten Block. Falls nichts markiert ist, wird vorher entweder das Zeichen rechts oder links der Einfügemarke selektiert. Ähnlich intuitiv sind auch andere Funktionen wie das Finden von Textstellen (der gefundene Text wird zum aktuell selektierten Block und kann damit direkt überschrieben werden) oder das Löschen von Zeilen (aktuelle Zeile als Block markieren und dann ausschneiden).
Und in diesem Zusammenhang werden auch die einzelnen Menüpunkte von »Bearbeiten« leicht verständlich. »Ausschneiden« entfernt den aktuellen Block und dupliziert ihn in die »Zwischenablage«, einen internen Puffer. »Kopieren« kopiert den selektierten Block in diese Zwischenablage, ohne ihn zu löschen. »Einfügen« plaziert den aktuellen Inhalt der Zwischenablage ins Dokument. »Löschen« löscht den aktuellen Block, »Alles auswählen« selektiert alle Objekte im Dokument. »Undo« schließlich macht die letzte Blockoperation rückgängig.
Die Zwischenablage enthält immer nur den zuletzt hineinkopierten Block. Viele Programme erlauben es, beim Ausschneiden und Kopieren durch Festhalten der Shift-Taste den Block an den Inhalt der Zwischenablage anzuhängen, statt ihn zu ersetzen. Ob die Zwischenablage nun als programminterner Puffer oder direkt über das GEM-Klemmbrett verwirklicht wird, ist zunächst egal. Falls nicht sowieso das GEM-Klemmbrett (also der Weg über Dateien im Scrap-Verzeichnis) benutzt wird - die heutigen schnellen Festplatten machen's möglich - sollte man diesen Weg zumindest zusätzlich anbieten. »Scigraph« beispielsweise bietet für diese Umschaltung den Menüpunkt »Klemmbrett benutzen« an.
Einige Äußerlichkeiten:
Bei der Gelegenheit gleich noch ein paar Hinweise zu Fenstertiteln:
Auch die Tastaturbelegung war ein Thema der Konferenz (Abb. 2). Faustregel sollte sein, daß eine Funktion, so sie vorhanden ist, auch den entsprechenden Shortcut erhält. Ausnahmen sind natürlich möglich: In einem Terminalprogramm braucht man zum Beispiel »Ctrl-S« und »Ctrl-Q« für andere Zwecke. Die Vorschläge für die Cursor-Tasten gelten in erster Linie für Editoren. Für »Page up« und »Page down« definiert das »VDI« übrigens auch eigene Scancodes [8], die man sogar mit einer PC-Tastatur am ST erzeugen kann - sie ebenfalls abzufragen, kann also nicht schaden.
Das Schöne an Standards ist bekanntlich, daß es soviele davon gibt und man sich einen heraussuchen kann. Und so sind die Vorschläge von »IBM« in seinen »SAA-Richtlinien« zwar grundsätzlich ähnlich, im Detail aber eben doch anders. Es gibt einige feste Belegungen der Funktionstasten (zum Beispiel: »F1« Hilfe, »F3« Programm beenden, »Alt-F4« Fenster schließen) und praktische Zuordnungen für die Edit-Funktionen (Ausschneiden: »Shift-Delete«, Kopieren: »Ctrl-Insert«, Einfügen: »Shift-Insert«). Wer diese Tastaturbelegungen zusätzlich anbietet, wird sicherlich »Auch-PC-Benutzer« sehr erfreuen.
(uw)
Quellennachweis:
[1] Philip Balma/William Fitler: »GEM Programmier-Handbuch«, Sybex, Düsseldorf 1987, ISBN 3-88745-692-0
[2] Digital Research Inc.: »Introduction to GEM Programming«, «, Second edition, June 1986
[3] Digital Research Inc.: »GEM Programmer's Utilities Guide«, First edition, June 1986
[4] »Inside Macintosh Volume I-III«., Addison Wesley Publishing Company, Inc., ISBN 0-201-17737-4
[5] Dieter Geiß, Jürgen Geiß: »Vom Anfänger zum GEM-Profi.«, Hüthig, Heidelberg 1990, ISBN 3-7785-1792-9
[6] Julian Reschke: »Ans EinGEMachte«, ST-Magazin 10/1989, Seite 60
[7] Julian Reschke: »Neues von der Zwischenablage.«, ST-Magazin 12/1989, Seite 68
[8] Jankowski/Reschke/Rabich: »Atari ST Profibuch«, Sybex Düsseldorf 1989, ISBN 3-88745-563-0
Abbildung 2. Standard-Tastatur-Shortcuts für GEN-Programme (durch Sternchen markierte Shortcuts sind Vorschläge des Verfassers, alle anderen wurden auf der Entwicklerkonferenz als bindend beschlossen)
Taste Belegung
Ctrl-A Alles auswählen
Ctrl-C Kopieren
Ctrl-F Suchen
Ctrl-G Erneut suchen
Ctrl-M Speichern als
Ctrl-P Drucken
Ctrl-Q Programm beenden
Ctrl-R Ersetzen
Ctrl-S Sichern
Ctrl-U (*) Schließen
Ctrl-V Einfügen
Ctrl-W Fenster blättern
Ctrl-X Ausschneiden
Ctrl-Z Shell starten
Shift-Pfeil-Hoch Eine Seite zurückblättern
Shift-Pfeil-Runter Eine Seite vorwärtsblättern
Shift-Pfeil-Links Cursor an Zeilenbeginn
Shift-Pfeil-Rechts Cursor an Zeilenende
Ctrl-Pfeil-Links Cursor um ein Wort zurück
Ctrl-Pfeil-Rechts Cursor um ein Wort vor
Home Textanfang
Shift-Home Textende
HELP Hilfe anzeigen (möglichst kontextsensitiv)
UNDO Letzte (Block-)Operation rückgängig machen