ACS pro - Der„Easy Way“ der Programmentwicklung

Mit ACS erhält man ein Tool, das in der Hauptsache zwei Probleme abdecken soll: Erstens werden auch Programmierer, die nicht über fundierte Kenntnisse des Betriebssystems und besonders der Fähigkeiten des GEM verfügen, in die Lage versetzt, vollständige GEM-Anwendungen zu erstellen, die nicht nur professionell aussehen, sondern es auch sind.

Bisher waren die Voraussetzungen dafür möglichst über Jahre gesammelte praktische Erfahrung im Umgang mit GEM und eine möglichst umfangreiche und leistungsfähige Toolbox. Seit ACS pro 2.0 ist die mit Abstand schwerwiegendste Anforderung ein Budget von 398,- DM. Und zusätzlich sollte man natürlich Herr seiner C- bzw. Pascalorientierten Gedanken sein, mit anderen Worten, man muß eine dieser Sprachen beherrschen.

Zweitens kann man sich die Zeit sparen, das Rad zum x-ten mal zu erfinden, und sich stattdessen auf das Wesentliche einer Anwendung konzentrieren. Das senkt - bei kommerzieller Programmentwicklung -die Kosten und natürlich auch das Fehlerrisiko. Außerdem ist es unwahrscheinlich, daß es jemand schafft, die gesamte Fenster-, Dialog- und Menüumgebung eines Programmes innerhalb von weniger als 2 Tagen von Hand zu programmieren - zumindest nicht, ohne irgendwann einmal verfaßte Geistesblitze zu nutzen, denn deren Entwicklungszeit zählt mit.

Was dem NeXT recht ist

Was hat denn der NeXT-Computer mit ACS zu tun? Eine ganze Menge! Die Vorgeschichte: Als Steve Jobs 1988 seinen Cube der Öffentlichkeit präsentierte, staunten nämlich nicht nur die Software-Käufer über die leistungsfähige neue Benutzeroberfläche „NeXTstep“, sondern im besonderen die Programmierer. Denn es gehörte zu den Grundideen dieses Computers, dem Software-Hersteller die Entwicklung von Programmen unter dieser neuen Oberfläche so angenehm und einfach wie möglich zu machen. „Interface Builder“ hieß das Zauberwort, und dahinter verbarg sich ein Entwicklungspaket, wie es bis dahin noch nie dagewesen war und mit dem Programme aller Art zu einem großen Teil „gemalt“ werden konnten. Nein, nicht nur die Dialoge und die Menüs, sondern die halbe Anwendung entstand so. Für alle, die diesem Interface Builder noch nie begegnet sind, will ich einmal an einem kurzen Beispiel den Unterschied zwischen Programmieren und Malen erklären:

Sicher haben die meisten Leser dieses Artikels schon einmal ein kleines oder auch größeres GEM-Programm geschrieben. Nehmen wir nun an. Sie möchten, daß in Ihrem Programm der Menüpunkt „INFO“ angewählt wird, und daraufhin soll eine Dialogbox erscheinen mit irgendeinem Inhalt. Die Vorgehensweise sieht dann etwa so aus:

Das ganze wird natürlich begleitet von etlichen Kleinigkeiten wie Maus ausschalten, Maus einschalten, BEGUPDATE, ENDUPDATE und so weiter und so fort. Nun das gleiche mit dem „Interface Builder“:

Das war’s schon. Interface Builder weiß nun alles, was er wissen muß, um daraus ein lauffähiges Programm zu generieren -ohne eine einzige Zeile Sourcecode.

Bei NeXT versprach man sich von diesem Konzept die Halbierung der Entwicklungszeit kommerzieller Programme, und das zurecht: Das Verfahren ist einfach und genial. Ganze Texteditoren waren als Baustein verfügbar und konnten bei Bedarf in die eigenen Programme eingebunden werden. und außer den Software-Entwicklern von NeXT kennt praktisch niemand Details zum Neuzeichnen der Fenster - wozu auch? Sich darum zu kümmern, war von Anfang an ausschließlich Aufgabe des Interface Builders und des Betriebssystems. Was unter GEM auf ATARI-Computern alltäglich und des Programmierers notwendiges Übel war, die Feinheiten des Systems nämlich, wurde von den Experten bei den NeXT-Entwicklerschulungen nur unter schwerster Folter preisgegeben. Derlei Kleinkram zu wissen, war einfach unnötig.

