アップルのイベント

Apple イベントは、 Mac OSのメッセージベースのプロセス間通信メカニズムで、 System 7で初めて登場し、それ以降のクラシック Mac OSのすべてのバージョンとmacOSでサポートされています。Apple イベントは、「ドキュメントを開く」や「ファイルを印刷する」などの「高レベル」イベントを表しますが、それ以前の OS は「クリック」や「キーを押す」など、はるかに基本的なイベントをサポートしていました。Apple イベントは、Mac OS スクリプト システムであるOpen Scripting Architecture (その主要言語はAppleScript ) の基礎を形成します。

出発点は、AEDescと呼ばれる動的に型付けされた拡張可能な記述子形式です。これは、データ型を指定するOSTypeコードと、型依存データのブロックを組み合わせたものです。たとえば、OSType コードは、inteデータがビッグ エンディアン形式の 4 バイトの符号付き整数であったことを示します。

さまざまな一般的な単純型の定義済み型コードのほかに、定義済みの構造化記述子型が 2 つあります。データ型 (レコード) を持つAERecordrecoと、型 (リストまたは配列) を持つAEList ですlist。これらの内部構造には再帰的にネストされた AEDesc が含まれますが、AERecord は各要素を OSType である一意のレコード フィールド ID に関連付けます。Apple Event Manager は、これらの構造を構築するためのAPI呼び出し、およびそれらの内容を抽出して、それらが保持する内容の種類を照会するための API 呼び出しを提供します。

Apple Event Manager は、 AEDesc をあるデータ型から別のデータ型に変換する強制変換もサポートしています。整数型と実数型間の標準の強制変換に加えて、アプリケーションは、カスタム データ型との間の変換を処理する 独自の強制変換ハンドラ コールバックをインストールできます。

Appleイベント自体は、イベントの目的に応じたフィールドを持つ AERecord です。さらに、 Apple イベント マネージャによって事前に定義されたセットからの属性(レコード フィールドとは異なり、現在ではイベントのパラメータと呼ばれています) があります。これらは、イベントが行うこと (イベント クラスとイベント IDを通じて)、イベントが送信されるターゲット アドレス (ローカル マシンまたはリモート マシンのプロセス)、およびイベントを処理するためのその他のさまざまなオプションを指定します。リモート マシンは当初AppleTalk経由で接続する必要がありましたが、Mac OS 9 ではTCP/IP経由の接続オプションが追加されました。

Apple イベントをターゲット プロセスに送信した後、送信プロセスは Apple イベントへの応答を受信することを選択できます。これには、成功/失敗を示すエラー コード、元のイベントによって要求された情報、およびその他の適切な情報など、元のイベントの処理に関してターゲットから返されるさまざまな情報が含まれます。

Apple イベントはAppleEvent オブジェクト モデルの基礎であり、これはOSAとAppleScriptの基礎でもあります。2016 年現在^{[アップデート]}、Apple Event Manager API の公式実装はCおよびC++を含むその派生言語で利用できます。Objective -CとSwift向けの公式バインディングはCocoa APIを通じて提供されています。Perl 、UserTalk 、Ruby、Pythonなど他の言語向けの非公式バインディングも存在します (制限の度合いはさまざまです) 。

AppleEventオブジェクト モデル( AEOM ) は、 AppleEvent上に構築されたプロトコルのセットであり、これによりクラシック Mac OSおよびmacOSで実行されるアプリケーションが互いの機能を制御できました。AEOM の一部を実装したアプリケーションは、AppleScript経由で制御できるため、スクリプト可能と呼ばれていました。残念ながら、スクリプト可能のサポートは、クラシック Mac OS の歴史を通じて、不完全で一貫性のないままでした。

AEOM は、あらゆるアプリケーションが内部オブジェクトを公開できる構文レイヤーを提供し、それらのオブジェクトを標準化された方法で操作できるようにしました。ToolTalk などの他の似たような概念とは異なり、名詞と動詞の間には明確な直交的な区別がありました。したがって、「ドキュメントを閉じる」と「ウィンドウを閉じる」という別々のコマンドを提供する代わりに、「ドキュメント」または「ウィンドウ」オブジェクト、またはアプリケーションが公開したその他のオブジェクトへの参照を取得できる単一の「閉じる」動詞がありました。

