Apple Event – Wikipedia

before-content-x4

Apple-Ereignisse sind der nachrichtenbasierte Interprozess-Kommunikationsmechanismus in Mac OS, der zuerst in System 7 angezeigt wird und seitdem von jeder Version des klassischen Mac OS und von macOS unterstützt wird. Apple-Ereignisse beschreiben “Ereignisse auf hoher Ebene” wie “Dokument öffnen” oder “Datei drucken”, während frühere Betriebssysteme wesentlich grundlegendere Ereignisse unterstützt hatten, nämlich “Klicken” und “Tastendruck”. Apple-Ereignisse bilden die Grundlage des Mac OS-Skriptsystems, der Open Scripting-Architektur (die Hauptsprache von AppleScript).

Der Ausgangspunkt ist ein dynamisch typisiertes, erweiterbares Deskriptorformat namens AEDescDies ist nur ein OSType-Code, der den Datentyp zusammen mit einem Block typabhängiger Daten angibt. Zum Beispiel der OSType-Code inte Gibt an, dass es sich bei den Daten um eine 4-Byte-Ganzzahl mit Vorzeichen im Big-Endian-Format handelt.

Neben vordefinierten Typcodes für verschiedene gängige einfache Typen gibt es zwei vordefinierte strukturierte Deskriptortypen: an AERecord, der Datentyp hat reco (Aufzeichnung) und AEList mit Typ list (Liste oder Array). Die interne Struktur dieser enthält rekursiv verschachtelte AEDescs, während der AERecord jedem Element eine eindeutige Datensatzfeld-ID zuordnet, bei der es sich um einen OSType handelt. Der Apple Event Manager bietet API-Aufrufe zum Erstellen dieser Strukturen sowie zum Extrahieren ihres Inhalts und zum Abfragen des darin enthaltenen Inhaltstyps.

Der Apple Event Manager unterstützt ebenfalls Zwänge, die AEDescs von einem Datentyp in einen anderen konvertiert. Zusätzlich zu Standardzwängen, beispielsweise zwischen ganzzahligen und reellen Typen, können Anwendungen ihre eigenen Rückrufe für Zwangshandler installieren, die Konvertierungen in und von benutzerdefinierten Datentypen verarbeiten.

Ein Apple Event Richtig ist ein AERecord mit Feldern, die vom Zweck des Ereignisses abhängen. Darüber hinaus hat es Attribute (die sich von Datensatzfeldern unterscheiden, die jetzt als bezeichnet werden Parameter des Ereignisses) aus einem vom Apple Event Manager vordefinierten Satz. Diese geben an, was das Ereignis tun soll (durch Ereignisklasse und Ereignis-ID), die Zieladresse, an die das Ereignis gesendet werden soll (dies kann ein Prozess auf dem lokalen oder einem Remotecomputer sein), und verschiedene andere Optionen für die Behandlung. Remotecomputer mussten zunächst über AppleTalk verbunden werden, Mac OS 9 fügte jedoch die Option für Verbindungen über TCP / IP hinzu.

Nach dem Senden eines Apple-Ereignisses an den Zielprozess kann der Sendevorgang festlegen, dass ein Apple-Antwortereignis empfangen wird. Dies kann verschiedene vom Ziel zurückgegebene Informationen über die Verarbeitung des ursprünglichen Ereignisses enthalten, einschließlich eines Fehlercodes, der Erfolg / Misserfolg anzeigt, aller vom ursprünglichen Ereignis angeforderten Informationen und / oder anderer geeigneter Informationen.

Apple-Ereignisse bilden die Grundlage für das AppleEvent-Objektmodell, das wiederum die Grundlage für OSA und AppleScript bildet. Ab 2016Die offizielle Implementierung der Apple Event Manager-API ist in C und seinen Nachkommen, einschließlich C ++, verfügbar. Offizielle Bindungen werden auch für Objective-C und Swift über die Cocoa-API bereitgestellt. Inoffizielle Bindungen bestehen auch für andere Sprachen (mit unterschiedlichen Einschränkungen), einschließlich Perl, UserTalk, Ruby und Python.

Objektmodell[edit]