Warum ACS?

So gesehen hat es erstaunlich lange gedauert, bis endlich jemand auf die Idee kam, dieses Konzept auf den ATARI zu bringen - das Betriebssystem hat ja im Grunde nichts gegen derartige Vereinfachungen.

Was den ATARI auszeichnet, ist nicht zuletzt die übersichtliche und einfach zu bedienende Oberfläche GEM, die sich mit ihren Eigenschaften und Fähigkeiten durchaus nicht hinter vergleichbaren Oberflächen zu verstecken braucht. Programme unter GEM zu erstellen, hat einige Vorteile und (fast) keine Nachteile. Zugegeben, viele Programmierer haben im Laufe der Zeit an GEM herumgearbeitet, beschleunigt oder sogar eigene Kreationen zum besten gegeben, hauptsächlich, weil sie mit der Verwaltung der wahrscheinlich wichtigsten GEM-Elemente, der Fenster, wenig oder überhaupt keine Erfahrung hatten. Denn was sich für den Endverbraucher als Bedienungskomfort darstellt, ist für die Programmierer eine lästige und nicht ganz einfache Arbeit, und damit ist (war?) die Zahl derer, die mit Begriffen wie „Message-System“, „GEM-Ereignis“ oder „Fenster-Redraw“ etwas anfangen und, vor allem, das auch in die Tat Umsetzen können, gering.

Aber spätestens seit es Systeme wie den TT oder den Falcon030 gibt, mußten viele der GEM-Aussteiger feststellen, daß ihr über alles geliebtes Programm auf diesen Rechnern nicht läuft - nicht zuletzt, weil beim Entwurf der eigenen Oberfläche die neuen Bildschirmmodi nicht berücksichtigt wurden. Also beißt man in den sauren Apfel. Findet GEM plötzlich schön (warum auch nicht?) und schreibt zukünftige Anwendungen unter GEM.

Das ACS-Desktop

Das Ei des Kolumbus

Jetzt liegen also zwei Konzepte vor, die es zu verbinden und miteinander in Einklang zu bringen gilt: Das wiedergefundene GEM. an dem auch ich trotz jahrelanger Praxis immer wieder neue Eigen-, Fein-und Schönheiten entdecke, und die bei NeXT entstandene Methode der redundanzarmen und damit einfachen und schnellen Programmentwicklung. Nun also endlich zu dem Programm selbst.

Der Builder

Ebenso wie die mit ACS pro erzeugten Applikationen setzt sich auch der Application-Builder selbst aus vier Grundbausteinen zusammen:

  1. dem Desktop, das, mit diversen Icons ausgestattet, die Bedienung des Programms vereinfacht
  2. den Fenstern, in denen ALLE Bildschirmausgaben (Texte und Grafiken im weitesten Sinne) und, mit Ausnahme einiger weniger modaler Dialoge, auch diese untergebracht sind
  3. den anwendungsspezifischen Funktionen (die des ACS selbst sind natürlich nicht offengelegt, schließlich will der Autor noch was verdienen!)
  4. den externen Modulen

Bei 4. handelt es sich um eine Neuerung von ACS pro. Dabei steht es dem jeweiligen Programmierer frei, eine vollkommen autarke Anwendung zu schreiben, ein Basismodul sozusagen, oder ein externes Modul, das sich bei den Standardfunktionen wie Fensterverwaltung der Funktionen des Basismoduls bedient. Man könnte also z.B. ein absolut funktionsloses Programm als Programm-Shell erstellen, um die aufwendige Verwaltungsarbeit für viele kleine Anwendungen nur einmal zentral zu verrichten. Dem ACS liegen zahlreiche solcher Module bei, beispielsweise ein kompletter Texteditor. Einmal geladen, wird der Editor selbst und jeder in Bearbeitung befindliche Text durch ein Icon auf dem Desktop repräsentiert. Wird ein Modul oder eines seiner Produkte (z.B. ein Text) nicht mehr benötigt, zieht man das zugehörige Icon in den Papierkorb und der veranschlagte Speicherplatz wird wieder freigegeben. Ein weiteres sehr nützliches Modul im Lieferumfang ist der sogenannte „Imageviewer“, mit dem Grafiken im IMG-Format geladen und auf einfachste Weise in einer Dialogbox plaziert werden können. Praktisch alle beigefügten Module liegen auch im Sourcecode vor, so daß sie als Lehrmaterial verwendet oder auch einfach modifiziert werden können.

