Benny Kannengiesser - Lehrstuhl Algorithmen & Datenstrukturen ...

D I P L O M A R B E I T
Implementierung des AOF-Viewers auf
dem Macintosh PowerPC
von
Benny Kannengießer
eingereicht am 13.4.99 beim
Institut für Angewandte Informatik
und Formale Beschreibungsverfahren
Universität Karlsruhe
Betreuer und Gutachter:
Prof. Dr. Hartmut Schmeck (Universität Karlsruhe),
Prof. Dr. Thomas Ottmann (Universität Freiburg),
Dr. Jennifer Lennon (University of Auckland)

Heimatanschrift:
Fr.-Ebert-Str.4
67346 Speyer
2

Inhaltsverzeichnis
1 Einleitung . . . . . . . 4
2 Authoring on the fly . . . . . 5
2.1 Vorlesungen und neue multimediale Techniken . 5
2.2 Das Authoring-on-the-fly-Prinzip . . . 6
2.3 Werkzeuge . . . . . . . 7
2.3.1 Whiteboard . . . . . . 7
2.3.2 Aufnahme- und Wiedergabeumgebung . . 8
2.3.3 Editor . . . . . . . 8
2.4 Abspielen von Animationen und Simulationen . 9
2.5 Aufzeichnung und Synchronisation der Datenströme 9
2.5.1 Audiodatenstrom . . . . . 9
2.5.2 Whiteboarddatenstrom - Eventqueue und Objectlist .
10
3 Der AOF-Viewer . . . . . . 12
3.1 Die Module . . . . . . . 12
3.1.1 aofSync . . . . . . 12
3.1.2 wbPlay . . . . . . 14
3.1.3 appPlay . . . . . . 15
3.2 Synchronisation . . . . . . 16
4 Portieren des AOF-Viewers auf Apple PowerPCs 19
4.1 Ausgangspunkt . . . . . . 19
4.2 Compiler und Gerät . . . . . 19
4.3 Beibehaltene Prinzipien . . . . . 19
4.4 Änderungen und Anpassungen für die Macintosh-Version 20
4.4.1 Programmierung der Graphischen Benutzeroberfläche 20
4.4.2 Kommunikation zwischen den Modulen . . 21
4.4.3 Starten der Helfer-Anwendungen . . . 22
4.4.4 Gestaltung der Fenster . . . . 22
3

4.4.5 Macintosh-Dateisystem . . . . 24
4.4.6 Abspielen der Audiodatei . . . . 25
4.4.7 Einlesen der Bilder . . . . . 27
4.4.8 Zeichenkommandos . . . . . 27
4.4.9 Flackerfreies Zeichnen . . . . 28
4.4.10 Öffnen eines AOF-Dokuments . . . 28
4.4.11 Ladevorgang . . . . . 28
4.4.12 Steuerung von Animationen durch das appPlay-Modul 29
4.4.13 Schriftsatz-Problem . . . . . 30
4.4.14 Zeichensatz . . . . . . 31
4.4.15 Bildschirmgröße . . . . . 32
4.5 Macintosh-Besonderheiten . . . . 32
4.5.1 Dateien . . . . . . 32
4.5.2 Icons . . . . . . . 32
4.5.3 Menüs . . . . . . 33
4.6 Vorteile der Macintosh-Version des AOF-Viewers . 35
4.6.1 Graphik . . . . . . 35
4.6.2 Menüs . . . . . . 35
4.6.3 Icons . . . . . . . 35
4.7 Nachteile der Macintosh-Version . . . 35
5 Beurteilung der portierten Version. . . 37
6 Literaturverzeichnis . . . . . 38
7 Anhang . . . . . . . . 41
4

1 Einleitung
Thema dieser Diplomarbeit ist die Portierung des Authoring-on-the-fly-Viewers auf
die Apple-Macintosh-Plattform (Power PC).
Authoring-on-the-fly (AOF) ist ein Projekt [AO99] des Instituts für Informatik der
Universität Freiburg. AOF wurde entwickelt, um das Unterrichten an Universitäten
multimedial zu unterstützen. Es soll neue, multimediale Techniken mit
konventionellen Vorlesungsmethoden kombinieren. Mit den AOF-Werkzeugen
gehaltene Vorlesungen können live an andere Orte übertragen, aber auch
aufgezeichnet und von Studenten z.B über das Internet heruntergeladen und
nachträglich verfolgt werden. Zum Betrachten einer solchen Vorlesung ist der
AOF-Viewer erforderlich. Er wurde ursprünglich für Unix-Plattformen entwickelt
(so wie auch die AOF-Aufnahmeumgebung) und existiert seit kurzem auch in einer
Windows-Version. Im Zuge der weiteren Verbreitung der AOF-Software, die durch
geplante virtuelle Universitäten sicherlich bald beschleunigt wird (z.B. die Virtuelle
Universität Oberrhein [VirW]), regte Herr Prof. Ottmann eine Portierung der
Viewer-Software auf den Macintosh an. Dies gab den Anstoß zu vorliegender
Diplomarbeit.
Bei der Portierung wurden Teile des Originalcodes (geschrieben von Christian
Bacher, Rainer Müller, Gabriela Maass und Andreas Reichle am Institut für
Informatik der Universität Freiburg) von der Unix- und der Windows-Version
unverändert übernommen. Diese Teile machen etwa ein Drittel des Macintosh-
Programmcodes aus.
Die eigentliche Entwicklung der Macintosh-spezifischen Programmteile fand an der
University of Auckland (Neuseeland), Hypermedia Unit, und am Institut für
Mikrosystemtechnik, Mikrosystem-Simulation, Universität Freiburg, statt. An
dieser Stelle sei den verantwortlichen Professoren Frau Dr. Lennon und Herrn Prof.
Korvink mein herzlicher Dank für ihre unkomplizierte Unterstützung vor allem in
Form von Gerät und Software ausgesprochen. Ebenfalls zu Dank verpflichtet bin
ich den Mitarbeitern und Assistenten an diesen genannten Instituten, die mich bei
der Programmierung mit den Macintosh-Eigenheiten vertraut machten. Mein
besonderer Dank geht an Gabriela Maass und Rainer Müller vom Institut für
5

Informatik, Universität Freiburg, für die unermüdliche Beantwortung meiner
programmtechnischen Fragen.
6

2 Authoring-on-the-fly
2.1 Vorlesungen und neue multimediale Techniken
In ”konventionellen” Vorlesungen an einer Universität - zumindest im Bereich der
Informatik - legt der Vortragende vorbereitete Folien auf einen Overheadprojektor,
schreibt oder zeichnet erklärende Anmerkungen auf die Folien oder mit Kreide an
die Tafel und kommentiert mündlich. Von weiteren - multimedialen - Techniken,
die heutzutage Computer bieten, wird nur selten Gebrauch gemacht (“so stellt man
fest, daß sicherlich 95% des Unterrichts nach wie vor in der traditionellen Form
erfolgen, das heißt im Frontalunterricht ohne Medienunterstützung oder mit Tafel
und Kreide”[BMO97, S.1]).
Neue technische Errungenschaften bieten heutzutage jedoch schon andere Formen
der Wissensvermittlung. Genannt seien hier z.B das Abspielen von Filmen und
Audiosequenzen, das Verwenden von Hypertextfunktionen, das Vorführen von
Simulationen und Animationen, um abstrakte Zusammenhänge zu verdeutlichen,
oder das Einbinden von elektronischen Büchern. Die Akzeptanz dieser neuen
Techniken ist, zumindest im universitären Bereich, relativ gering.
Auch die immer weiter schreitende Vernetzung durch multimediale Netzdienste
(z.B. Internet und ISDN) wird kaum ausgenutzt. Dabei ist es schon lange möglich,
entsprechend aufgezeichnete Vorlesungen mit Teleteaching-Werkzeugen einem
größeren und entfernteren Publikum zugänglich zu machen. So wäre es auch nicht
mehr notwendig, daß sich Vortragender und Zuhörer zeit- und ortsgleich
zusammenfinden, um einen bestimmten Vortrag zu hören bzw. zu halten. Vorträge
könnten zudem, zusätzlich zu ihrer Live-Übertragung an entfernte Zuhörer, in
einem multimedialen Dokument aufgezeichnet und in einer Art elektronischen
Vorlesungsbibliothek verfügbar gemacht werden, so daß sich Studenten auch
nachträglich, zur Wiederholung oder Vorbereitung auf Prüfungen, bestimmte
Vorlesungen anschauen könnten.
Die Gründe für die zu beobachtende schleppende Umstellung auf die neuen
Techniken müssen jedoch auch berücksichtigt werden. So ist es z.B. nicht
garantiert, daß neue Techniken die Wissensvermittlung unbedingt erleichtern.
7

Vielleicht sind Tafel und Kreide in manchen Bereichen immer noch die
effizienteste Methode, bestimmte Themen Studenten zugänglich zu machen.
Finanzielle Hürden sind ebenfalls nicht zu unterschätzen. Ein wichtiger Grund mag
außerdem sein, daß ein Vortragender vielleicht nicht unbedingt von zu vielen
technischen Hilfsmitteln abhängig sein möchte. Des weiteren kostet der Gebrauch
zusätzlicher Techniken natürlich mehr Vorbereitungszeit pro Vorlesung.
Hier setzt der AOF-Ansatz an:
2.2 Das Authoring-on-the-fly-Prinzip
Das Authoring-on-the-fly-Prinzip (kurz AOF) wurde am Institut für Informatik der
Universität Freiburg entwickelt[AO99]. Es geht davon aus, daß die vorherig
erwähnte mangelnde Akzeptanz neuer multimedialer Vorlesungstechniken nur
dadurch verbessert werden kann, wenn bewährte, traditionelle Lehrverfahren und
Arbeitsweisen so weit es geht beibehalten werden. Ein ”radikaler Bruch mit der
traditionellen Form der Hochschullehre” [BMO97; S.1] soll vermieden werden.
Neue multimediale Techniken sollen ”die spezifischen Stärken des traditionellen
Unterrichts erhalten” und ”kontinuierlich um neue Möglichkeiten erweitern”
[BMO97; S.1].
Konkret bedeutet die Umsetzung dieses Prinzips folgendes:
Statt Tafel und Kreide benutzt der Vortragende eine elektronische Tafel
(Whiteboard) und einen speziellen Stift, mit dem er genauso agieren kann wie
bisher auf der traditionellen Tafel gewohnt. Statt Folien, Texte und Bilder auf den
Overheadprojektor aufzulegen, werden die gleichen Dokumente vorher in dieses
Whiteboard geladen und bei Bedarf abgerufen und angezeigt. Die Folien können
mit dem elektronischen Stift graphisch bearbeitet werden. Der Dozent startet bei
Bedarf elektronische Animationen, Simulationen und Videofilme.
Als Whiteboard wurde zunächst das der MBone-Teleteaching-Umgebung [ErH94]
verwendet. Dank der Multicastfähigkeit können so die Vorlesungen live (online) an
andere Orte (Rechner oder Großbildschirme) übertragen werden. Das MBone-wb
(Whiteboard) erlaubt das Laden von Postscript-Dateien, Vor- und Zurückblättern in
8