アプリケーションが AEOM サポートを通じて利用可能にするオブジェクトは、階層構造になっています。最上位にはアプリケーション自体があり、ヌル オブジェクト記述子を介して参照されます。他のオブジェクトは、親オブジェクトを (再帰的に) 指定することで参照され、そのオブジェクトをその親の子として識別するその他の情報もすべてAERecordに収集されます。親は反復子を提供して子または特定のクラスの子を列挙し、アプリケーションが一連の要素を処理できるようにします。このシステムは、アクセス パターンに若干の違いはあるものの、 XMLで使用されるドキュメント オブジェクト モデルとほぼ同様です。

各オブジェクトには要素とプロパティがあります。要素は他のオブジェクトであり、作成または削除できますが、プロパティは作成または削除できませんが、照会または変更できる値を持ちます。たとえば、アプリケーションには、現在開いているドキュメントの内容を表示するウィンドウを表す 1 つ以上のウィンドウ要素がある場合があります。これらのウィンドウには、タイトル、位置、サイズなどの プロパティがあります。

アプリケーションは、そのオブジェクトを操作するためのカスタム動詞を定義できます。AEOM では、開く、閉じる、要素の作成、削除、データの設定、データの取得など、アプリケーションが一貫した方法で実装する (ことが期待される) さまざまな標準動詞も指定されています。各動詞は、特定のタイプとクラスの AppleEvent として定義され、特定のタイプの特定のパラメータが存在が期待されていました。たとえば、「データ取得」イベントは、プロパティの値を取得するための標準的な手段でした。このイベントは、基本的に 1 つのパラメータ (クエリするプロパティを識別するオブジェクト記述子) を受け取りました。そのプロパティの値は、応答イベントで返されます。「データ設定」イベントは、設定するプロパティのオブジェクト記述子とプロパティの新しい値の 2 つのパラメータを受け取りました。応答イベントは、成功ステータスまたは失敗エラー コードのみを返すことが期待されていました。

AppleEvent アーキテクチャ全体は、4 バイトのOSTypeコードを使用して物事を識別し、英語 (または他の言語) の実際の単語やフレーズを意図的に避けています。代わりに、内部の AppleEvent コードと外部の自然言語の説明との対応は、aete ( AppleEvent Terminology Extension )リソースを通じて指定されます。この「拡張」は、AppleScript 自体に組み込まれている標準用語に対するものです。アプリケーションは、AppleScript 自体の元の多言語設計に従って、複数の言語に対して複数の 'aete' リソースを提供することができます。

たとえば、架空の描画アプリケーションを制御する次の AppleScript シーケンスを考えてみましょう。

 tell  application  "ScriptableDraw" 
   set  background color  of  window  "New Drawing"  to  background color  of  window  "Old Drawing"をアプリケーション "ScriptableDraw" に渡します
 。end tell 

実際には、これには、ターゲット アプリケーションへの 2 つの AppleEvent の送信 (および対応する応答の受信) が含まれます。まず、get-data イベントが送信され、「Old Drawing」という名前で識別されるウィンドウの背景色プロパティが取得されます。次に、set-data イベントが送信され、「New Drawing」という名前のウィンドウの背景色プロパティとして返された値が適用されます。

この種のアクセス パターンは一般的であるため、AppleScript では、Visual BasicやPascalの ステートメントにtell似た方法でコンテキストを名前付きオブジェクトに切り替える ステートメントが広く使用されました。 以降の対応する へのすべてのコマンドは、現在のアプリケーションである既定のオブジェクトではなく、で名前が付けられたオブジェクトに送信されます。 withtellend telltell

オブジェクト記述子を使用すると、さまざまな方法でオブジェクトを識別できます。最も興味深いのは、where 句 (AppleScript 用語ではフィルター式として翻訳されます) を使用することです。たとえば、AppleScript 1.0 SDKには、次のようなスクリプトに応答する Scriptable Text Editor と呼ばれるサンプル アプリケーションのソース コードが同梱されていました。

 tell  application  "Scriptable Text Editor" 
   tell  window  "Example Document"
     長さが7を超えるすべての単語のテキストスタイルを太字に設定する end tell end tell          
    
  