Definition eines Fensters

Fensterln ohne Leiter

Wie bereits angedeutet, liegt das Hauptaugenmerk bei ACS auf der Gestaltung, Erzeugung und Bearbeitung von Fenstern. Ohne ein komfortables Werkzeug wie ACS pro hat man sich nunmal um alles selbst zu kümmern. Da muß auf Benutzeraktionen richtig reagiert werden (wie z.B. Schließbox angeklickt, Slider bewegt...), da müssen Teile des Fensterinhaltes neugezeichnet werden etc. ACS macht das alles automatisch. Bereits bei der Definition der Fenster wird festgelegt, von welchem Typ das Fenster ist, was genau passiert, wenn ein Fenster geöffnet oder geschlossen wird, ob und wenn ja welche zusätzlichen eigenen Funktionen bei Fensteraktionen wie Scrollen, Verschieben, Verkleinern, Vergrößern usw. angesprochen werden sollen. Für den Programmierer stellt sich im weiteren dieses Fenster nur noch durch seine Definition in Form einer Struktur dar (also für den C-Programmierer ein Struct, für den Pascal-Programmierer ein Record), und alle künftigen Änderungen und Aktionen werden entweder vollautomatisch oder über diese Struktur getätigt. Für eventuelle eigene Funktionen innerhalb des Verwaltungsapparates werden fertige Funktions- bzw. Prozedurskelette erzeugt, die dann „nur“ noch mit den gewünschten Aktionen gefüllt werden müssen. Eine recht einfache Geschichte also. Die Definition eines Fensters beinhaltet neben diesen zusätzlichen Funktionen, wie eben erwähnt, auch den Typ eines Fensters. Allgemein hat ein Fenster immer ein GEM-Objekt zum Inhalt. Um dieses möglichst effizient zu verwalten, ist es ratsam und mitunter auch notwendig, dieses GEM-Objekt etwas näher zu spezifizieren. „Text“ kann zum Beispiel eines sein, die Darstellung eines Bildes, eine nichtmodale Dialogbox etc. Und es gibt noch einige sehr spezielle Fälle, Listenfenster etwa. Ein Beispiel für ein solches Listenfenster ist ein Verzeichnisfenster auf dem normalen GEM-Desktop. Der Inhalt eines Listenfensters wird immer so dargestellt, daß die Horizontale möglichst optimal genutzt wird, d.h. daß wenn überhaupt, vertikal gescrollt werden muß. Eine weitere Spezialität sind Protokollfenster, die, wie der Name schon sagt, für Protokollausgaben da sind. Damit lassen sich auch größere Protokolle im Auge behalten, da man sich in einem Fenster, im Gegensatz zum TOS-Bildschirm, frei bewegen kann. In Abbildung 2 wird gezeigt, wie eine Fensterdefinition vonstatten geht. Die Vielzahl der Eingabemöglichkeiten (die nicht alle wahrgenommen werden müssen!) läßt erahnen, daß trotz aller Vereinfachungen nichts an Flexibilität eingebüßt wird.

ACS = RCS?