den Folien sowie das Markieren und Zeichnen auf diesen. Seine Fähigkeiten sind
jedoch beschränkt, weshalb ein verbessertes Whiteboard entwickelt wurde, auf das
im nächsten Abschnitt eingegangen werden soll.
Während dem Halten der Vorlesung werden gleichzeitig Stimme und
gegebenenfalls auch ein Abbild (Videofilm) des Dozenten übertragen und
aufgezeichnet. Die Vorlesung selbst findet wie gewohnt im Hörsaal statt. Studenten
sind anwesend und können selbstverständlich auch Fragen stellen, auf die der
Dozent eingehen kann. Sämtliche Aktionen auf dem Whiteboard werden nicht nur
übertragen, sondern auch aufgezeichnet und mit dem Audio- und gegebenenfalls
Videostrom synchronisiert (siehe Abschnitt “Synchronisation” im nächsten
Kapitel). Eine so aufgenommene Vorlesung kann dann auf einem Multimediaserver
abgelegt werden, und Studenten können, mit einem viewer ausgestattet, die
Vorlesung (offline) auch nachträglich verfolgen.
Auf die beschriebene Weise werden tradtionelle Vorlesungstechniken beibehalten,
multimedial unterstützt und um neue Möglichkeiten erweitert. Dabei dient das
Whiteboard dem Dozenten als ”Interaktionsmedium, das die traditionelle Form der
Lehre mit unserem neuen Ansatz und seinen Möglichkeiten vereint” [BMO97; S.4].
Der Name ”Authoring on the fly” wurde gewählt, um zu verdeutlichen, daß bereits
während dem Halten der Vorlesung – also ”on the fly” – ein Multimedia-Dokument
erstellt wird.
2.3 Werkzeuge
Ausgehend von dem oben beschriebenen Ansatz, multimedial unterstützte
Vorlesungen mit den MBone-Werkzeugen zu halten, wurden einige
Verbesserungen für das Authoring-on-the-fly an der Universität Freiburg
entwickelt.
2.3.1 Whiteboard
Sehr wichtig für die Qualität einer multimedialen Vorlesung sind die Fähigkeiten
des Whiteboards. Das am Anfang verwendete Whiteboard wb [ErH94] von MBone
9

ietet zwar mehr Präsentationsmöglichkeiten als eine konventionelle Tafel/Kreide-
Vorlesung, auch erlauben die Multicastfähigkeiten ein Teleteaching über Distanz;
jedoch zeigte sich im Betrieb, daß noch einige Verbesserungen wünschenswert
wären, und zwar sowohl was das Vorbereiten als auch das eigentliche Vortragen
einer Vorlesung betrifft.
Das ”AOFwb” wurde entwickelt. Es vereint Fähigkeiten des MBone wb und
ähnlicher Software, wie z.B. Showcase, xfig, TeX, powerpoint., mit zusätzlichen
Möglichkeiten. So können mit dem AOFwb Bilder in den unterschiedlichsten
Formaten geladen und angezeigt werden, gezeichnete Objekte gruppiert und Folien
und Objekte auch nachträglich (während der Rechnervorlesung) manipuliert
werden. Des weiteren wurde der “Telepointer” eingeführt (vergleichbar einem
Zeiger, den der Dozent freihändig bewegt, um auf bestimmte Objekte zu zeigen).
Ein eingebauter Formeleditor dient dazu, Formeln in TeX während der
Vorbereitung zu schreiben und dann bei der Vorlesung abzurufen und zu plazieren.
Bilder können sowohl im Hintergrund als auch im Vordergrund gezeigt werden.
Video- und Audiosequenzen sowie Animationen und Simulationen können
ebenfalls vorbereitend geladen und bei Bedarf live gestartet werden.
Desweiteren wird versucht, das AOFwb so weit wie möglich in die MBone-
Umgebung zu integrieren, um die Teleteaching-Fähigkeiten beizubehalten.
2.3.2 Aufnahme- und Wiedergabeumgebung
Um Vorlesungen mit den AOF-Werkzeugen zu halten, wird eine spezielle
Aufnahme- und Wiedergabeumgebung benutzt, die ”AOFshell”. Sie stellt ein
komplexes, erweiterbares System verschiedener Softwarekomponenten dar. Die
AOFshell, für die im Moment zwei UNIX-Workstations benötigt werden, integriert
Audiostrom (und gegebenenfalls Videostrom), Whiteboardaktionen und das Starten
der Animationen zu einem einzigen AOF-Dokument.
2.3.3 Editor
Mit dem AOF-Editor können AOF-Dokumente, also bereits aufgezeichnete
Vorlesungen, nachträglich bearbeitet werden. Live aufgenommene Vorlesungen
10

sind zwar erfahrungsgemäß so gut, daß keine Nachbereitung erforderlich ist, und
kleine Fehler sollten nicht sonderlich stören, ”sondern einer solchen Vorlesung eher
eine persönliche Note geben” [BMO97; S.6]. Jedoch möchte man manchmal
bestimmte Abschnitte herausschneiden, um das Dokument kompakter zu machen.
Darunter fallen Sprechpausen, Versprecher (die z.B von
Spracherkennngsprogrammen auch automatisch gefunden werden könnten), das
versehentliche Auflegen falscher Folien während dem Vortrag oder auch das
Verschreiben des Vortragenden auf dem Whiteboard.
Herkömmliche Editoren für Audio- und Videoströme können nicht verwendet
werden, weil die Synchronisation der Ströme mit dem Whiteboardaktionsstrom
erhalten bleiben muß. So soll z.B. durch das Herausschneiden eines Versprechers
keine Aktion auf dem Whiteboard verloren gehen.
Ein Editor, der diesen Anforderungen genügt, wurde am Institut für Informatik der
Universität Freiburg ebenfalls entwickelt [MaG96]. Er läuft zur Zeit nur auf
SGI/Irix-Systemen und erlaubt oben erklärtes Herausschneiden von Abschnitten
mit Erhaltung der Synchronität. Whiteboardaktionen können mit dem Editor
zeitlich ”hin- und hergeschoben” werden, um oben beschriebene unerwünschte
Effekte beim Herausschneiden von kurzen Abschnitten zu vermeiden.
2.4 Abspielen von Animationen und Simulationen
Animationen mit ihren zugehörigen Werkzeugen stehen mittlerweile für eine
Vielzahl von Bereichen für den Unterricht zur Verfügung. Da die meisten bisher
aufgezeichneten AOF-Vorlesungen das Thema ”Algorithmen und Datenstrukturen”
betrafen, boten sich die Animationswerkzeuge ”XTango” [StJ92] (neuere
Versionen ”Polka”[ StJW] und ”Zeus”[BrM91]) an. Mit ihnen können
implementierte Algorithmen visualisiert werden.
Es stellt sich die Frage der Kontrolle der Animationen. Sollen sie einseitig vom
Vortragenden kontrolliert werden oder soll eine gewisse Interaktivität zum
Studenten hergestellt werden? Bei den bisherigen Entwicklungen für den AOF-
Viewer wurde auf die Interaktivität der Animationen beim Abspielen von
11

Vorlesungen verzichtet. Sie ist jedoch grundsätzlich mit oben genannten
Werkzeugen möglich und pädagogisch sicherlich sinnvoll. Studenten könnten z.B.
Parameter der visuell dargestellten Algorithmen eigenhändig verändern. Die vom
AOF-Viewer dargestellten Animationen beschränken sich darauf, im richtigen
Moment gestartet und gestoppt zu werden. Eventuell vorhandene Parameter haben
die gleichen Werte wie in der Live-Vorlesung. Erwähnt sei an dieser Stelle, daß
XTango und auch seine neueren Versionen nur auf Unix- und WindowsNT-
Plattformen laufen. Die Konvertierung in Quicktime- oder MPEG-Filme (Moving
Picture Expert Group) ist für eine Darstellung auf dem Macintosh notwendig.Das
beansprucht natürlich auch mehr Speicherplatz.
2.5 Aufzeichnung und Synchronisation der Datenströme
Da bei bisher aufgenommenen Vorlesungen eine Videoaufnahme des Vortragenden
nur in Ausnahmefällen als wichtig erschien, soll bei den folgenden Ausführungen
nicht auf den Videodatenstrom eingegangen werden.
2.5.1 Audiodatenstrom
Der Audiodatenstrom, d.h. im Normalfall die (digitalisierte) Stimme des
Vortragenden, wird im AIFF-Format (Audio Interchange File Format) oder AIFC-
Format (Audio Interchange File Format Extension for Compression) aufgezeichnet.
Eine Kompression ist im AIFC-Format möglich. Eine (unkomprimierte) Audiodatei
hat typischerweise eine Größe von bis zu 40MB für eine einstündige
Universitätsvorlesung.
Da der Audiodatenstrom die zeitlich genaueste Auflösung besitzt, wird er zur
Synchronisation der restlichen Datenströme benutzt und daher als ”Master”-
Datenstrom bezeichnet. Die zeitliche Auflösung ist deshalb so genau, weil die
analogen Audiosignale digitalisiert, d.h. in bestimmten Zeitabständen abgetastet
und in diskrete Werte umgewandelt werden. Für eine ausreichende Tonqualität ist
eine Abtastfrequenz von 8000 Hz erforderlich.
12

