Anderer Arbeit Lohn: »GL« - GEM-Library für Pure C und Pascal

Wieso soll man jedesmal das Rad neu erfinden, wenn sich andere darüber schon den Kopf zerbrochen haben« Gleiches gilt natürlich für die GEM-Programmierung, wenn es um die Oberflächengestaltung und die hierfür notwendigen Funktionen geht.

Da sich weder die Firma Atari noch die Compiler-Anbieter anschicken, die Oberflächenprogrammierung durch etwas mächtigere Funktionen zu vereinfachen, widmen sich inzwischen zahlreiche Fremdanbieter diesem Manko. Nicht zuletzt wegen der unterschiedlichen Atari-Rechnerplattformen (ST, STE, TT, Falcon) - kombiniert mit allerlei Grafikkarten in jeder nur erdenklichen Bildschirmauflösung - hat auch der letzte »Quick-and-Dirty-Programmierer« eingesehen, daß man an der viel zitierten »sauberen GEM-Programmierung« nicht vorbeikommt. Diese Erkenntnis hat zu einem wahren Boom von erweiterten GEM-Bibliotheken geführt. Eine recht erfolgsversprechende Bibliothek steht hier zum Test an. Die »GL« genannte Bibliothek erinnert vom Namen her zwar eher an die einfallslose Typbezeichnung einer Automarke; bei einer genaueren Analyse stellt man aber schnell fest, daß wohl alle Kreativität in den Aufbau der Bibliothek floß.

Zweisprachig

Beim Auspacken fällt zunächst das üppige, gut 170 Seiten starke Handbuch (DIN A5-Ringbuch) auf, und man vermutet eine besonders große Auswahl an Funktionen oder aber eine besonders detaillierte Funktionsbeschreibung. Doch weit gefehlt. Die Beschreibung der Funktionen beschränkt sich auf etwa 80 Seiten, dafür aber gleich in zweifacher Anfertigung: einmal für die Pascal- und einmal für die C-Version der Bibliothek. Weil der Funktionsumfang der beiden Versionen identisch ist, unterscheidet sich die Dokumentation lediglich bei den Beispiel-Listings, die jeweils in der entsprechenden Syntax aufgeführt sind. Somit hebt sich der Umfang dieser Dokumentation nicht von der anderer GEM-Bibliotheken ab. Dennoch ist das Handbuch für jeden, der sich schon einmal mit GEM befaßt hat, und hier über eine weitere Referenz verfügt, ausreichend. Obwohl Index und Schnelleinstieg enthalten sind, bleiben des öfteren Fragen bei der Verwendung der GL-Funktionen offen.

Erfreulich ist, daß der Name »GEM-Library« für dieses Paket wirklich gerechtfertigt ist, denn diese Bibliothek beschränkt sich nicht nur auf das An- und Abmelden einer GEM-Applikation und Funktionen zur einfachen Verwaltung von Dialogen, sondern automatisiert die komplette Fensterverwaltung inklusive der Event-Behandlung.

Ohne daß es im Handbuch explizit erwähnt wurde, fällt auf, daß die meisten Funktionen zweistufig arbeiten. Die erste Stufe beschränkt sich nur auf das allernötigste, was die diversen Übergabeparameter der Funktionen betrifft. Hier benutzt die Bibliothek nur die Default-Werte. Möchte man hingegen mehr Einfluß auf das Verhalten der Funktionen ausüben, benutzt man einfach weitere Konfigurationsfunktionen. Diese Vorgehensweise erlaubt einen raschen Aufbau eines GEM-Programmes, in dem sich dann im Nachhinein noch spezielle Wünsche aufnehmen lassen, ohne deswegen die komplette Programmstruktur ändern zu müssen.

Als Beispiel seien hier die Funktionen »Init_GEM()« und »Exit_GEM()« genannt. Ohne sich hier mit lästigen Parametern, Konfigurationen oder ähnlichem herumschlagen zu müssen, übernehmen diese Funktionen das komplette An- und Abmelden beim GEM.

Ob das Programm nun als Accessory oder als Applikation gestartet wurde, interessiert ebensowenig wie das VDI-Handle der virtuellen Workstation. Stellt man zu einem späteren Zeitpunkt fest, daß man doch noch eigene VDI-Ausgaben benötigt, lassen sich im Nachhinein alle benötigten Systemparameter mit der Funktion »GetParameter()« erfragen.

Ein kleines Programmbeispiel veranschaulicht, wie einfach man eine Applikation mit einer Menüzeile und einem Dialog schreibt:

OBJECT *menue, *dialog; int done = 0;
int DoMenu( int msg, WINDOW_INFO *inf )
{
	if ( msg == wMenu ) 
	  switch{ inf->mItem )
	 {
	 default:
	 case QUIT: done = 1; break; 
	 case DODIALOG: if ( DoDialog( dialog, 0 ) == DIALQUIT )
		done = 1; 
		break;
	 }
	return ( TRUE );
}
int main( void )
{
	if ( Init_GEM() )
	{
		if ( LoadRsc( name ) )
		{
			menue = RscAdr( R_TREE, MENUE ); 
			dialog= RscAdr( R_TREE, DIALOG ); 
			SetDeskTopMenu( menue, DoMenu ); 
			while ( !done )
				HandleEvents();
			RscFree();
		}
		Exit_GEM();
	}
	return ( 0 );
}

Natürlich ist damit die Bibliothek noch lange nicht ausgereizt, aber für die gleiche Aufgabe würde man ohne GL bestimmt vier bis fünf Quelltextseiten benötigen.

Im einzelnen lassen sich die Funktionen in sieben Gruppen einteilen:

Die »Managementfunktionen« übernehmen das An-und Abmelden des GEM, sowie das Laden der Resource-Dateien. Außerdem steht hier eine Art »atexit«-Funktion bereit, die allerdings auf GEM-Ebene arbeitet. Eine weitere Routine installiert einen eigenen Desktop.

Für die komplexeste Aufgabe, die »Ereignisverwaltung«, ist lediglich der Aufruf einer Funktion (ohne Parameter) nötig. Diese regelt dann alles weitere. An dieser Stelle soll aber nicht verschwiegen werden, daß eine andere oder weiterführende Behandlung der Ereignisse nur schwer zu realisieren ist. Wollte man zum Beispiel die Mausform innerhalb eines Fensters ändern, je nachdem an welcher Stelle sich die Maus gerade befindet, hat man schlechte Karten, da das Ereignis »die Maus hat sich bewegt« bei GL nicht vorgesehen ist. Eine derartige Funktion müßte man um die GL-Ereignisverwaltungsfunktion herumprogrammieren, was dann, wegen des großen Aufwands, natürlich den ganzen Nutzen der GL-Funktionen in Frage stellt.

Die Funktionen zur Dialogverwaltung lassen hingegen keine Wünsche offen. Hier hat sich unter den verschiedenen GEM-Libraries schon fast ein Standard herausgebildet. Eine dieser Funktionen übernimmt die komplette Dialogführung. Diese positioniert dann den Dialog, stellt die Grow- und Shrink-Boxen dar, zeichnet den Dialog, übernimmt die Benutzereingaben und räumt hinterher wieder alles ordnungsgemäß auf. Als Rückgabewert erhält man wie gewohnt die Nummer des Objekts, mit dem der Dialog verlassen wurde. Über globale Parameter läßt sich noch einstellen, ob der Dialogbildschirmmittig oder in der Nähe der Maus positioniert werden soll.

GL wäre keine konkurrenzfähige GEM-Library, wenn hier nicht auch erweiterte Objekte angeboten würden, wobei die Erweiterung sowohl die grafische Darstellung wie auch die Funktionalität betrifft. Neben dem Eselsohr (für verschiebbare Dialoge), dem ankreuzbaren Knopf, dem Mac-Radio-Button (jeweils mit Shortcut-Funktion über die ALTERNATE-Taste) und Titelrahmen in verschiedenen Formen, lassen sich auch Textzeilen mit den wichtigsten Textattributen (hell, fett, unterstrichen) darstellen.

Die Funktionen »ShowDialogO«, »HandleDialog()« und »EndDialog()« ermöglichen die Behandlung von Dialogen mit mehreren EXIT- oder TOUCHEXIT-Objekten, ohne jedesmal den Dialog verlassen zu müssen. Auf diese Weise realisiert man zum Beispiel Slider in Dialogen.

Dazu wird HandleDialog() aufgerufen, und der Dialog bei einem Mausklick auf den Slider (TOUCHEXIT-Objekt) verlassen. An dieser Stelle setzen noch selbstgeschriebene Funktionen zur Silderbewegung ein. Ist die Sliderverschiebung abgeschlossen, möchte man normalerweise den Dialog nicht direkt verlassen, und ruft deshalb HandleDialogO ein weiteres Mal auf.

HandleDialog() entspricht also weitgehend der AES-Funktion »form_do()«, bis auf die Tatsache, daß der GL-Pendant zusätzlich Shortcuts interpretiert und die Eingabe in Edit-Feldern wesentlich komfortabler von der Hand geht (Cut, Copy, Paste über Clipboard und Cursor zu Zeilenanfang und -ende bewegen).