Nein. Das ACS ist kein Resource Construction Set, und es beinhaltet dem Sinn nach auch keins. Natürlich kann man, auf ähnliche Art und Weise wie in einem RCS üblich, seine Dialoge und Menüs entwerfen, aber diese werden nicht als separate Dateien abgelegt, sondern sie sind Teil des Ganzen, werden also ebenso wie Quelltextsegmente in die gesamte Applikation integriert. Damit die Arbeit der letzten Jahre nicht völlig umsonst war, können auch bereits erstellte Resource-Dateien geladen und quasi als Ersatzteillager verwendet werden. ACS ist im Konzept objektorientiert. Eine Anwendung oder ein Teil einer Anwendung ist ein Objekt mit ganz besonderen Eigenschaften, und zu diesen zählen Datenbereiche aller Art, Eingaben, Ausgaben und eben auch die Beschreibung der äußeren Erscheinung des Objekts, also der Dialoge, Menüs und was eben so dazu gehört.

Wie man in Abbildung 3 erkennen kann, ähnelt die Erzeugung eines Objektbaumes der mit einem RCS. Objekte werden im „Drag and Drop“-Verfahren aus der Teilebox entnommen und im Dialog plaziert. Jedoch sind in der ACS-Teilebox Elemente enthalten, die ein RCS überhaupt nicht bieten kann, da sie normalerweise nicht ohne Programmtext möglich sind. Von den in dem abgebildeten Beispieldialog verwendeten Elementen ist nur der Knopf mit der Beschriftung „Button“ ein einfaches Objekt. Der Text „So wollte ich“ ist eine einzige Zeile, die je nach Höhe und Breite dieses Objektes automatisch umgebrochen wird. Auch der kleine Kasten mit der Aufschrift „rot“ hat es in sich: Dahinter verbirgt sich ein komplettes Menü, wie es aus den Kontrollfeld-(CPX)-Modulen bekannt ist. Und auch die Bemaßungslinie ist EIN Objekt. Aber es gibt noch mehr.

Ein Blick auf die Referenzenliste

Die eigene Anwendung

Wie oben erwähnt, baut ACS auf einem ebenso einfachen wie vielseitigen Desktop auf, das auch automatisch an eigene Entwicklungen weitergereicht wird - komplett mit Menüleiste, ACS-Infobox und allen Fähigkeiten, wie z.B. der, Module nachladen zu können. Will man auf das Desktop verzichten oder es durch etwas Eigenes ersetzen, muß dieser Wunsch explizit geäußert werden. Wer jetzt sagt, daß in vielen Anwendungen die Modultechnik nicht notwendig sei und daher der Speicherplatz eingespart werden könne, den muß ich enttäuschen. Ob verwendet oder nicht, die Standardfunktionen sind immer vorhanden.

Eigentlich wollte ich an dieser Stelle anhand einer Beispielanwendung die Funktionsweise von ACS demonstrieren, aber: Ein „Hello World“ besteht im wesentlichen aus einer wahllos gemalten Dialogbox und ca. 25 Zeilen Source-Text. Deren Inhalt sind

Was an include-Dateien für „C“ bzw. Pascal benötigt wird, erzeugt ACS auf Knopfdruck. Fazit: Die detaillierte Beschreibung einer Programmentwicklung macht nur bei etwas größeren Programmen Sinn und würde dann den Rahmen dieses Testberichts sprengen. Die Aufgaben des Programmierers beschränken sich fast ausschließlich auf die programmspezifischen Funktionen. Vielseitigkeit in eigenen Programmen wird eben durch die einfach zu handhabende Vielseitigkeit von ACS erreicht, und nicht durch umständliches Entwickeln, oder anders formuliert: Die Arbeit ist die gleiche, die auch beim Programmieren ohne ACS gemacht werden muß, nur geht es mit ACS wesentlich einfacher, wesentlich schneller und trotzdem gehaltvoller.

Eine Besonderheit muß unbedingt erwähnt werden. Bei der Kurzbeschreibung des „Interface Builder“s von NeXT habe ich die Verbindung zweier Objekte mittels eines Striches genannt. Das ist nicht ganz vollständig, denn zu einer solchen Referenzierung gehört neben der Verbindung selbst noch eine Aktion. Wie bereits erwähnt, ist das Konzept bei ACS wie bei NeXT objektorientiert, und zwischen Objekten gibt es keine Verbindung in dem Sinn. Aber ein Objekt kann einem anderen eine Nachricht senden, die im wesentlichen aus dem Adressaten und der eigentlichen „Message“ besteht. Dieses Nachrichtensystem ist etwas umfangreicher als das Messagesystem des AES, welches nur über Ereignisse informiert, also praktisch nur die Ursache für eine mögliche Aktion nennt. Eine Objektmessage kann aber durchaus die gesamte Aktion beinhalten. Beispiel: „Prozeß xy“ (Adressat): „Schreibe in Dein Textfeld ... den Text ...“ (Message). Eine solche Nachricht ist nichts anderes als ein Funktionsaufruf; für Standard-Messages gibt es in der Regel auch fertige Standardfunktionen, kompliziertere müssen erstellt werden. Das heißt, eine Referenzierung besteht aus