2.5.2 Whiteboarddatenstrom - Event Queue und Object List
Die Whiteboarddaten werden in zwei getrennten Dateien während dem Vortrag
abgespeichert.
Jedes auf dem Whiteboard während der Vorlesung gezeichnete Objekt (z.B. eine
Linie, ein Rechteck, ein Punkt oder ein Buchstabe) wird mit seinen Daten (z.B. bei
einer Linie ihre Dicke sowie Start- und Endkoordinate) in einer Liste, der ”Object
List” abgelegt. In dieser Liste werden die Objekte numeriert und ihre Daten
gespeichert. Jedes Objekt ist so anhand seiner Nummer eindeutig identifizierbar.
In einer weiteren Datei, der ”Event Queue”, sind für jeden Zeitpunkt (zeitlich
aufsteigend geordnet) die Nummern der Objekte aufgeführt, die gerade zu diesem
Zeitpunkt auf dem Whiteboard sichtbar sind.
Bild 1: Object List und Event Queue (aus [BaM, S.3])
Diese Zeitpunkte werden auch als ”Timestamps” bezeichnet. Der Abstand zwischen
zwei Timestamps ist üblicherweise der Zeitabstand zwischen zwei Veränderungen
auf dem Whiteboard.
Für jeden beliebigen, gegebenen Zeitpunkt kann auf diese Weise sofort festgestellt
werden, welche Objekte auf dem Whiteboard gerade zu sehen sind, und zwar
unabhängig von der Kenntnis, welche Objekte zu vorherigen Zeitpunkten zu sehen
waren (diese Fähigkeit wird auch ”random-access” - Fähigkeit genannt).
Wenn ein Objekt längere Zeit zu sehen ist, taucht seine Nummer in mehreren,
zeitlich aufeinander folgenden Timestamps auf. Man spricht von ”overlapping
objects”.
13

Bild 2: overlapping Timestamps (aus [BaM, S.3])
Ein Abspielgerät muß erkennen können, ob Objekte von einem zum nächsten
Zeitpunkt ”überlappen”, und soll diese dann nicht neu auf den Bildschirm zeichnen.
Die oben erwähnte random-access-Fähigkeit erlaubt schnelles Vor- und
Zurückspulen in einem AOF-Dokument oder Springen an bestimmte Stellen im
Dokument. Die Darstellung der Whiteboardaktionen in Event Queue und Object
List ermöglicht dem Zuschauer so ein komfortables Navigieren im Dokument. Die
random-access-Fähigkeit erlaubt technisch erst die Synchronisation des
abzuspielenden Whiteboardaktionsstroms in Abhängigkeit von anderen
Datenströmen, sprich dem Audiodatenstrom.
14

3 Der AOF-Viewer
3.1 Die Module
Der AOF-Viewer soll eine Wiedergabe eines aufgezeichneten AOF-Dokumentes
ermöglichen. Vorgaben beim Entwurf (der ersten Version für Unix) waren einfache
Bedienbarkeit für den Benutzer sowie für die Entwickler eine robuste und
gleichzeitig flexible Programmstruktur mit der Möglichkeit von Erweiterungen und
Neuerungen.
Ein wichtiges Prinzip des AOF-Viewers ist daher seine Modularität. Der Viewer
soll die verschiedenen Datenströme, aus denen ein AOF-Dokument besteht,
darstellen. Für jeden dieser Datenströme ist ein eigenes Programmmodul zuständig.
Programmtechnisch bedeutet dies, daß ein Modul eine eigenständige, auch allein
lauffähige Anwendung darstellt. Die Module müssen im simultanen Betrieb
untereinander kommunizieren, um die Synchronisation der Datenströme zu
gewährleisten.
3.1.1 aofSync
Das aofSync-Modul stellt das Hauptmodul des Viewers dar. Es ist für das
Abspielen des Audiodatendstromes zuständig. Der Audiodatenstrom besitzt unter
allen darzustellenden Datenströmen die zeitlich genaueste Auflösung und wird
deshalb zur Synchronisation der restlichen Datenströme (Whiteboarddatenstrom,
eventuell Videodatenstrom sowie Start- und Endpunkte der Animationen) benutzt.
Man spricht von einer Master-Slave-Synchronisation, wobei das aofSync-Modul
den Master darstellt. Die anderen Module werden als Helfer bezeichnet ([BaM],
S.4).
15

Bild 3: aofSync-Fenster (Unix-Version)
16

Zum aofSync-Modul gehört das Kontrollfenster (Bild 3), anhand dessen der
Benutzer das Abspielen eines Dokumentes steuern kann.
Die Navigation in einem geöffneten (geladenen) Vortrag erfolgt mit Hilfe des Startund
Stopknopfes. Für schnelles Vor- und Zurückspulen im Vortrag klickt der
Benutzer einfach auf den Skalenzeiger , der die aktuelle Position im Dokument
anzeigt, und zieht diesen an die gewünschte Stelle. Sobald auf den Skalenzeiger
geklickt wird, wird der Ton des Vortrages abgeschaltet, bis der Spulvorgang
beendet ist. Während dem Spulen werden jedoch jederzeit alle Whiteboardaktionen
(siehe folgenden Abschnitt ”wbPlay”) angezeigt. Diese Tatsache stellt eine
wichtige Navigationshilfe dar. Will der Benutzer z.B. an den Beginn eines
bestimmten Abschnitts im Vortrag springen, zieht er den Skalenzeiger einfach so
lange in die entsprechende Richtung, bis die entsprechende Folie auf dem
Whiteboard zu sehen ist (”visible scrolling”).
Durch die “Zoom-In”- und “Zoom-Out”-Kontrollknöpfe kann die angezeigte
zeitliche Auflösung der Skala verändert werden. Das ermöglicht ein genaueres
Spulen. Will der Benutzer in “eingezoomten” Zustand weiterspulen als der gerade
angezeigte Zeitbereich der Skala es zuläßt, so zieht er den Skalenzeiger einfach an
den Skalenanschlag. Sobald der Skalenzeiger den (linken oder rechten) Anschlag
berührt, fängt die Zeitskala unter dem Zeiger an, sich zu bewegen (solange die
Maus gedrückt bleibt) und setzt so den Spulvorgang fort. Die Geschwindigkeit, mit
der sich die Skala bewegt, kann vergrößert werden, indem der Benutzer versucht,
den Zeiger aus der Skala nach links bzw. nach rechts ”herauszuziehen”.
Das Zählwerk zeigt die aktuelle Position im Dokument auf Millisekunden genau an.
Daten des Vortrags, wie Titel, Autor und Länge, werden im unteren Fensterbereich
dargestellt. Bei Bedarf kann dieser untere Bereich durch Drücken des ”More”-
Knopfes erweitert werden, um weitere Daten anzuzeigen (Datum der Aufnahme,
letzte Änderungen, Kommentar).
Mit dem “Quit”-Knopf wird die aofSync-Anwendung beendet und eventuell
laufende Helfer-Module ebenfalls.
Die Auswahl des zu öffnenden AOF-Dokumentes wird in der Unix- und Windows-
Version mit der Kommandozeilentechnik durchgeführt, d.h. beim Starten des
17

aofSync-Moduls wird diesem in der Kommandozeile Name und Pfad der zu
öffnenden AOF-Datei übergeben.
Unmittelbar nach dem Starten werden dann die oben beschriebenen Daten der
Vorlesung von der AOF-Datei geladen, angezeigt, die Audiodatei geöffnet und die
im Vortrag benötigten Helfer-Module gestartet.
18

3.1.2 wbPlay
Das wbPlay-Modul ist für die Anzeige des Whiteboardaktionsstroms zuständig. Am
linken Rand des wbPlay-Fensters deutet ein Zeiger auf die aktuelle Position im
Dokument.
Bild 4: wbPlay -Fenster (Unix-Version)
19

Wird dieses Helfer-Modul vom aofSync-Modul gestartet und ihm von letzterem
Name und Pfad der Eventqueue- und Objectlistdatei mitgeteilt, öffnet es diese, lädt
sie in den Speicher und erstellt aus beiden eine verkettete Liste. Alle zum Vortrag
gehörenden Folien (bisher meistens im GIF-Format vorliegend) werden in Bitmaps
umgewandelt und ebenfalls im Speicher abgelegt. Die zwei aufgeführten Vorgänge
können bis zu mehreren Sekunden Zeit beanspruchen. Aus diesem Grund wird für
jeden der Ladevorgänge in einem eigenem Anzeigefenster der aktuelle Stand des
Ladevorgangs angezeigt (“progressbar”). In der Unix- und der Windowsversion
sind diese Anzeigefenster des Ladevorgangs eigenständige, wenn auch kleine
Anwendungen. Trotzdem wurden sie hier nicht als Modul des AOF-Viewers
aufgeführt, weil sie erstens nur sehr kurz beim Ladevorgang in Erscheinung treten
und zweitens bei der Macintosh-Version keine eigene Anwendung darstellen (siehe
Abschnitt ”Ladevorgang” im entsprechenden Kapitel).
3.1.3 appPlay
Das appPlay-Modul ist ebenfalls ein Helfer-Modul und für das Starten und
Beenden von Animationen zuständig. Bisher wurden nur (XTango-)Animationen
und MPEG-Filme gestartet, theoretisch können jedoch beliebige Anwendungen
gestartet und gestoppt werden, die dann ein bestimmtes Dokument öffnen und
anzeigen. Zum appPlay gehört ein kleines Anzeigefenster mit Skala und Zeiger.
20

Bild 5: appPlay-Fenster (Unix-Version) und laufende XTango-Animation (Türme
von Hanoi)
Die zeitlichen Positionen und Längen der Animationen eines Vortrages sind durch
dunkelgrüne Balken neben der Zeitskala des appPlay-Fensters dargestellt. Je länger
eine Animation, desto dicker ihr Balken. Wird während dem Abspielen des
Vortrages eine Animation gestartet, leuchtet der entsprechende Balken hellgrün auf,
bis die Animation stoppt.
Das appPlay-Modul kann außerdem das Spulen beeinflussen. Beendet der Benutzer
nämlich ein Vor- oder Zurückspulen in einem Zeitbereich zwischen Start und Ende
einer Animation, springt die Datenposition (aller Module) automatisch an den
Anfang der Animation, in der das Spulen beendet wurde. Diese Eigenschaft wird
durch Kontrollsignale ermöglicht, die zwischen den Helfer-Modulen (in diesem
Fall dem appPlay) und dem aofSync-Modul gesendet werden können (s. Abschnitt
”Synchronisation”).
Programmtechnisch baut der appPlay beim Starten seine eigene Liste aus Start- und
Endzeitpunkten von Animationen auf.
21