Das AppleEvent-Objektmodell ((AEOM) war eine Reihe von Protokollen, die auf AppleEvents basierten und mit denen Anwendungen, die unter klassischem Mac OS und macOS ausgeführt wurden, die Funktionen des anderen steuern konnten. Anwendungen, die einen Teil des AEOM implementiert haben, wurden aufgerufen skriptfähig weil sie über AppleScript gesteuert werden könnten. Leider blieb die Unterstützung der Skriptfähigkeit während der gesamten Geschichte des klassischen Mac OS lückenhaft und inkonsistent.

Das AEOM stellte eine syntaktische Ebene bereit, unter der jede Anwendung ihre internen Objekte veröffentlichen konnte, sodass diese Objekte auf standardisierte Weise bearbeitet werden konnten. Im Gegensatz zu anderen ähnlich klingenden Konzepten wie ToolTalk gab es eine klare, orthogonale Unterscheidung zwischen Substantive und Verben;; Anstatt separate Befehle für “Dokument schließen” und “Fenster schließen” bereitzustellen, gab es daher ein einzelnes Verb “Schließen”, das Verweise auf “Dokument” – oder “Fenster” -Objekte oder jedes andere von der Anwendung veröffentlichte Objekt enthalten konnte.

Die Objekte, die eine Anwendung über ihre AEOM-Unterstützung zur Verfügung gestellt hat, wurden in einer Hierarchie angeordnet. Oben befand sich die Anwendung selbst, auf die über einen Nullobjektdeskriptor verwiesen wurde. Auf andere Objekte wurde verwiesen, indem (rekursiv) ihr übergeordnetes Objekt angegeben wurde, zusammen mit anderen Informationen, die es als untergeordnetes Objekt dieses übergeordneten Objekts identifizierten, die alle in einem AERecord gesammelt wurden. Ein Iterator wurde von Eltern bereitgestellt, um ihre Kinder oder Kinder einer bestimmten Klasse aufzulisten, sodass Anwendungen eine Reihe von Elementen ansprechen können. Das System ähnelte im Allgemeinen dem in XML verwendeten Dokumentobjektmodell, jedoch mit einigen Unterschieden in den Zugriffsmustern.

Jedes Objekt könnte haben Elemente und Eigenschaften;; Elemente waren andere Objekte, die erstellt oder gelöscht werden konnten, während Eigenschaften nicht erstellt oder gelöscht werden konnten, sondern Werte hatten, die abgefragt oder geändert werden konnten. Beispielsweise kann die Anwendung ein oder mehrere Fenster haben Elemente Darstellen von Fenstern, die den Inhalt aktuell geöffneter Dokumente anzeigen. Diese Fenster könnten haben Eigenschaften wie Titel, Position und Größe.

Eine Anwendung kann benutzerdefinierte Verben für die Bearbeitung ihrer Objekte definieren. Das AEOM spezifizierte auch verschiedene Standardverben, die (wie erhofft) Anwendungen auf konsistente Weise implementieren würden, wie z. B. Öffnen, Schließen, Erstellen von Elementen, Löschen, Festlegen von Daten und Abrufen von Daten. Jedes Verb wurde als AppleEvent eines bestimmten Typs und einer bestimmten Klasse definiert, zusammen mit bestimmten Parametern bestimmter Typen, von denen erwartet wurde, dass sie vorhanden sind. Beispielsweise war das Ereignis “Daten abrufen” das Standardmittel zum Abrufen des Werts einer Eigenschaft: Es wurde im Wesentlichen ein Parameter verwendet, bei dem es sich um einen Objektdeskriptor handelte, der die abzufragende Eigenschaft identifizierte. Der Wert dieser Eigenschaft wird im Antwortereignis zurückgegeben. Das Ereignis “Daten festlegen” hat zwei Parameter verwendet, den Objektdeskriptor für die festzulegende Eigenschaft und den neuen Wert für die Eigenschaft. Es wurde nur erwartet, dass das Antwortereignis einen Erfolgsstatus oder einen Fehlercode zurückgibt.

Die gesamte AppleEvent-Architektur identifiziert Dinge mithilfe von 4-Byte-OSType-Codes, wobei tatsächliche Wörter oder Phrasen in Englisch (oder einer anderen Sprache) sorgfältig vermieden werden. Stattdessen wird die Entsprechung zwischen internen AppleEvent-Codes und externen Beschreibungen in natürlicher Sprache durch das angegeben aete ((AppleEvent-Terminologieerweiterung) resource – Die “Erweiterung” entspricht der in AppleScript selbst integrierten Standardterminologie. Eine Anwendung kann mehrere ‘aete’-Ressourcen für mehrere Sprachen bereitstellen, entsprechend dem ursprünglichen mehrsprachigen Design von AppleScript

Betrachten Sie beispielsweise die folgende AppleScript-Sequenz, die eine fiktive Zeichenanwendung steuert:

 tell application "ScriptableDraw"
   set background color of window "New Drawing" to background color of window "Old Drawing"
 end tell

Dies beinhaltet tatsächlich das Senden von zwei AppleEvents an die Zielanwendung (und den Empfang der entsprechenden Antworten): Zuerst wird ein Get-Data-Ereignis gesendet, um die Hintergrundfarbeneigenschaft des Fensters abzurufen, das durch den Namen “Old Drawing” gekennzeichnet ist. Anschließend wird ein Set-Data-Ereignis gesendet, um den als Hintergrundfarbeneigenschaft des Fensters mit dem Namen “New Drawing” zurückgegebenen Wert anzuwenden.

Da diese Art von Zugriffsmuster typisch war, nutzte AppleScript das tell Anweisung, die den Kontext auf ähnliche Weise wie das benannte Objekt umschaltete with Anweisung in Visual Basic oder Pascal gefunden. Alle Befehle nach dem tell zum entsprechenden end tell würde an das im tellanstelle des Standardobjekts, das die aktuelle Anwendung war.

Objektdeskriptoren ermöglichten die Identifizierung von Objekten auf verschiedene Weise. Am interessantesten war die Verwendung einer where-Klausel (die in die AppleScript-Terminologie als übersetzt wurde Filterausdruck). Beispielsweise wurde das AppleScript 1.0 SDK mit dem Quellcode für eine Beispielanwendung namens Scriptable Text Editor ausgeliefert, die auf Skripte wie die folgenden reagiert:

 tell application "Scriptable Text Editor"
   tell window "Example Document"
     set text style of every word whose length > 7 to bold
   end tell
 end tell

Bis heute ist es selten, dass diese Art von Leistung in universellen Skriptsprachen außerhalb von SQL zu finden ist.

Das Hinzufügen von Unterstützung für AEOM unter dem klassischen Mac OS war ein schwieriger Prozess. Anwendungsentwickler mussten ihre Objekte identifizieren und Code von Hand schreiben, damit sie angesprochen werden konnten. Dies erfolgte normalerweise in Form von Code für die Rückgabe des “nächsten” Objekts eines bestimmten Typs, sodass AppleScript darüber iterieren kann. Da das Betriebssystem jedoch kein Objektmodell enthielt, wurde diese Arbeit ausschließlich den Entwicklern überlassen, von denen viele es nicht implementierten. Seltsamerweise bot sogar Apples eigenes Anwendungsframework, MacApp, kein solches Modell an, mit Ausnahme der ihm bekannten GUI-Objekte, was den Entwickler erneut dazu veranlasste, den größten Teil der Skripterstellung für die Objekte durchzuführen, die die Daten selbst darstellen. Vor allem aus diesen Gründen war die AppleScript-Unterstützung nicht sehr verbreitet.

Apple hat versucht, dieses Problem mit der Einführung verschiedener Objekt- “Suites” zu lösen, die Standardobjekte und -verben darstellten, von denen erwartet wurde, dass sie von verschiedenen Arten von Anwendungen unterstützt werden. Beispielsweise wurde von allen Anwendungen erwartet, dass sie die “Kernsuite” unterstützen, und von jedem Anwendungsbearbeitungstext wurde erwartet, dass er die “Textsuite” unterstützt. Durch die Auswahl eines geeigneten Satzes von Suiten könnte der Entwickler zumindest den Arbeitsaufwand für die Planung der Belichtung seiner Objekte verringern. Da diese Objekte jedoch im Allgemeinen nicht Teil des Systems selbst waren (mit Ausnahme des stark eingeschränkten TextEdit-Editors), wurde die eigentliche Implementierung dem Entwickler überlassen.

In Cocoa, dem System, das früher als OpenStep bekannt war, entwickelte Anwendungen bieten eine umfangreiche Objektlaufzeit, die von jeder anderen Anwendung abgefragt werden kann. Dies erleichtert die Implementierung des AEOM erheblich und reduziert den Codebedarf in einer durchschnittlichen Anwendung erheblich. Darüber hinaus besteht die Mehrzahl der Cocoa-Anwendungen hauptsächlich aus Cocoa-Standardobjekten, die alle aktualisiert wurden, um eine ziemlich umfangreiche Skriptfähigkeit zu bieten. Dies gilt nicht nur für GUI-Objekte wie unter MacApp, sondern auch für darin enthaltene Datenobjekte, einschließlich Text, Tabellen und verschiedene Listenobjekte. Eine Textdatei wird verwendet, um die internen “objektähnlichen” Namen auf lesbare Versionen abzubilden. In den meisten Fällen reicht es aus, diese zu erstellen, um den meisten Programmen eine ziemlich umfangreiche Skriptfähigkeit zu verleihen.

Während Cocoa-Anwendungen nicht auf AEOM basieren und häufig subtil andere Objekte als die ursprünglich definierten Standardobjekte von Apple verwenden, sind Cocoa-Apps im Allgemeinen viel skriptfähiger als ihre “klassischen” Gegenstücke – tatsächlich ist es ungewöhnlich, eine Cocoa-Anwendung zu finden nicht bis zu einem gewissen Grad skriptfähig.

Weiterführende Literatur[edit]

  • Cook, William R. (29. September 2006), AppleScript (PDF), University of Texas in Austin, S. 1–1–1–21, CiteSeerX 10.1.1.76.6993, doi:10.1145 / 1238844.1238845abgerufen 9. Mai 2009. Siehe insbesondere Abschnitt 2.3 „Apple Events“ (Seiten 9–13), obwohl die Geschichte und Bedeutung von Apple Events auch an anderer Stelle in diesem Dokument erörtert wird.

Externe Links[edit]


after-content-x4