Trägt man nun im ACS zu einem Objekt ein Referenzobjekt ein, nimmt ACS diese Verbindung automatisch in die Liste der Referenzierungen auf und erzeugt dabei auch gleich das Gerüst für die Nachrichtenfunktion. Dieses Gerüst kann nun bei Bedarf, also komplexerem Informationsaustausch, mit Programmcode ergänzt werden. Auch hier wird also der Aufwand auf ein Minimum beschränkt. Abbildung 4 zeigt die Liste der Referenzen und eine bereits leicht veränderte Referenzfunktion.

Konstrukt eines Objektbaumes

Schmankerl am Rande

Sicherlich Finden viele das neue Outfit des Falcon030 sehr ansprechend. Gemeint sind im Besonderen die 3dimensional dargestellten Fensterelemente und Buttons. ACS bietet dieses 3D-Gefühl auch für TOS-Versionen < 4.0 und geht dabei sogar noch etwas weiter. So lassen sich z.B. zudem ganz einfach optische „Höhenunterschiede“ in Dialogboxen einbringen, wie sie von der NeXT-Oberfläche her bekannt sind. Solche 3D-Effekte sind zwar nicht unbedingt jedermanns Geschmack, aber wer’s mag ...

Ohne Handbuch keine Chance

Angesichts der Fülle von Möglichkeiten, die einem mit ACS pro offen stehen, ist man ohne die 300seitige Bibel im Taschenbuchformat tatsächlich verloren. Das gut illustrierte und übersichtlich gegliederte Nachschlagewerk enthält neben einer ausführlichen Einführung in die Funktionsweise von ACS und den Richtlinien für eigene Entwicklungen (etwa 100 Seiten) den unverzichtbaren Referenzteil für die einzelnen Funktionen, die ACS zur Verfügung stellt (der Rest). Obwohl sich 200 Seiten Referenz nach viel anhören, können gerade diese Funktionsbeschreibungen nicht ausführlich genug sein. Bei einigen Funktionen jedenfalls fällt die Dokumentation etwas knapp aus. Selbiges gilt für das Stichwortverzeichnis, das zwar alle Funktionen enthält, dafür aber manchen allgemeinen Begriff vermissen läßt. Alles in allem ist das Handbuch leicht verständlich und enthält alles Notwendige. Eine ganze Kleinigkeit vielleicht noch, die aber nichts mit dem Inhalt des Handbuches zu tun hat. Ich persönlich fände aus verschiedenen Gründen eine Ringbuchlösung praktischer, nicht zuletzt, weil sich häufig benutzte Taschenbücher erfahrungsgemäß nach relativ kurzer Zeit in Wohlgefallen auflösen.

Voraussetzungen

ACS pro setzt als Minimalkonfiguration 512 KB und eine doppelseitige Floppy voraus. Aber ACS pro ist ein Werkzeug für Programmierer, und damit ist die SINNVOLLE Minimalkonfiguration viel RAM und viel Festplatte. Wer also mit ACS pro nicht nur spielen, sondern arbeiten will, kommt um entsprechende Hardware nur schwer herum. Und wer dabei richtig glücklich werden will, dem sei noch etwas geraten. Angesichts der - durchaus berechtigten - Fenster- und Icon-Flut im ACS werden Programmierer, die nur 640 mal 400 Pixel ihr eigen nennen, möglicherweise mehr oder weniger schnell Platzangst kriegen. Ein Großbildschirm ist da eine echte Wohltat, aber natürlich nicht notwendig.

Kosmetik?