Das eigentliche Starten der Animationen während dem Betrachten einer Vorlesung
(im Normalfall Starten des XTango-Players, der eine bestimmte Animation
abspielt) geschieht bei der Unix-Version durch Öffnen von Dateien, in denen
Skripte (Unix-Kommandozeilen) stehen, die ausgeführt werden. Da Macintosh-
Computer keine Kommandozeilentechnik kennen, mußte das Starten von
Animationen hier anders durchgeführt werden.
3.2 Synchronisation
Wie vorher schon ausgeführt, müssen die verschiedenen Datenströme, aus denen
ein AOF-Dokument besteht (Audio, eventuell Video, Whiteboardaktionen, sowie
Animationskontrollkommandos), synchronisiert werden. Jeder dieser –
zeitabhängigen und simultan darzustellenden - Datenströme ist ”randomaccessible”,
d.h. der Inhalt des Datenstroms kann zu einem beliebigen Zeitpunkt
unabhängig von seiner Vorgeschichte bestimmt werden. Einer der Datenströme ist
der ”Master Stream”, die restlichen sind die ”Slave Streams”.
Die Synchronisationsform des AOF-Viewers wird als ”Master-Slave-
Synchronization” [BaM, S.4] bezeichnet. In dieser Synchronisationsform werden
die Slave-Datenströme nicht nach einer zeitlich konstant laufenden Uhr
synchronisiert, sondern nach dem Master-Datenstrom. Der Master-Strom ist in
kleine, gleichlange Blöcke unterteilt. Dadurch erhält man Timestamps, die zur
Synchronisation benutzt werden. Immer wenn ein Block des Master-Stroms
komplett abgespielt wurde, wird nach dem entsprechenden Timestamp (oder dem
nächstkleineren) in sämtlichen Slave-Datenströmen gesucht und die Daten, die zu
diesem Zeitpunkt gehören, dargestellt. Das ist nur möglich, wenn die Slave-
Datenströme random-accessible sind. Wird der Master-Strom in seiner
Aufnahmegeschwindigkeit abgespielt, erhält man ein ”real-time replay” [BaM,
S.4]. Die Blockgröße des Master-Stroms muß klein genug sein, um ein ”flüssiges”
Abspielen der Slave-Datenströme zu ermöglichen.
Im AOF-Viewer wird für die Darstellung jedes Datenstroms ein eigenes,
unabhängig funktionierendes Präsentationsmodul verwendet. Module für Slave-
Datenströme bezeichnet man auch als Helfer. Es sind dies beim Macintosh-Viewer
22

die wbPlay- und appPlay-Anwendung. Das Modul, das den Master-Strom anzeigt
(aofSync-Modul), wird auch als ”Synchronizer” bezeichnet. Zwischen Synchronizer
und jedem Helfer bestehen Kommunikationskanäle, die Kommunikation in beiden
Richtungen ermöglichen.
Bild 6: Master-Slave-Synchronisation (aus [BaM, S.4])
Die Kommunikationskanäle in Richtung Helfer werden für die Master-Slave-
Synchronisation sowie für die Steuerung der Helfer benutzt. Der Synchronizer
präsentiert den Master-Strom. Als Master-Strom wird der Audiodatenstrom
verwendet, da er die zeitlich kleinste Auflösung besitzt. Immer wenn ein Block des
Master-Stroms fertig gespielt wurde, wird der korrespondierende Timestamp durch
die Kommunikationskanäle an die Helfer gesendet. Diese zeigen umgehend die zu
diesem Timestamp gehörenden Daten ihres Slave-Stroms an. Durch die
Kommunikationskanäle können – in beiden Richtungen – auch Kontrollnachrichten
gesendet werden, wie z.B. ”Presentation has started, Presentation has stopped, User
is scrolling, [] jump to specified time stamp”[BaM, S.5].
Hier zeigt sich direkt ein Vorteil des Modularitätsprinzips: Die Erweiterung mit
neuen Datenströmen und damit mit neuen Helfern ist ohne großen Aufwand
möglich. Neue Helfer müssen lediglich ihren Datenstrom darstellen können und das
Kommunikationsprotokoll beherrschen.
23

Es ist darauf hinzuweisen, daß durch die random-access-Eigenschaft aller
Datenströme und durch die oben beschriebene Architektur ein Springen an jede
beliebige Stelle in einem Dokument möglich ist. Das erlaubt auch ein Indizieren
eines AOF-Dokumentes, d.h. Verweise auf bestimmte Stellen im Dokument von
außerhalb, z.B. von einem HTML-Browser via Hyperlinks aus. Bei den Unix- und
Windows-Versionen wurde diese Funktion bereits realisiert.
24

4 Portieren des AOF-Viewers auf Apple PowerPCs
4.1 Ausgangspunkt
Der Programmcode des AOF-Viewers ist für alle bisher unterstützten Plattformen
in C++ geschrieben. Die Teile des Codes, die plattformunabhängig sind, wurden
weitgehend unverändert übernommen. Es sind dies vor allem Klassen und
Funktionen, mit deren Hilfe dynamische Datenstrukturen aufgebaut werden (doc.c,
aoflist.c, aofobj.c und sgml.c).
Die eigentliche Portierungsarbeit lag in denjenigen Bereichen des Codes, die
plattformabhängige Befehle enthalten. Hierunter fällt vor allem die
Programmierung der graphischen Benutzeroberfläche (Fenstergestaltung,
Zeichenkommandos), das Abspielen des Audiodatenstroms sowie die
Implementierung der Kommunikation zwischen den einzelnen Modulen des
Viewers. Es wurden beide Codevarianten, die für Unix und die für Windows, für
die Portierung herangezogen. Dabei gab der Windows-Code etwas mehr
Anhaltspunkte für die Oberflächengestaltung, da sich die Befehle zum Zeichnen
und Gestalten von Fenstern mit denen des Macintoshs ähneln. Der Unix-Code
wiederum ließ etwas besser die modularen Prinzipien des Viewer-Aufbaus
erkennen.
4.2 Compiler und Gerät
Als Compiler stand die Entwicklungsumgebung CodeWarrior von Metrowerks,
Version 3 [MeW] zur Verfügung. Zielplattform für die Portierung des AOF-
Viewers war der Apple Power PC ab Version 7.0. Die älteren 68K-Prozessoren
konnten nicht unterstützt werden. Der Grund dafür lag in der Notwendigkeit, den
Audiodatenstrom in kleinen, in einer Warteschlange aufgereihten 1024-Byte-
Blöcken abzuspielen, da nur so eine Synchronisation mit den restlichen
Datenströmen erreicht werden kann. Bei dieser Methode kann es jedoch bei den
25

68K-Modellen zu akustischen Aussetzern zwischen dem Spielen zweier Blöcke
kommen.
Die Portierungsarbeit erfolgte auf zwei Power PCs mit Version 7.6.1 und 8.5.
4.3 Beibehaltene Prinzipien
Wie bereits am Anfang erwähnt, ist eines der programmtechnischen Prinzipien des
AOF-Viewers die Modularität. Das heißt, daß jeder Helfer (wbPlay und appPlay)
eine eigenständige, unabhängige Anwendung (standalone application) darstellt, die
von der Hauptanwendung (aofSync) bei Bedarf gestartet wird und über
Kommunikationskanäle Nachrichten austauscht. Dieses Prinzip wurde auch bei der
Macintoshversion beibehalten. Jedes Modul (aofSync, wbPlay, appPlay) ist
unabhängig von anderen Programmen lauffähig und besitzt auch äußerlich alle
Merkmale einer eigenständigen Anwendung (z.B. eigenes Icon). Die Vorteile
liegen auf der Hand: gefahrlosere Veränderbarkeit und Anpaßbarkeit des Codes
eines Moduls, mehr Übersichtlichkeit sowie geringere Fehlerwahrscheinlichkeit.
Das Modul-Prinzip erfordert die Implementierung einer Kommunikation zwischen
den einzelnen Anwendungen. Dies wurde mit Hilfe von Highlevelevents und
Appleevents realisiert (siehe dazu den entsprechenden Abschnitt). Die Unix-
Versionen des AOF-Viewers benutzen hier named pipes und die Windows-Version
das ”SendMessage”-Kommando, mit dessen Hilfe im Windows-Betriebssystem
Nachrichten an Fenster anderer Anwendungen geschickt werden können.
4.4 Änderungen und Anpassungen für die Macintosh-Version
In diesem Abschnitt soll auf die eigentliche Portierungsarbeit eingegangen werden.
Sie stellte den Haupt-Zeitaufwand dieser Diplomarbeit dar. Im folgenden seien die
Teile des AOF-Viewers beschrieben, bei denen der Code der anderen Plattformen
nicht übernommen werden konnte, sondern neu entwickelt werden mußte.
4.4.1 Programmierung der graphischen Benutzeroberfläche
26

Die graphische Benutzeroberfläche mußte für alle drei Viewer-Anwendungen von
Grund auf neu programmiert werden. Der Code hierfür befindet sich für alle drei
Programmmodule in der jeweiligen ”Window.c”-Datei. Zur
Oberflächenprogrammierung gehören das Aussehen von Fenstern und Knöpfen, die
Zeichenkommandos sowie die Implementierung der Reaktionen auf Knopfdrücke
und Anwählen von Menüpunkten. Der Windowscode, der in diesem Bereich als
Ausgangsbasis diente, konnte nur begrenzte Anhaltspunkte geben. Eine
umfangreiche Einarbeitung in Macintosh-Oberflächenprogrammierung war
notwendig. Hierzu wurden vor allem Handbücher, Programmierliteratur und online-
Programmierführer verwendet ([Ma92],[IM91],[IMT92]). Ein typisches Apple-
Problem, das sich dabei auftat, war die Tatsache, daß die Handbücher - z.T. noch
aus den Achtzigerjahren stammend – weitestgehend nur PASCAL-Code für
Befehlserklärungen und Programmbeispiele benutzen. Ein Grund hierfür ist die
Tatsache, daß das Macintosh-Betriebssystem ursprünglich in PASCAL
programmiert war. Eine Übersetzung in C-Code ist zwar nicht schwer, hat jedoch
einiges “Ausprobieren” zur Folge. Wert- und Variablenübergabe in Funktions- und
Prozeduraufrufen entsprechen sich nämlich in den PASCAL- und C-Versionen der
Befehle nicht.
4.4.2 Kommunikation zwischen den Modulen
Zur Kommunikation zwischen den Modulen wurden Highlevelevents benutzt. Im
Gegensatz zu Lowlevelevents (z.B. Mausklick, Tastendruck, Fensterbereich
aktualisieren) sind Highlevelevents zur Kommunikation zwischen verschieden
Anwendungen gedacht. Einige Highlevelevents sind bei Apple genormt: das
OpenApplication-Event, OpenDocument-Event, PrintDocument-Event und
QuitApplication-Event. Sie stellen die sog. Apple-Events dar, die jede Anwendung
unterstützen sollte, um die typische Macintosh-Benutzung zu garantieren, wie z.B.
das Öffnen eines Dokuments durch Ziehen des Dokument-Icons auf das Icon der
öffnenden Anwendung oder Doppelklicken auf das Dokument-Icon. Die
Nachrichten zwischen den AOF-Viewer-Modulen, deren Bedeutung sich mit denen
der Apple-Events decken (das QuitApplication- und OpenDocument-Kommando),
27

