4/00 4/00
In
unserem Amiga-OS-Kurs in den letzten Ausgaben des AMIGA Magazins wurde gezeigt,
wie man Oberflächen für und mit dem neuen AmigaOS 3.5 programmieren kann. Nun
wollen wir Ihnen zeigen, wie man auch kompatibel zu alten Betriebssystem-Versionen
programmiert.
Bei unserem Kurs zur AmigaOS 3.5 Programmierung [1] wurde stillschweigend davon ausgegangen, daß der Benutzer bereits über die aktuelle Version des Betriebssystems verfügt. Werden die Beispielprogramme unter älteren Versionen gestartet, so erscheint lediglich die Meldung, dass AmigaOS 3.5 benötigt wird. Diese Vorgehensweise ist aber nicht immer von Vorteil oder erwünscht.
Warum Programme
für beide AmigaOS-Versionen erstellen?
|
Lösungsansatz
1: Das Programm unterstützt beide Oberflächen
In diesem Fall wäre sowohl die Oberfläche für das alte, als auch für das aktuelle AmigaOS vorhanden. Das Programm entscheidet zur Laufzeit, welche Oberfläche / Funktionen benutzt werden. Der Vorteil für den Benutzer ist, dass er keine unterschiedlichen Programmversionen hat. Beim Umstieg auf AmigaOS 3.5 präsentiert sich dann automatisch das »alte« Programm im »modernen« Outfit.
Nachteil dieser Methode: Der Programmcode fällt größer aus. Auch die Programmwartung ist aufwändiger, da Ergänzungen bei Bedarf für beide Oberflächen zu erstellen sind. Trotzdem dürften die Vorteile, vor allem aus Sicht des Kunden, deutlich überwiegen!
Lösungansatz
2: Es werden zwei Programme erstellt
|
Welche der beiden Lösungen verwendet wird, bleibt Ihnen überlassen. Wichtig ist jedoch in beiden Fällen, daß sauber zwischen Oberfläche und Funktionalität im Programmcode unterschieden wird. Daraus ergibt sich zumindest eine einfachere Wartung des Sourcecodes. Änderungen der Funktionalität müssen nur ein einziges Mal gemacht werden und stehen doch in beiden Programmversionen zur Verfügung. Bei Änderungen der Oberfläche kann es aber durchaus notwendig sein, beide GUI-Versionen zu aktualisieren (z.B. wenn neue Bedienelemente benötigt werden). Nicht umgehen lässt sich der Testaufwand für beide Programme/Oberflächen.
Natürlich bietet sich hier besonders C++ mit seiner objektorientierten Denkweise an. Jeweils gekappselt in eine eigene Klasse, steht nach »außen hin« das selbe Interface zur Verfügung, wenn von einer gemeinsamen Basisklasse abgeleitet wird. Natürlich ist diese Vorgehensweise auch unter ANSI-C möglich, wobei aber mehr Disziplin vom Programmierer verlangt wird.
Ein Beispiel
aus der Praxis
|
Damit Miami mit steigender Anzahl unterstützter Oberflächen nicht immer größer wird, wird auf das bewährte Library-Konzept zurückgegriffen. Die komplette Oberfläche inklusive deren Messagehandling ist in einer Library untergebracht. Es existiert ein gemeinsames Interface (Funktions-Einsprünge), über dass das Programm mit der Oberfläche »kommuniziert«. Unser Beispiel in diesem Artikel wird nicht so ausgefeilt sein. Es wird einfach per Compiler-Define festgelegt, welche Oberfläche »ausgespuckt« werden soll. Aus den im letzten Kapitel erwähnten Gründen greifen wir auf C++ als Programmiersprache zurück. Alle modernen Compiler (StormC, MaxonC, GnuC) unterstützen die Programmentwicklung in C++. Das Programm dient natürlich nur als Anschauungsgrundlage. Erweiterungsmöglichkeiten wären z.B. die Auswahl der Oberfläche durch den Benutzer. Das setzt natürlich voraus, dass alle GUIs im Programmcode bzw. extern vorhanden sind.
Weitere Aspekte
bei der Entwicklung
Bisher wurde die Programmunterscheidung lediglich aus Blickpunkt der Oberfläche betrachtet. Nimmt man allerdings auch die anderen Unterschiede zwischen AmigaOS 3.1 und 3.5 in Augenschein, so ergeben sich weitere Probleme, die hier allerdings nur kurz angesprochen werden können.
|
Betrachtet man hingegen die Unterschiede in der workbench- und icon. library, muss eine Unterscheidung im Programmcode stattfinden. In der Regel sind die neuen Funktionen nicht in »Allerwelts-Programmen« notwendig. Allerdings ist es natürlich schöner, wenn das Programm sein Konfigfile mit den neuen »GlowIcons« speichert und nicht mit den alten grauen Symbolen. Die Vorgeheisweise hierbei ist allerdings einfach: Statt wie bisher GetDiskObject() aufzurufen, wird die neue Funktion GetIconTagList() dazu verwendet. Damit lädt man das Icon. Das gilt auch bei PutIconTagList() diese Funktion kommt an Stelle von PutDiskObject() zum Einsatz, um das Icon zu speichern.
Andere Funktionen (z.B. icon.library/DrawIconStateA()) zum Zeichnen eines Icons als Image, müssen unter älteren Versionen nachgebildet werden. Also Icon laden, die Imagedaten entnehmen und an intuition.library/DrawIcon() übergeben. In allen Fällen muß die minimale Libraryversion (meist 37 für AmigaOS 2.04 oder 39 für AmigaOS 3.0) geöffnet werden und erst zum Ausführungszeitpunkt die Unterscheidung stattfinden. Das Gerüst in Listing 1 zeigt die Vorgehensweise.
struct Library *IconBase;
struct DiskObject *diskobj;
if(IconBase = OpenLibrary("icon.library",37))
{ if(IconBase->lib_Version < 44)
/* alte AmigaOS-Version */
diskobj = GetDiskObject("dateiname");
else
/* neue AmigaOS-Version */
diskobj = GetIconTagList("dateiname",NULL);
if(diskobj)
{ /* tu was ! */
}
CloseLibrary(IconBase);
}
else
printf("FEHLER: icon.library "
"V37 kann nicht geöffnet werden.\n");
Listing 1: Icons richtig einbinden |
Die Installation
eines gemischten Programms
Abschließend soll noch kurz ein Blick auf die Installation und die dabei notwendige Unterscheidung geworfen werden. Hierbei wird davon ausgegangen, dass der Standard-Installer (bzw. dessen kompatible Äquivalente) eingesetzt werden. Das Erstellen von Installerscripts wurde bereits im Installer-Kurs [2] ausführlich erklärt und hier nur Ausschnittsweise angesprochen.
(if (< (/ (getversion "exec.library" (resident)) 65536)) 37) (abort "Es wird mind. AmigaOS 2.04 benötigt !"). (if (< (/ (getversion "workbench.library") 65536)) 44) (abort "Es wird mind. AmigaOS 3.5 benötigt !"). Bzw. ein "=" Vergleich, wenn genau eine Version zutreffen muß. Listing 2: Ermitteln der vorhandenen OS Version |
(set #OS_Version (/ (getversion "workbench.library") 65536))
(if (< #OS_Version 44) (*installieren Gadtools Oberfläche*)
(*installieren Reaction Oberfläche*)
)
Listing 3: Ermitteln der zu installierenden Version |
Das Beispielprogramm
Als anschauliches Beispiel dient diesmal die Oberfläche für das Perl-Script »txt2pdf« [3]. Damit können einfache Textdateien in das PDF-Format umgewandelt werden. Dieses Format wird vor allem für Druckvorlagen (z.B. von Handbüchern) verwendet. Die aktuelle Version ist unter der URL http://www.sanface.com zu finden.
Wie bereits oben angesprochen, liegen die Oberflächen als einzelne C++-Klassen vor. Anhand der Defines GUI_GADTOOLS und GUI_REACTION wird definiert, welche Oberfläche das erzeugte Programm verwenden soll; bzw. sind beide Defines gesetzt, kann der Benutzer die Oberfläche auswählen oder wird automatisch beim Programmstart ermittelt. Durch einfaches Hinzufügen weiterer Defines und C++-Klassen können auch andere Oberflächen, z.B. MUI oder BGUI, eingebunden werden.
|
Auf die Erstellung der »modernen« Reaction-Oberfläche wurde bereits im ersten Teil des Inspektor-Gadget-Kurses [1] eingegangen und auf deren Programmierung im zweiten Teil [4]. Die zutreffenden Programmteile sind in der myGUI_Reaction-Klasse enthalten. Sie unterstützen neben der Größenänderung des Fensters auch die neue Iconify-Funktion. Bei der GadTools-Umgebung wurde auf die Nachbildung der Iconify-Funktion verzichtet. Zumindest für das eigentliche Iconify-Image gibt es bereits eine fertige BOOPSI-Klasse im Aminet (s. Kasten »Online-Ressorucen«). Das eigentliche Fenster schließen und AppIcon für die Workbench erzeugen, müsste dann noch ergänzt werden. Die einzelnen Dateien sind natürlich mit den aktuellen Include-Dateien des AmigaOs-3.5-DevPack zu kompilieren. Als Basisklasse dient myGUIClass, welche fünf virtuelle Funktionen enthält. Dadurch könnten z.B. Gemeinsamkeiten aller GUIs bereits in der Basisklasse behandelt werden. In unserem Beispiel ist die Basisklasse leer, und nur die Ableitungen enthalten die Funktionalität. Im Kasten »Die Basis-Klasse« finden Sie eine kurze Vorstellung der fünf Funktionen und ihre Funktionsweise.
Hinweis: Das Programm enthält teilweise doppelt ausgeführte Teile! Hier
ist es in der Praxis empfehlenswert, eine zusätzliche Datei zu erzeugen und
dort die Funktionen unterzubringen, die von allen Oberflächenmodulen benutzt
werden können (z.B. die Menü-Behandlung). Das Programm und den Sourcecode finden
Sie auf der Homepage des Autors. Sollten Fragen zum Artikel oder dem Programm
auftreten, können Sie sich gerne per E-Mail
(michael@meicky-soft.de)
an den Autor wenden.
|
© 2000 All Rights Reserved. Alle Rechte vorbehalten Franzis' Verlag GmbH Kommentare, Fragen, Korrekturen und Kritik bitte an Webmaster AMIGA schicken.
Zuletzt aktualisiert am 01. Juni 2000 und 03. Juni 2006, Michael Christoph.