Ebenso einfach lassen sich Dialoge in Fenster legen, wobei diese sich auf Wunsch weiterhin modal verhalten (die Applikation kann erst fortfahren, wenn der Dialog wieder geschlossen wurde). Unter MultiTOS sollten beinahe alle Dialoge in Fenstern liegen, da nur so gesichert ist, daß andere parallel laufende Programme Zugriff auf ihre Fenster haben, also nicht mit der Programmausführung warten müssen, bis der Dialog geschlossen wurde. Allerdings ist es für den Anwender oft verwirrend, wenn er zu einem Programm mehrere Dialoge gleichzeitig bedienen muß oder auch nur bedienen kann. Deshalb erlaubt GL auf Wunsch nur Eingaben in das aktuelle Fenster und verhindert einen Fensterwechsel innerhalb der Applikation. Damit wird der Anwender gezwungen, den obersten Dialog abzuschließen, sprich das Fenster zu schließen, bevor er mit dem Programm fortfahren kann.

Die Fensterverwaltung beschränkt sich allerdings nicht nur auf das Einbinden von Dialogen. So übernimmt die Bibliothek auch die komplette Verwaltung von Fenster-eigenen Menüzeilen. Weiter stehen diverse Funktionen zur Fensterausschnittbehandlung nach folgendem Konzept bereit:

Ein Fenster stellt in der Regel nur einen Ausschnitt eines Dokumentes dar, weil das Dokument beliebig groß sein darf, das Fenster sich hingegen an der Bildschirmgröße orientieren muß. Mit dem horizontalen und dem vertikalen Slider bestimmt man den Ausschnitt des Dokuments, der im Fenster anzuzeigen ist. Also übergibt man die Größe des Dokuments (in Pixeln) und die Position und Größe des Fensters an GL. Desweiteren benötigt GL noch eine Funktion, die einen bestimmten Ausschnitt des Dokuments an eine bestimmte Stelle auf dem Bildschirm zeichnet. Den Rest übernehmen dann die GL-Funktionen. Ob nun seiten- oder zeilenweise gescrollt wird oder ob das Fenster verschoben oder verkleinert wird, alle diese Aufgaben übernehmen die GL-Funktionen. Sie berechnen den neuen Dokumentausschnitt sowie die Sliderposition und -größe.

Desweiteren stellt die GEM-Library eine eigene Alert-Funktion bereit, die bis zu 16 Zeilen und maximal vier Buttons unterstützt. Zusätzlich lassen sich hier Texte mit verschiedenen Textattributen darstellen und die Buttons via Shortcuts bedienen.

Eine Pop-Up-Funktion darf natürlich auch nicht fehlen. Dieser übergibt man ein Objekt und die Position (wahlweise die aktuelle Mausposition) und erhält dann die Nummer des Objekts, mit der das Pop-Up verlassen wurde. Verschachtelte Pop-Ups sind nicht vorgesehen. Außerdem wäre ein scrollbares Text-Pop-Up, wie es das CPX-Modul oder das neue AES des Falcon bereitstellt, wünschenswert.

Zu guter Letzt erhält man noch tatkräftige Unterstützung seitens GL, wenn es um das Verschieben oder Sichern eines Bildschirmausschnittes geht.

Weitere Funktionen zum Verändern der Mausform und der Objekt- Flags und States erhöhen nur noch formell die Anzahl der Bibliotheksfunktionen, da die entsprechenden AES-Funktionen auch nicht komplizierter zu bedienen sind.

Der insgesamt klar strukturierte Aufbau der GL-Bibliothek (was nicht unbedingt auf die Namensgebung der Funktionen zutrifft), reduziert die Einarbeitungszeit enorm und sorgt nebenbei für relativ kurze Quelltexte. Die prinzipiellen Nachteile einer GEM-Bibliothek lassen sich auch mit GL nicht ausräumen. So ist man zum Beispiel darauf angewiesen, sich ein neues Update zu besorgen (vorausgesetzt es gibt ein solches), wenn Atari wie zuletzt bei der neuen AES-Version neue Funktionen oder zumindest neue Messages einführt und man diese im eigenen Programm unterstützen will. (ah)

WERTUNG

Name: GL
Preis: 149 Mark
Hersteller: Neuman - Seidel Gbr

Stärken: Kurze Einarbeitungszeit □ einfacher Aufbau □ erweiterte Objekte □ automatische Fenster- und Event-Behandlung □ User-Help für Pure C und Pascal

Schwächen: Fehlender Zugriff auf die Event-Behandlung □ knappe Dokumentation □ keine weiteren VDI-Funktionen

Fazit: Sehr einfach zu handhabende GEM-Bibliothek für kleine bis mittelgroße Programme. Für den Hausgebrauch uneingeschränkt zu empfehlen.

Jürgen Lietzow

---

---