wurden deshalb auch als Apple-Event implementiert. Siehe hier als Beispiel das
aofSync-Modul, das beim Empfangen eines QuitApplication-Kommandos die
Audiodatei schließt, an die Helfer ebenfalls ein QuitApplication-Kommando
schickt und die globale Variable gDone auf wahr setzt, um ein Beenden der
Anwendung zu veranlassen (s.Datei window.c des aofSync-Moduls im Anhang):
pascal OSErr doQuitAppEvent(AppleEvent *appEvent,AppleEvent *reply,
long handlerRefCon)
{
gDone = true;
if(gAOFDocumentOpen)
{
helpers->sendcommand(-17); // send Quit command to helpers
sndExit(); // stop sound and close sound file
}
}
Die Nachrichten zwischen den Modulen im AOF-Viewer dienen der
Synchronisation (das aofSync-Modul teilt den Helfern den Timestamp, d.h. die
aktuelle Position im AOF-Dokument mit), der Information über Zustände (spielen,
stop, spulen) und dem Übermitteln des Sprung-Kommandos (Viewer soll an den
Anfangspunkt einer zu startenden Animation springen). Für diese Nachrichten
wurden Highlevelevents mit einer bestimmten Kennung verwendet, und zwar der
Kennung ‘AOFM’ für das Senden einer Nachricht, d.h. des Timestamps, ‘AOFC’
für das Übermitteln von Kommandos und Zuständen sowie ‘AOFI’ als Kennung für
den Initialisierungsdatenblock (Dateinamen der Objectlist und Eventqueue). Siehe
dazu die Dateien comm.c und comm.h im aofSync-Modul..
Bei einer Audioblockgröße von 1024 Byte wird alle 1/16 Sekunde ein
Synchronisationssignal an die Helfer geschickt. Tests bestätigten, daß
Highlevelevents schnell genug übermittelt und ausgeführt werden, um die
Synchronisation zwischen den Modulen zu gewährleisten.
4.4.3 Starten der Helfer-Anwendungen
28

Nach dem Öffnen eines AOF-Dokuments von der Hauptanwendung aofSync
werden die für das Lesen des Dokuments notwendigen Helfer-Anwendungen
automatisch gestartet. Das ist auch bei der Windows- und Unix-Version der Fall.
Für die Macintosh-Version wurde noch ein Suchprozeß implementiert, der vor dem
Starten eines Helfers in sämtlichen lokalen Speichermedien nach der
Programmdatei dieses Helfers sucht. Auf diese Weise ist der Standort der Helfer-
Programmdateien frei wählbar und auch nicht an den Standort des aofSync-Moduls
gebunden. Für den Suchprozeß werden die Datenbanken ausgenutzt, die der
Macintosh für jedes Speichermedium unterhält. Sie können in sehr kurzer Zeit
durchsucht werden, um nach einer Programmdatei zu suchen, die gestartet werden
soll (siehe die Funktion ‘start’ in der Datei comm.c im aofSync-Modul). Bekannt
sein muß nur der ”signature”-Code der zu startenden Anwendung, ein vierstelliger
Buchstabencode (32 Bit), der für jede Anwendung nur einmal existiert und sie
identifiziert. Signatures für Programmanwendungen können bei Apple zentral
registriert werden. Das wurde für den AOF-Viewers bereits getan.
4.4.4 Gestaltung der Fenster
Bei der Gestaltung der Fenster wurde auf ein Macintosh-typisches Aussehen Wert
gelegt. Dies gilt vor allem für das aofSync-Fenster.
29

Bild 7: Der AOF-Viewer für Macintosh
Der “More”/”Less”-Knopf der Unix- und Windows-Version wurde durch das
Macintosh-typische blaue Dreieck ersetzt, das seit Betriebssystem-Version 8.0
immer dann verwendet wird, wenn Inhalte auf- und zugeklickt werden können.
Alle Knöpfe wurden mit den Macintosh-typischen runden Ecken versehen und die
ordnenden Rahmenlinien im Fenster ebenfalls an das Macintosh-Design angepaßt.
Die Zahlen des Zählwerks wurden in einem blauen Farbton gehalten und die blauen
Ziffern der Unix- und Windows-Zeitskala bei der Macintosh-Version auf schwarz
angezeigt. Diese Reduzierung der Farbenanzahl geschah auf Anraten meiner
Programmierbetreuer an der University of Auckland.
30

Sämtliche Knöpfe wurden nicht als Standardkontrollknöpfe implementiert (wie z.B.
die Knöpfe in üblichen Dialogfenstern), sondern von Hand programmiert. Das hat
den Vorteil, daß die Knöpfe auf Betriebssystem 7.x und 8.x genau gleich ausehen.
Das Aussehen herkömmlicher Standardkontrollknöpfe änderte sich bei Macintosh
mit der Einführung der 8.0-Betriebssystemsversion.
Der Skalenzeiger wurde so implementiert, daß bei “eingezoomten” Zustand und
Ziehen des Zeigers ans Skalenende bereits beim Berühren desselben die Skala
anfängt, weiterzuwandern und so das Vor- bzw. Zurückspulen fortgeführt wird
(entspricht der Unix-Version, nicht der Windows-Version). Wird während dem
Spulen der gedrückte Mauspfeil aus dem aofSync-Fenster herausbewegt, bewegt
sich die Skala schneller. Des weiteren verdunkelt sich der Skalenzeiger, solange er
angeklickt wird (übliches Macintosh-Verhalten beim Bewegen von Zeigern).
4.4.5 Macintosh-Dateisystem
Die Besonderheiten des Macintoshs, die Organisation von Dateien betreffend,
machte sich auch beim Portieren des AOF-Viewers bemerkbar.
Zum Identifizieren einer Datei benutzt ein Macintosh-Computer einen speziellen
struct-Datentyp (FSSpec), in dem die Nummer des Speichermediums, die des
übergeordneten Verzeichnisses, sowie der Name der Datei (ohne Pfad) abgelegt
sind. Der Dateiname ist dabei ein PASCAL-String. Bei PASCAL-Strings gibt das
erste Byte des Strings die Länge des Strings an. Außerdem wird im Gegensatz zu
C-Strings keine Null am Ende des Strings angefügt.
struct FSSpec {
short vRefNum;
long parID;
Str63 name;
};
Alle Macintosh-spezifischen Befehle zum Öffnen, Schließen und Lesen von
Dateien erfordern diesen FSSpec. Eine einmal geöffnete Datei wird über eine
Nummer (die file reference number) referenziert, die beim Öffnen der Datei einer
Variablen zugewiesen wird.
31

Macintosh unterstützt auch die Standard-C-Ein- und Ausgabebefehle für Dateien,
die zur Identifikation einer Datei den vollen Pfadnamen (als C-String, d.h. Nullterminiert)
benutzen und zur Referenzierung einer offenen Datei den C-”FILE”struct
benutzen.
Jedoch ist manchmal die Benutzung der Macintosh-spezifischen Befehle
unvermeidlich. Z.B. erfordert Macintoshs ‘ParseAIFFHeader’-Funktion, die den
Dateikopf einer (offenen) Audiodatei liest , ihre file reference number. Hier mußte
dann bei der Portierung der vorliegende volle Pfadname für die Audiodatei in einen
FSSpec konvertiert werden, dann die Datei mit Macintosh-spezifischen Befehlen
geöffnet werden, um so die file reference number zu erhalten. (Siehe die Funktion
‘aof_af_open’ in der Datei snd.c im aofSync-Modul.)
Ein weiteres Mal wurde die Verwendung des Macintosh-spezifischen FSSpecs im
wbPlay-Modul erforderlich. Die Quicktime-Befehle, die zum Einlesen der GIF-
files in den Speicher benutzt wurden, arbeiten ebenfalls nur mit dem FSSpec(siehe
Funktion ‘newI’ in der Datei replay.c im wbPlay-Modul).
Eine weitere Besonderheit des Macintosh-Dateisystems ist die Tatsache, daß in
Datei- und auch Verzeichnisnamen Leerzeichen vorkommen dürfen. Das hat zur
Folge, daß einige C-Funktionen, die mit Strings arbeiten (z.B. ‘sscanf’), nur mit
Vorsicht benutzt werden dürfen, da sie ein Leerzeichen als Trennzeichen zwischen
zwei verschiedenen Strings interpretieren. Funktionen dieser Art wurden bei der
Macintosh-Version durch andere Funktionen ersetzt.
4.4.6 Abspielen der Audiodatei
Das Abspielen von Audiodateien ist in hohem Maße plattformabhängig.
Macintosh-Computer bieten zahlreiche Möglichkeiten zum Abspielen von
Audiodaten. Mit jeweils einem einzigen Befehl können sie z.B. direkt von Datei
gestartet und sekundengenau gestoppt werden. Eine Sekunde ist jedoch zu lange für
die geforderte Synchronisationsgenauigkeit des AOF-Viewers, der ungefähr alle
1/16 Sekunde ein Synchronisationssignal für die Helfer benötigt. Deshalb mußte
das Abspielen der Audiodatei ähnlich wie auf den anderen Plattformen
implementiert werden. Die Audiodaten werden in 1024 Byte-Blöcken in einer Art
32

Warteschlange dem Audiodevice zugeführt, das diese dann spielt. Jeweils nach dem
Abspielen eines kompletten Blocks wird eine Callback-Prozedur aufgerufen, die
die globale Variable “gBufferFlag” setzt (Synchronisationssignal). Der Wert dieser
Variablen wird regelmäßig abgefragt und - falls sie gesetzt ist - das Füllen eines
neuen Blocks mit Audiodaten von der Datei veranlaßt. Des weiteren wird die
Datenposition aktualisiert (Zählwerk) und diese den Helfern mitgeteilt.
Siehe hierzu einen Auszug aus dem eventloop des aofSync-Moduls (Datei
window.c):
33