今日でも、 SQL以外の汎用スクリプト言語でこのようなパワーを見つけることはまれです。

従来の Mac OSに AEOM のサポートを追加するのは困難なプロセスでした。アプリケーション開発者はオブジェクトを識別し、それらを処理できるようにコードを手書きする必要がありました。これは通常、特定のタイプの「次の」オブジェクトを返すコードの形を取り、AppleScript がそれらを反復処理できるようにします。しかし、OS にはオブジェクト モデルが含まれていなかったため、この作業は完全に開発者に任されていましたが、その多くはそれを実装していませんでした。奇妙なことに、Apple 独自のアプリケーション フレームワークであるMacAppでさえ、認識しているGUIオブジェクトを除いてそのようなモデルを提供しなかったため、ここでもデータ自体を表すオブジェクトのスクリプト作成作業のほとんどを開発者が行う必要がありました。主にこれらの理由により、AppleScript のサポートはあまり普及していませんでした。

Apple は、さまざまなオブジェクト「スイート」を導入することでこの問題に対処しようとしました。これは、さまざまなタイプのアプリケーションでサポートされることが期待される標準オブジェクトと動詞を表します。たとえば、すべてのアプリケーションは「コア スイート」をサポートすることが期待され、テキストを編集するすべてのアプリケーションは「テキスト スイート」をサポートすることが期待されました。適切なスイート セットを選択することにより、開発者は少なくとも、オブジェクトの公開方法を計画する作業負荷を軽減できます。ただし、これらのオブジェクトは一般にシステム自体の一部ではないため (非常に制限された TextEdit エディターを除く)、実際の実装は開発者に任されていました。

Cocoa (以前はOpenStepと呼ばれていたシステム)で開発されたアプリケーションは、他のアプリケーションからクエリできる豊富なオブジェクト ランタイムを提供します。これにより、AEOM の実装が大幅に簡単になり、平均的なアプリケーションに必要なコードの量が大幅に削減されます。さらに、Cocoa アプリケーションの大部分は主に Cocoa 標準オブジェクトから構築されており、それらはすべて、かなり広範なスクリプト機能を提供するようにアップグレードされています。これは、MacApp の GUI オブジェクトだけでなく、テキスト、テーブル、さまざまなリスト オブジェクトなど、それらの内部のデータ オブジェクトにも適用されます。テキスト ファイルは、内部の「オブジェクトのような」名前を人間が読めるバージョンにマップするために使用されます。ほとんどの場合、これを作成するだけで、ほとんどのプログラムにかなり充実したスクリプト機能を追加できます。

Cocoa アプリケーションは AEOM ベースではなく、Apple が元々定義した標準オブジェクトとは微妙に異なるオブジェクトを使用することが多いですが、Cocoa アプリケーションは一般に「クラシック」なアプリケーションよりもはるかにスクリプト化しやすく、実際、ある程度スクリプト化でき ないCocoa アプリケーションを見つけることはまれです。

Scripting Bridgeは、 AppleScriptなどの中間スクリプト言語を使用せずにアプリケーションが相互に通信できるようにするmacOSフレームワークです。AppleScriptと同様に、Scripting Bridgeはアプリケーション間通信にAppleイベントを使用します。^[1]

スクリプティングブリッジは通常Objective-C ^[1]から使用されますが、 MacRuby ^[2]やPyObjCなどのObjective-Cブリッジを介して他のプログラミング言語でも使用できます。

• Cook, William R. (2006 年 9 月 29 日)、「AppleScript」(PDF)、プログラミング言語の歴史に関する第 3 回 ACM SIGPLAN 会議の議事録、テキサス大学オースティン校、pp. 1–1–1–21、CiteSeerX  10.1.1.76.6993、doi :10.1145/1238844.1238845、ISBN 9781595937667、S2CID  220938191 、2009年5月9日取得{{citation}}: CS1 メンテナンス: 場所が見つかりません 発行者 (リンク)特に、セクション 2.3「Apple イベント」(9 ～ 13 ページ) を参照してください。ただし、Apple イベントの歴史と重要性については、このホワイト ペーパーの他の場所でも説明されています。

• appscript — Python、Ruby、Objective-C 用の Apple イベント ブリッジ