Angesichts immer größer werdender RAM- und Festplattenkapazitäten kann man innerhalb eines gewissen Rahmens durchaus mal etwas großzügiger mit Speicherplatz umgehen. Die unsinnige Byte-Fuchserei sollte mit dem Zeitalter der 8-Bit-Rechner mit 1 KB RAM beendet sein. Wer große oder zahlreiche oder zahlreiche große Programme betreiben möchte, muß einfach einsehen. daß Rechnerkapazitäten von 0,5 MB ebenso überholt sind wie Benzinmotoren mit 7 Liter Hubraum und 30 Litern Durchschnittsverbrauch. ACS-Erzeugnisse bewegen sich eben noch innerhalb dieses Rahmens, d.h., ein funktionsloses Programm, das alle Fähigkeiten und notwendigen Funktionen beinhaltet, ist knapp 60 Kilo schwer. Auf den ersten Blick reichlich. Aber zwei Dinge müssen hierbei bedacht werden: Zu diesen 60 KB gesellen sich in einer Anwendung nur noch die programmspezifischen Funktionen. Erstens. Und zweitens gibt es da ja auch noch die Möglichkeit der Modularisierung, und da die Module auf alles verzichten. was in diesen 60 KB enthalten ist, fallen sie entsprechend kleiner aus. So liegt die Größe des gesamten Texteditors mit all seinen Funktionen bei ca. 50 KB. der Image-Viewer und der Taschenrechner liegen jeweils um 10 KB. Man muß Prioritäten setzen können.

Fehler? Natürlich: Nobody’s perfect, wie der Lateiner sagt. ACS macht da sicherlich keine Ausnahme. Will man die oben erwähnte Möglichkeit nutzen, auf das Standard-Desktop von ACS in eigenen Applikationen zu verzichten, kann es kleine Probleme geben. Das Desktop selbst ist schnell eliminiert und eigene Ideen ebenso schnell verwirklicht. Nur gab es kleine Probleme bei dem Versuch, über die neue Menüleiste einen eigenen Programminfo-Dialog anzuzeigen. Die bombige Quittung läßt zumindest vermuten, daß das nicht ganz so einfach ist. Ein weiteres Problem ergab sich in Verbindung mit dem neuen SpeedoGDOS. Ich bin jedoch sicher, daß es sich bei den von mir gefundenen Fehlern - sofern die Schuld überhaupt bei ACS liegt (GDOS? Ich??) - um Kleinigkeiten handelt, die im nächsten Update verschwunden sind. Der Programmierer versprach mir, sich sofort der Sache anzunehmen und ggf. für Abhilfe zu sorgen.

Unterm Strich ist ACS für ein Programm dieser Größe und Komplexität ausgesprochen fehlerfrei, was auf eine einwandfreie und gut durchdachte Programmierung schließen läßt.

Der Predigt End'

Allen, die GEM-Anwendungen programmieren (wollen) und ihre Zeit sinnvoll nutzen wollen (wenn z.B. im Sommer der Teich gar mächtig zum Bade lockt!), sei ACS pro wärmstens empfohlen.

Allen, die gegen Stundenlohn programmieren: Besser, Ihr habt nie etwas von ACS gehört.

Allen, die in BASIC programmieren und immer etwas neidisch auf die „C‘- und Pascal-Programme geschielt haben: Ihr seid zurecht neidisch.

Aus presserechtlichen Gründen sind wir zu folgendem Hinweis verpflichtet MAXON Computer als Herausgeber dieser Zeitschrift ist gleichzeitig Vertrieb des beschriebenen Programmes ACS pro.

Literatur:
ST-Computer 3, 4, 5, 6/92

Bezugsquelle:
MAXON Computer
Industriestr. 26
W-6236 Eschborn (ab 1.7. neue PLZ: 65734)

Positiv:

leicht erlernbares, übersichtliches Programm
100% GEM-konform, ohne Tricks und Anabolika
umfangreiche Toolbox

Negativ:

bisher nur für C und Pascal


Volker Stamme
Aus: ST-Computer 07 / 1993, Seite 32
Links
Copyright-Bestimmungen: siehe Über diese Seite