void eventLoop(void)
{
EventRecord eventRec;
Boolean gotEvent;
gDone = false;
}
while(!gDone)
{
while (gBufferFlag>0) //one (or already several) buffer(s) played
{
gDataPosition = gDataPosition + (double)bytesToMs(kBufferSize);
// update data position
}
if(gPlaying)
{
sndFillBuffer();
sndPlayBuffer();
gBufferFlag--;
}
else
{
sndStop();
gBufferFlag = 0;
}
helpers->sendmessage((long)gDataPosition); // send time stamp
// to helpers
if(!gBufferFlag) drawCounter(gDataPosition); // update counter
} // end while(gBufferFlag)
gotEvent=WaitNextEvent(everyEvent,&eventRec,3,gMouseMovedRegion);
if(gotEvent)
doEvents(&eventRec);
Gestoppt werden kann das Abspielen der Audioblöcke nur dann, wenn gerade ein
Block zu Ende gespielt ist (deshalb dürfen die Blöcke nicht zu groß sein). Der
”random-access” für die Audiodaten, d.h. die Möglichkeit zum Springen an
bestimmte Stellen in der Audiodatei, ist gewährleistet durch Einlesen der
Audiodaten in die Speicherblöcke von dieser bestimmten Stelle ab (Funktion
‘sndStart’ in der Datei snd.c für aofSync-Modul).
Die Länge eines Blocks wurde auf ein Kilobyte gesetzt (Datei snd.h im aofSync-
Modul). Dies ermöglicht ein praktisch sofortiges, jederzeit mögliches Stoppen des
Tones und garantiert bei Mono, 16000Hz Samplefrequenz und einer Samplegröße
von 8 Bit ein Synchronisationssignal alle 1/16-Sekunde.
Es fiel auf, daß, insgesamt gesehen, das Abspielen des Audiodatenstromes auf dem
Macintosh nicht einfacher zu implementieren ist als auf den anderen Plattformen.
34

Bessere Audiofähigkeiten und -möglichkeiten bietet der Macintosh vor allem im
Synthesizerbereich, der beim AOF-Viewer jedoch keine Rolle spielt.
Nichtsdestotrotz stellte die Benutzung der Macintosh-”ParseAIFF-Header”-
Funktion eine große Vereinfachung dar, die fünf Seiten Windows-Programmcode
ersetzte. Diese Funktion liest Parameter der Audiodatei, wie z.B. Dateilänge,
Anzahl der Kanäle, Kompressionsart und Offset, die bekannt sein müssen, bevor
die Audiodaten gespielt werden können.
4.4.7 Einlesen der Bilder
Eine wichtige Funktion des wbPlay -Moduls ist das Laden und Anzeigen der
Folien, die während der Vorlesung gezeigt werden. Während bei der Unix-Version
des Viewers die Folien in verschiedenen Formaten gelesen werden können (z.B.
GIF, postscript, TIFF), kann der Windows-Viewer nur GIF-Bilddateien lesen.
Für die Macintosh-Version wurde hier auf einige Quicktime-Funktionen
zurückgegriffen, die verhältnismäßig viel Programmcode - verglichen mit den
anderen Viewer-Versionen – ersparen (Datei replay.c im wbPlay-Modul):
GraphicsImportComponent gi;
PicHandle picHand;
Rect natRect;
FSSpec spec;
GetGraphicsImporterForFile(&spec, &gi);
GraphicsImportGetAsPicture(gi, &picHand);
GraphicsImportGetNaturalBounds(gi, &natRect);
CloseComponent(gi);
Mit wenigen Programmzeilen erhält man so eine handle (Zeiger auf einen Zeiger)
auf das jeweilige Bild. Vorausgesetzt werden muß jedoch, daß auf dem Computer
des Benutzers Quicktime 3.0 installiert ist. Das sollte jedoch keinen Nachteil
darstellen, da diese neueste Quicktime-Erweiterung auf dem Internet frei
zugänglich ist. Ein Vorteil der Quicktime-Funktionen ist ihre Fähigkeit, zahlreiche
Bildformate zu akzeptieren. Unterstützt werden: GIF, TIFF, JFIF/JPEG,
SiliconGraphics, PICT, QTIF, BMP, PNG, Targa, MacPaint, Photoshop.
4.4.8 Zeichenkommandos
35

Die Übersetzung der Windows-Zeichenkommandos für das Whiteboard stellte kein
großes Problem dar. Sie ähneln weitgehend denen des Macintoshs. Größere
Änderungen im Code mußten hauptsächlich beim Anzeigen der Bitmaps (Folien)
vorgenommen werden (siehe vorheriger Abschnitt).
4.4.9 Flackerfreies Zeichnen
Flackern findet immer dann statt, wenn ein bereits auf dem Bildschirm
existierendes Objekt zusammen mit seinem Hintergrund neu gezeichnet wird.
Dadurch, daß zuerst der Hintergrund gezeichnet wird (z.B. weiß), wird das alte
Objekt auf dem Bildschirm kurz ”gelöscht”, bevor es neu auf den Hintergrund
gezeichnet wird. Durch dieses kurze ”Löschen” des Objektes entsteht ein Flackern.
Dieses macht sich beim AOF-Viewer (Windows- und Sun-Version) vor allem im
Zählwerk und bei sich schnell verändernden Objekten auf dem Whiteboard
bemerkbar (z.B. beim freihändigen, langsamen Einkreisen von Objekten).
Bei der Macintosh-Version wurde darauf geachtet, daß alle graphischen Objekte,
die alle 1/16-Sekunde neu gezeichnet werden (also nach Abspielen eines
Audioblocks), zuerst in einen “unsichtbaren” Bildschirm im Speicher gezeichnet
werden und dann erst dieser Speicherbereich Pixel für Pixel auf den eigentlichen
Bildschirm kopiert wird. Auf diese Weise wird das Flackern vermieden, da Pixel,
die sich nicht verändern, nicht erst gelöscht und dann wieder neu gezeichnet
werden. Für das Auge macht sich diese Verbesserung vor allem beim Betrachten
des Zählwerks positiv bemerkbar.
4.4.10 Öffnen eines AOF-Dokumentes
Da Macintosh-Computer keine Kommandozeilentechnik kennen, mit deren Hilfe
dem Programm (aofSync-Modul) direkt beim Start Daten übergeben werden
können - also Standort und Name der zu öffnenden AOF-Datei - , wurde das
Öffnen eines AOF-Dokumentes in der Macintosh-Version mittels Menüs
implementiert.
36

Nach dem Starten des aofSync-Moduls kann der Benutzer durch den “Open”-Befehl
im “File”-Menü ein AOF-Dokument öffnen. Siehe hierzu den Abschnitt ”Menüs”
später in diesem Kapitel.
4.4.11 Ladevorgang
Die Zeit, die benötigt wird, um ein AOF-Dokument zu laden, wird hauptsächlich
durch die Anzahl der vorkommenden Bilder (Folien) bestimmt. Ihre Umwandlung
in Bitmaps kostet Zeit. Dieser Ladevorgang wird vom wbPlay-Modul veranlaßt, das
nach seinem Start anhand der eingelesenen Objectlist und Eventqueue eine interne
Objekt- und Ereignisliste anlegt.
Wie im vorherigen Kapitel bereits erwähnt, wird dieses Laden bei der Unix- und
der Windows-Version durch Ladevorgangsfenster illustriert, die
programmtechnisch eigenständige Anwendungen sind.
Auf eigenständige Anwendungen wurde bei der Macintosh-Version verzichtet und
die Ladevorgangsfenster als Teil des wbPlay-Moduls implementiert (siehe Dateien
prog.c und prog.h im wbPlay-Modul). Grund dafür war die Tatsache, daß
Ladevorgänge, wenn sie einen eigenständigen Prozeß darstellen, in den
Hintergrund geklickt werden können. Der gesamte Ladevorgang des wbPlay ist
jedoch programmtechnisch kein eigenständiger Prozeß, sondern Teil des wbPlay-
Programmprozesses. Schließlich wird während dem Laden der Eventloop der
wbPlay-Anwendung nur einmal durchlaufen (deshalb kann das Laden auch nicht
abgebrochen werden). Dieser Tatsache sollte dadurch Rechnung getragen werden,
daß die Ladevorgangsfenster bei der Macintosh-Version fest im Vordergrund, über
dem wbPlay-Fenster angezeigt werden, keine eigenständige Anwendung darstellen
und auch keinen Abbruch(“Cancel”)-Knopf besitzen.
Hier sind für zukünftige Viewer-Versionen Verbesserungsmöglichkeiten
vorhanden, da Ladeprozesse der Sicherheit wegen immer abbrechbar sein sollten,
z.B. im Falle nichtausreichenden Speicherplatzes.
37

4.4.12 Steuerung von Animationen durch das appPlay-Modul
Wie weiter oben schon ausgeführt startet das appPlay-Modul im Unix-Viewer zu
entsprechenden Zeitpunkten beliebige Anwendungen. Dies geschieht, indem Shell-
Skripte ausgeführt werden. In diesen Skripten (Dateien, die meistens nur aus einer
Zeile bestehen) stehen Pfad und Name der Anwendung, die gestartet werden soll,
sowie das von dieser Anwendung zu öffnende Dokument. Bsp.:
/usr/local/mpeg2play /usr/local/movie01.mpg
Für die Macintosh-Version des AOF-Viewers wurde in Abstimmung mit den
Betreuern der anderen Plattformen beschlossen, die Skripte beizubehalten, auch
wenn der Macintosh-Computer damit direkt keine Anwendung starten kann.
Stattdessen wird, nach dem Einlesen des Skripts, der Name der Anwendung durch
eine Mapping-Tabelle auf die signature einer entsprechenden Anwendung auf dem
Macintosh abgebildet. Ist der Name der Anwendung im Skript z.B. “mpeg2play”
(der MPEG-Player auf Unix-Plattformen), wird beim Macintosh der
“AppleMoviePlayer” gestartet.
Diese Tabelle, in der Namen von Unix-Anwendungen auf Macintosh-
Anwendungen (genauer gesagt: deren signatures) abgebildet werden, befindet sich
in der Resourcefork der appPlay-Programmdatei. Damit wird ein zukünftiges
Hinzufügen von weiteren Anwendungen und deren Namen ohne Änderungen am
Quellcode ermöglicht. Es wurde eine weitere Funktion implementiert, die, falls der
Anwendungsname unbekannt ist, die Endung (Extension) des Dokumentnamens
(z.B. ‘.mpg’) mit Hilfe einer weiteren Tabelle auf eine passende Anwendung
abzubilden versucht.
Ist die signature der zu startenden Anwendung gefunden, wird nach ihr gesucht und
die Anwendung gestartet. Danach wird ihr ein OpenDocument-Kommando mit dem
Dateinamen des zu öffnenden Dokuments geschickt (Funktion ‘startApp’ in
window.c im appPlay-Modul).
Als nicht unerheblicher Nachteil erwies sich die Tatsache, daß der Apple-Movie-
Player nach dem Öffnen eines Filmdokuments dieses nicht automatisch startet und
ihm dies auch nicht durch Nachrichten mitgeteilt werden kann. Der Benutzer muß
38

manuell auf den Startknopf am unteren Fensterrand klicken. Man könnte
argumentieren, daß ein erfahrener Macintosh-Benutzer wissen sollte, was es zu tun
gilt, wenn der Movie-Player das Anfangsbild eines Films zeigt (nämlich ihn
starten). Trotzdem ist das nicht komfortabel, wenn zu viele Filme in einer
Vorlesung vorkommen.
Applescript würde sich normalerweise in diesem Fall anbieten. Mit dieser Sprache
können (bestimmte) Anwendungen auf Makroebene gesteuert werden. Jedoch ist
der Apple-Movie-Player bis jetzt noch nicht durch applescript steuerbar. Als
Abhilfe wurde ein eigener, selbst programmierter Movie-Player getestet. Hier störte
jedoch ein bekannter und von Macintosh-Benutzern schon öfters monierter Fehler
in Quicktime, der zur Folge hat, daß MPEG-Filme nur mit Tonspur gespielt werden
können. Leider haben die bisher bei AOF-Vorlesungen benutzten Filme MPEG-
Format, aber keine Tonspur.
4.4.13 Schriftsatz-Problem
Das Schriftsatz(Font)-Problem ist ein grundsätzliches Problem bei Portierungen
von Anwendungen, die Schrift benutzen. Es taucht schon bei Portierungen
zwischen verschiedenen Unix-Plattformen auf. Das AOF-System benutzt
bestimmte Schriftsätze (z.B. Courier, Times Helvetica, etc.). Jeder Computer
benutzt aber seine eigenen graphischen Darstellungen dieser Schriftsätze, d.h.
andere Bitmaps für die Buchstaben. Breite und Höhe der Buchstaben können sich
auf verschiedenen Plattformen unterscheiden. Eventuell vorgenommene
Skalierungen, die notwendig sind, wenn ein Schriftsatz nicht in der gewünschten
Größe als Bitmap auf dem System vorliegt, können ebenfalls von System zu
System variieren. Das kann sich störend bemerkbar machen, wenn Text mit
anderen graphischen Elementen gekoppelt ist, z.B. eingerahmt, oder unterstrichen.
Hier kann es in ungünstigen Fällen passieren, daß der Text im Viewer seine
Einrahmung durchbricht, an der falschen Stelle steht oder anderen Text überlappt.
Das Problem taucht nur in Vorlesungen auf, in denen die Folien hauptsächlich mit
dem Whiteboard erstellt worden sind.
39

Das Schriftsatz-Problem wurde bisher für keine Plattform gelöst. Lösungen gäbe es
jedoch. Z.B. könnte man festlegen, nur “True-Type-Fonts” zu verwenden. Diese
Schriftsätze enthalten keine Bitmaps für die graphische Darstellung der
Buchstaben, sondern Berechnungsregeln für deren Proportionen. Auf diese Weise
sehen in allen Schriftgrößen und auf allen Plattformen die Buchstaben gleich aus.
Die True-Type-Fonts müßten dann im Viewer-Code enthalten sein. Diese Lösung
wäre wohl elegant und auf dem Macintosh zudem leicht zu implementieren. Sie
kann jedoch nur in Abstimmung mit dem Whiteboard geschehen, dessen
Entwickler zur Zeit aber noch eine neue Benutzeroberfläche (mit eventuell neuen
Schriftsätzen) abwarten.
Eine weitere Lösung wäre, für Texte mehr oder weniger genaue Informationen
bezüglich der Position der einzelnen Buchstaben auf dem Whiteboard
bereitzustellen. Das liefe auf eine Darstellung von Text durch einzelne Char-
Zeichen heraus (die ja einen x- und y-Wert haben), wäre ziemlich aufwendig und
speicherplatzintensiv.
Ein Schritt in diese Richtung wurde schon gemacht, indem man Text (in der
Objectlist) in einzelne Textitems aufgeteilt hat, die sich nicht überlappen dürfen. In
der Praxis führt dies bereits zu recht guten Erscheinungsbildern.
4.4.14 Zeichensatz
Macintosh-Computer benutzen einen anderen Zeichensatz als Unix- und Windows-
Rechner. Die ASCII-Zeichen sind zwar gleich (Codierung 1 bis 127), der restliche
Bereich, in dem z.B. auch die deutschen Umlaute liegen, wird jedoch anders
codiert. Da die meisten aufgenommenen Vorlesungen bisher deutsch sind, mußte
hier Abhilfe durch eine Tabelle geschaffen werden, mit deren Hilfe die
Codierungen der Zeichen auf die entsprechenden Werte des Macintoshs gesetzt
werden (Datei “encoding.c” im wbPlay-Modul). Selbst für Zeilenwechsel benutzt
Macintosh (beim Schreiben) andere Codierungen, nämlich “\r” statt “\n” auf Unixund
Windows-Plattformen.
Bei einer zukünftigen internationalen Benutzung der AOF-Software wäre ein
Zusatz in der AOF-Datei angebracht, der den benutzten Zeichensatz angibt (z.B.
40

ISO 8859-x, MacOSRoman, ISO 646,...) und eine eindeutige Darstellung der
Zeichen erlaubt.
4.4.15 Bildschirmgröße
Das Whiteboard ist in einer Größe entworfen worden, die man nur auf einem relativ
großen 1280 x 1024 Pixel-Bildschirm ausnutzen kann. Hat der Benutzer des
Viewers einen kleineren Bildschirm, kann es passieren, daß bestimmte
Whiteboardaktionen einfach abgeschnitten werden. Ein Hin- und Herscrollen
während dem Betrachten eines Vortrags wäre hier auch keine Lösung.
In die wbPlay-Version des Macintosh-Viewers wurde daher eine Abfrage nach der
Bildschirmgröße eingebaut, die alle Zeichenobjekte und auch die Bitmaps der
Bilder schon beim Einlesen auf eine passende Größe skaliert, so daß der gesamte
Whiteboardinhalt auf den jeweiligen Bildschirm paßt.
4.5 Macintosh-Besonderheiten
4.5.1 Dateien
Eine wichtige Macintosh-Eigenheit ist mit Sicherheit der Aufbau seiner Dateien. So
besteht jede Datei beim Macintosh aus zwei Gabeln (”forks”), der Resourcefork
und der Datafork. Wichtigste Fork ist die Datafork, in der die Daten von sowohl
Dokument- wie auch Programmdateien abgelegt werden. Der Resourcefork kommt
eine besondere Aufgabe zu. In ihr werden, sofern es sich um eine Programmdatei
handelt, globale Konstanten, Textstrings, Icons, Fensterbreiten und -höhen, Menüs,
Menütexte, Dialogfensteraufbau und -texte, also alles, was das äußere
Erscheinungsbild der Anwendung bestimmt, abgelegt. So kann der Benutzer mit
einem entsprechenden Werkzeug (z.B. mit dem frei erhältlichen Programm
ResEdit) alle in der Anwendung vorkommenden Texte von Dialog-, Alarm- und
auch normalen Fenstern in seine Muttersprache übersetzen oder Icons durch andere
ersetzen. Das alles ist ohne Zugang zum eigentlichen Programmcode möglich (der
kompiliert in der Datafork liegt). Dieses benutzerfreundliche Prinzip wurde
versucht einzuhalten und demnach alle der oben erwähnten globalen Konstanten in
der Resourcefork gespeichert.
41

4.5.2 Icons
In der graphischen Macintosh-Benutzeroberfläche spielen Icons eine wichtige
Rolle. Icons repräsentieren sowohl Anwendungen wie auch Dokumente. Für die im
AOF-Viewer vorkommenden drei Anwendungen (aofSync, wbPlay und appPlay)
wurde beim Entwurf der Icons auf das dreifarbige AOF-Logo zurückgegriffen.
Bild 8: AOF-Icons
Alle mit Icons verbundenen Funktionen werden beim Macintosh-Viewer
unterstützt:
Doppelklick auf das Icon startet die jeweilige Anwendung (auch wbPlay und
appPlay, die zwar nur Helferanwendungen sind und in diesem Fall nur ein graues
Fenster mit der Andeutung einer Skala zeigen).
Doppelklick auf ein AOF-Dokument-Icon mit der Endung ”.aof” startet
automatisch die aofSync-Anwendung (die das Dokument öffnet und die Helfer
startet), genauso als wäre das Dokument über den Open-File-Dialog der bereits
gestarteten aofSync-Anwendung geöffnet worden. Diese Funktion (Doppelklick auf
Dokument-Icon) setzt jedoch die richtige ”Creator”-Eintragung in der
Dokumentdatei voraus. Der Creator-Code ist ein vierstelliger Buchstabencode in
der Resourcefork jeder Macintoshdatei, der ihr eine Anwendung zuordnet, von der
sie geöffnet werden kann. Hier muß die Anwendungssignature der aofSync-
Anwendung eingetragen sein. Dies kann vor der Bereitstellung von AOF-
Dokumenten für den Macintosh-Viewer leicht bewerkstelligt werden.
Gleichsam können AOF-Dokumente - auch ohne Creator-Code - jederzeit geöffnet
werden, indem das angeklickte Dokument-Icon über das aofSync-Icon gezogen
wird.
Alle erwähnten Icon-Funktionen arbeiten über die oben bereits erwähnten Apple-
Events, die von den Anwendungen unterstützt werden (siehe Abschnitt
”Kommunikation zwischen den Modulen” am Anfang dieses Kapitels). Z.B. wird
42

eim Doppelklick auf ein AOF-Dokument-Icon automatisch die aofSync-
Anwendung gestartet und dieser dann ein OpenDocument-Apple-Event geschickt,
zusammen mit einem FSSpec des Dokuments.
4.5.3 Menüs
Zur graphischen Benutzeroberfläche des Apple Macintosh gehören Menüs. Der
Menübalken ist dabei nicht, wie im Windows- und Unix-Betriebssystem, Teil eines
Fensters, sondern befindet sich immer am oberen Bildschirmrand. Je nachdem,
welches Programm gerade aktiv ist und welche Menüs es beinhaltet, verändert sich
dieser zentrale Menübalken.
Apple empfiehlt Entwicklern, in ihren Anwendungen mindestens das ”File”-Menü
zu unterstützen, mit den Befehlen ”Open”, ”Close”, und ”Quit”.
Das Menü-Prinzip sollte auch für den AOF-Viewer verwirklicht werden.
So wird bei der aofSync Anwendung durch Wählen von ”Open” im File-Menü ein
Standard-Dialogfenster zum Öffnen von Dateien geöffnet, durch das dann durch
Navigation im Dateisystem ein AOF-Dokument ausgewählt und geöffnet werden
kann.
Das Schließen eines AOF-Dokuments (und das dadurch mögliche anschließende
Öffnen eines anderen Dokuments) konnte leider nicht implementiert werden, da die
dynamische Speicherallokation und -deallokation für den Aufbau der verketteten
Listen im wbPlay-Modul Probleme bereitete. Zudem ist der Code des AOF-
Viewers (Unix- und Windows-Version) auch eigentlich dafür ausgelegt, nur ein
AOF-Dokument anzuzeigen und dann das Programm zu beenden. Grundsätzlich
müßte das Schließen und Wiederöffnen von Dokumenten durch
Codeverbesserungen jedoch noch realisierbar sein.
Der “Quit”-Befehl im File-Menü beendet die Anwendung (der “Quit”-Knopf im
unteren rechten Teil des aofSync-Fensters bewirkt das gleiche). Eventuell offene
Helfer-Module werden durch Senden von entsprechenden Apple-Events ebenfalls
geschlossen. Nach strenger Apple-Philosophie dürfte innerhalb des Fensters jedoch
kein Quit-Knopf vorhanden sein - Anwendungen sollten nur durch den “Quit”-
Befehl im File-Menü beendet werden.
43

Bei den Helfer-Anwendungen wurden die “Open” - und “Close”-Befehle im File-
Menü einfach zum Öffnen und Schließen der Fenster ausgelegt (das Schließen
eines Fensters kann auch durch Anklicken eines speziellen Knopfes im oberen
Fensterrahmen bewirkt werden).
In einer verbesserten Version des Macintosh-AOF-Viewers wären noch andere
Menüpunkte denkbar, wie z.B. das Umstellen von Stereo auf Mono oder das
Ausschalten des wbPlay-Moduls schon vor dem Öffnen eines Dokuments, wie es
auch bei der Unix-Version durch entsprechende Kommandos in der
Kommandozeile möglich ist.
44

4.6 Vorteile der Macintosh-Version
Nach der Portierung des AOF-Viewers an das Macintosh-Betriebssystem können
einige Verbesserungen gegenüber der Unix- und Windows-Version bemerkt
werden:
4.6.1 Graphik
Vorteile der Macintosh-Graphik sind das Ausmerzen des Flackerns beim Zählwerk
sowie bei den Whiteboard-Zeichenkommandos. Desweiteren ist durch eine
Berücksichtigung der Bildschirmgröße sichergestellt, daß der gesamte
Whiteboardinhalt dargestellt wird.
4.6.2 Menüs
Eine Erweiterung der Benutzerfreundlichkeit stellen die Menübefehle dar.
In einer verbesserten Version müßte aber auf jeden Fall noch die Möglichkeit
implementiert werden, ein AOF-Dokument wieder schließen zu können, ohne die
Anwendung zu beenden (“Close”-Befehl). In diesem Fall müßten an die Helfer-
Module (wbPlay und appPlay) entweder entsprechende Nachrichten geschickt
werden (die den Abbau der für das offene Dokument aufgebauten Datenstruktur
veranlassen) oder die Helfer-Anwendungen müßten beim Schließen eines
Dokumentes einfach beendet und beim Öffnen eines neuen Dokuments neu
gestartet werden.
4.6.3 Icons
Die oben bereits erwähnten Eigenschaften von Icons in Macintosh-Anwendungen
stellen eine weitere Annehmlichkeit in der Bedienung des Macintosh-AOF-Viewers
dar.
4.7 Nachteile der Macintosh-Version
45

Es ist bisher nicht möglich, den Apple-Movie-Player zu starten, ohne daß der
Benutzer noch den Start-Knopf drücken müßte, damit der Film läuft. Falls Apple in
Zukunft den Movie-Player modifiziert, d.h. zugänglich für applescript macht, wäre
dieser Nachteil jedoch beseitigt.
Die vom appPlay-Modul abzuspielenden Animationen waren bisher für die meisten
aufgenommenen Vorlesungen (”Algorithmen und Datestrukturen”) Tango-
Animationen. Tango ist eine spezielle Software zur graphischen Darstellung von
Algorithmen. Die Tango-Software (shareware bereitgestellt vom Georgia Institut of
Technology [StJ92]) existiert jedoch nur für Unix und Windows-Plattformen. Um
die Animationen auf dem Macintosh abspielen zu können, müssen sie erst in
Quicktime- oder MPEG-Filme konvertiert werden, so daß das appPlay-Modul dann
an den entsprechenden Stellen den Apple-Movie-Player startet, um die Filme zu
zeigen. Da jedoch - zumindest am Institut für Informatik an der Universität
Freiburg - alle benutzten Animationen schon in MPEG-Filme konvertiert wurden,
fällt dieses Manko nicht so stark ins Gewicht.
Die Unix- und Windows-Viewer können mittlerweile schon direkt vom HTML-
Browser Netscape aus gestartet werden. In den HTML-Seiten können bestimmte
Stellen in Vorträgen angeklickt werden. Der Viewer wird dann gestartet und springt
zur entsprechenden Stelle in der Vorlesung. Eine vorherige lokale Installation des
Viewers ist erforderlich.
Bei der Macintosh-Version steht die Verbindung mit Netscape noch aus, bietet sich
aber für die nahe Zukunft an.
46

5 Beurteilung der portierten Version
Die Macintosh-Version des AOF-Viewers ist mit Sicherheit ein Schritt in Richtung
einer weiteren Verbreitung der AOF-Software. Bei dieser neuesten Version des
Viewers wurden, auch im Hinblick auf die relativ komfortable graphische
Benutzeroberfläche des Apple Macintoshs, einige kleine Verbesserungen erzielt. Es
wurde bei der Portierung darauf geachtet, auf Macintosh-Eigenheiten und -Stil
Rücksicht zu nehmen.
Von Vorteil sind bei der Macintosh-Version die etwas größere
Benutzerfreunlichkeit. Die graphischen Verbesserungen sind angenehm, sollten
aber auch bei den anderen Plattformen jederzeit ohne allzu großen Aufwand noch
realisierbar sein.
Die Geschwindigkeit der Macintosh-Version z.B. beim Öffnen eines Dokuments
(Laden der Bilder) ist jener der anderen Plattformen ebenbürtig. Es zeigt sich, daß
der Macintosh, auch mit dem älteren Betriebssystem 7.x, keinesfalls zu langsam für
die Anforderungen des AOF-Viewers ist.
Im Code konnten durch den Einsatz von Quicktime-Funktionen einige
Vereinfachungen erzielt werden, die auch auf der Windows-Plattform noch zum
Einsatz kommen könnten.
47

6 Literaturverzeichnis
[MO99] Müller R., Ottmann Th. : “The ‘Authoring on the Fly’ System for
Automated Recording and Replay of (Tele)presentations”; accepted
for
Special Issue on "Multimedia Authoring and Presentation
Techniques";
ACM/Springer Multimedia Systems Journal; to appear 1999
[BMO97] Bacher, Ch.; Müller, R; Ottmann, T. :” Ein Weg zur Integration von
Live-Vorlesung, Teleteaching und Lehrsoftwareproduktion”;
Proceedings Mediengestützte wissenschaftliche Weiterbildung;
Braunschweig; 1997
[BMOW97] Bacher, Ch.; Müller, R; Ottmann, T.; Will, M. :” Authoring on the
Fly, A new way of integrating telepresentation and courseware
production”; Proceedings ICCE ‘97; Kuching, Sarawak, Malaysia;
1997
[BaM98] Bacher, Ch.; Müller, R: ”Generalized Replay of Multi-
Streamed
Authored Documents”; Proceedings of ED-MEDIA ‘98; Freiburg;
1998
[MaG96] Maass, Gabriela: ”Editor für Multimedia-Dokumente”; Diplomarbeit;
Institut für Informatik; Universität Freiburg; 1996
[ErH94] Erikson, H.: ”Mbone: The multicast backbone”; ACM
Communications; 37:54-60; 8 1994
[IM91] Apple Computer Inc. (Hrsg.): ”Inside Macintosh”, Band I-VI;
Reading, Mas.; 1987-91
[IMT92] Apple Computer Inc. (Hrsg.): ”Inside Macintosh, Macintosh Toolbox
Essentials”; Reading, Mas.; 1992
[IMF92] Apple Computer Inc. (Hrsg.): ”Inside Macintosh, Files”; Reading,
Mas.; 1992
48

[Ma92] Mark, Dave: ”Macintosh C Programming Primer”; Reading, Mas.;
1992
[Al90] Allen, Daniel K.: ”On Macintosh Programming: Advanced
Techniques”; Reading, Mas.; 1990
[Kn87] Knaster, Scott: ”Macintosh Programming Secrets”; Reading, Mas.;
1987
[StJ92] Stasko, J.T.: ”Animating Algorithms with XTango”; SIGACT News,
Vol.23, No.2; 1992
[BrM91] Brown, M.H. : ”Zeus: A System for Algorithm Animation Multi-
View
Editing.”; IEEE Workshop on Visual Languages; 1991
[AmW] http://cafe.ambrosiasw.com/macintosh-c
[VirW] http://ad.informatik.uni-freiburg.de/viror.project.description
[ApW] http://www.apple.com
[MeW] http://www.metrowerks.com
[StJW] Stasko, J.H. : ”Polka Animation System”;
http://www.cc.gatech.edu/gvu/softviz/parviz/polka.html
49

Ich versichere hiermit wahrheitsgemäß, die Arbeit bis auf die dem Aufgabensteller
bereits bekannte Hilfe selbständig angefertigt, alle benutzten Hilfsmittel vollständig
und genau angegeben und alles kenntlich gemacht zu haben, was aus Arbeiten
anderer unverändert oder mit Abänderungen entnommen wurde.
50

7 Anhang
51