AppleScriptObjCのアプリをスクリプタブルにする話の続きです。

とりあえず、３０分もかからずにASOCアプリをスクリプタブルにできました。超簡単です。

そこで、以前から疑問に思っていたことをテストしてみました。

Xcode上では、プロジェクトを構成するさまざまなファイルをローカライズすることが可能です。つまり、各国語環境用に個別にファイルを用意しておいて、対応する言語環境で別々の内容を表示させることができるようになっています。

そこで、sdefファイルをローカライズして、日本語環境下では日本語の解説文が入ったAppleScript用語辞書を表示させられるかを試してみました。

▲ローカライズされたAppleScript用語辞書。日本のユーザーしか使わないようなツールに英語だけの用語辞書を付けておくことはナンセンス。このようにして分かりやすくできる

結果はばっちり大成功。日本語環境では、日本語で説明の入ったAppleScript用語辞書がオープンされることが確認できました。こうして英語の用語辞書のほかに日本語の用語辞書を用意しておけばよいのではないか？　と思われました。

→　プロジェクトのダウンロード（90Kバイト）

※記事掲載当初はアーカイブのダウンロードリンクが切れていました。2012/4/15現在は修正してあります

■総評

正直、AppleScriptで書かれたプログラムをAppleScriptから呼び出すのだから、処理内容自体を呼び出し側に書けばよいようにも思えますし、速度の面でもあまりメリットが感じられません。

リスト要素のソートなど、Cocoaの機能を用いると高速化できるものもありますが、Mac OS X 10.7以降であればAppleScriptエディタ上で直接AppleScriptObjCのプログラムが記述でき、Cocoaの機能も呼び出すことができます。わざわざ、操作が繁雑なXcode上でそれを行うメリットが大きいとも思えません。

AppleScriptでOSAX（のようなもの……つまり、Invisible Processでウィンドウとかメニューなどを持たないアプリ）に近いものが作れるわけで、それについてはなかなか便利でしょう（ライブラリを整備するのと自前OSAX作成とどちらが労力が少なくて済むかは、判断つきかねます）。

ですが……単純にやってみて「おもしろい」と感じられました。もっと高度な命令も実装できることが確認できれば、応用範囲がいろいろと広がるのではないかと思われました。

AppleScript用語辞書の（言語環境に応じた）ローカライズや、一部のAppleのアプリケーションで試行されているサンプルスクリプトの用語辞書への同梱など、「こうできた方が便利では？」というアイデアを試す場として利用できる、とは思っています。

スクリプタブルなアプリケーションを作るのがここまで簡単だとは思わなかったので、そのことが分かったことが最大の成果だと感じました。他人のプログラムを見ながら試して、動くようになるのに30分もかかりませんでした。

AppleScriptObjCアプリをスクリプタブルにした話の続きです。

r/oの属性ばかりではなく、書き換えできる属性値を用意し、これをGUIにつないで書き換えが目で見て分かるようにしてみました。

さきほどの用語辞書の属性値「message」はsdefファイルの定義によりAppleScriptObjCプログラム中の「theMessage」プロパティに対応。さらに、Xcode上でtheMessageプロパティをNSTextFieldのvalueにバインドしてみました。

アプリケーション「asoc1」を実行すると、こんな感じです。

上記のAppleScriptを実行すると、

のようにテキストフィールドの内容が変化します。逆に、テキストフィールドの内容を「message」属性を介して取得することもできます。

ただし、テキストフィールドに文字入力中の内容を取得しようとした場合、すぐにテキストフィールドの内容に対する変更が値に反映されないなどの現象が見られました。そこで、Xcode上でテキストフィールドのvalueをバインドしているところで、

「Continuously Updates Value」のチェック項目があるので、チェックを入れると……入力した内容がすぐに属性「message」に反映されるようにはなるのですが、今度はアプリケーションの動作が若干もたつく感じがしました。外すとそのようなことはなくなったので、少しひかえめな連動を行うべきなのかもしれません。

「ひかえめな連動」というのは、GUI上で入力中のフィールド内容を即座に求めるのではなく、内容が確定して環境設定に書き込んだ内容に対してアクセスするような連動、ということです。キーボード入力された内容をすぐ取得するのは避けたほうがよいでしょう。

MacScripter.netで探してAppleScriptObjCアプリをAppleScript対応（スクリプタブル）にする方法を確認してみました。貴重な情報を提供してくれている投稿者の方々には深く感謝しています。

実際の投稿記事はこちら。この一連の記事は同投稿を精査して、より単純化して資料を加え解説するものです。

■Info.plistを編集

まずはXcode上でAppleScriptObjCのプロジェクトを１つ作成してみましょう。サンプルでは、「asoc1」という名前のプロジェクトを作成しました。

最初に、Info.plist（各Xcodeプロジェクト内でのファイル名は異なります。上の画面では「asoc1-info.plist」が該当）を編集し、キーが「Scriptable」値が「Yes」（Boolean）、キーが「Scripting Definition file name」値が「myApp.sdef」のエントリ（合計２つ）を作成します。

■sdefファイルをプロジェクトに追加する

sdef（Scripting DEFinition）ファイルをプロジェクトに追加します。Xcodeで「New File」を実行し、「empty file」をプロジェクトに追加。追加ファイルのファイル名を「myApp.sdef」とします。

内容はこんな感じ。画像では内容が見えない場合には、あとでアーカイブ中の実物を見てください。

なお、sdefファイルの記述がもっと簡単にできる、Shadow Labの「Sdef Editor」というフリー・ソフトウェアが存在します。もっと込み入ったAppleScript用語辞書を作成する場合には、同ソフトウェアを併用するとよいでしょう。

▲Shadow LabのSdef Editor

■AppleScriptObjCプログラム側にハンドラ追加

on application_delegateHandlesKey_(sender, theKey)　ハンドラを追加。予約語messageに対応する「theMessage」を受信したときにtrueを返します。ただ、それだけ。

■AppleScriptObjCプログラム側にプロパティ追加

property theMessage : missing value

これだけ追加しておきましょう。

■ためしに、ビルド

これでXcode上でCommand-Rでビルド＆実行するだけで、スクリプタブルなアプリケーション（AppleScript用語辞書つき）になります。アプリケーションに対してプロパティを取得すると、これだけでアプリ名やバージョン番号などの最低限の情報を取得できます。

AppleScript用語辞書をAppleScriptエディタでオープンして内容を確認することも可能です。

AppleScriptObjCの世界をほぼ１人で引っ張っている感のある、Shane StanleyによるAppleScriptObjCに特化したスクリプトエディタが「AppleScriptObjC Explorer 2」です。

▲構文色分けがまったくできていないXcode 4（左）と構文色分けに対応しているAppleScriptObjC Explorer（右）

▲インデントも正確なAppleScript Explorer 2

まだ使い始めて日が浅いのですが、その特徴を紹介すると……

・Xcode 4ではまったく効かない「AppleScriptの構文に応じた色分け」ができる（これはでかい！　というか、Xcode 4がダメすぎ）
・Xcode 4ではまったくダメな「インデント」が正確（Xcode 4、本当にダメすぎ）
・Xcode 4では絶望的な、ログ表示機能を備える
・単体で動作可能なAppleScriptObjCベースのアプリケーションを作成可能
・Xcode 4の外部エディタとして動作可能（XcodeでScriptのファイルを選択して、コンテクストメニューから「Open With External Editor」を実行。あらかじめFinder上で拡張子とアプリケーションの関連を変更しておく必要がある）

・定番の処理（Arrayを作るとか、ソートするとか）はメニューからScript本文中にInsert可能

・Script文中で入力補完機能を利用可能（ここだけ、まだ試していない）

といったところでしょうか。AppleScriptObjCが使えるMac OS X 10.6/10.7で動作します。

構文色分けができないとプログラミング効率が悪すぎるのと、インデントが正確でないXcode 4にシビレを切らしてAppleScriptObjC Explorerを購入（5,000円……為替レートの変動で変わる？？）。

ただ、デバッグ機能についてはアプリケーション起動時に呼ばれる「applicationWillFinishLaunching_」イベントハンドラの中で実行されるコードしかデバッグできなさそうなので、デバッグ機能に期待して購入すると、期待外れになってしまうかもしれません。

総合的には……残念ながら、値段の割には……と、感じる点が多々あります。

AppleのCocoaについてのヘルプからAppleScriptObjC用のヘルプとして変換して表示するとか、既存のObjective-Cのコードをプロジェクトにインポートすると、その呼び出し用のAppleScriptObjCコードがScript本文中に展開されるとか……そういう機能を期待したいところです。

いまの段階では、ちょっと気の利いた構文色分けエディタ、というレベルです。それ以上でもそれ以下でもありません（Shane Stanleyへのお布施、という意味ではとても意義があるかもしれない）。

とりあえず30日間は試用ができるため、Xcode 4にブチ切れまくっている方は試してみるとよいでしょう。

AppleScriptObjCで作成したプログラムが、実際に作業で使ってみたらメモリを馬鹿喰いして困る、という話を海外でよく見かけます。

自分も、1,000色ほどの色セットと任意の色の近似色を求めるAppleScriptObjCのプログラムを作成し、任意の１色の近似色検索を行う分には問題なかったものの……まとめて数十〜数百色を処理しようとしたところ、MacBook Pro搭載の8GBのメモリーをアレヨアレヨという間に喰いつぶされてしまいました。

その時には急いでいたので、根本的な解決をあきらめ……近似色検索処理だけを通常のAppleScriptのアプレットに追い出し、AppleScriptObjCのプログラムからAppleScriptアプレットをtell文で呼び出すように処理変更。

余計なプロセス間通信を行うので、余計に時間がかかるようになりましたが、メモリを喰いつぶしてスワップしまくるよりはマシという判断でした。事実、プロセス分離を行う前よりもずいぶん処理速度が落ちたのですが……背に腹はかえられません。

後日、時間に余裕があるときに調査を行ったところ……以前に掲載したCocoaベースのソートルーチンが問題の発生源であることが判明（わかってたけど）。

その場でプログラムから作成したオブジェクトについては、ループ処理などで後続の処理がすぐに発生した場合……自動的にはメモリー上から解放されないということが分りました。

ソートルーチンはサブルーチン化しておいたので、AppleScript的にはローカル変数などで処理される安全な「離れ小島」ですが、Cocoaアプリケーション的には「離れ小島ではない」という状態だと理解しました。

解決策は、作成したオブジェクトを明示的にリリース（release）すること。ほんの短い追加ではあるものの、数百件のデータを処理してもまったくメモリーを馬鹿喰いすることなく、処理を継続できました。

このあたり、Info.plistの記述を書き換えると回避できる問題なのかどうか、もうちょっと調べる必要がありますが……

AppleScriptObjCでさまざまな小物ツールを作っては日常的に使っています。

ただ、困ったことに……大量のリスト型変数を扱うのに必須な、「a reference to」によるリスト型変数の間接アクセスによる高速化が、AppleScriptObjCの環境では使えません（プログラム中に記述できるものの、実行時にエラーになってしまいます）。

そこで、いろいろ高速化の手段はないものかと考えることに。

実際に、カラーピッカーで選んだ任意の色の類似色を1,000色ぐらいの色見本データからピックアップして提示する、というツールを作ってみたときに、a reference toによるアクセスができず、AppleScriptエディタ上で動作させるよりも遅くなってしまいました。これは由々しき事態です。

そこで、同じ問題に直面している人がいるのではないかと考え、海外のサイトを探し回り……MacScripterでそのものズバリの内容を見つけました。

「Objective-Cに書き換えれば高速化が……」という身もふたもない内容の投稿もありましたが、a reference toと同程度の高速化が実現できる手法を見つけ、実際に自分のコードに入れてみて効果を確認。

それが、script文によって（論理的に）別Scriptにpropertyを追い出して、別Script上のpropertyにアクセスするというものです。

script speedUp
　　property aList:{}
end script

script mainScriptDelegate

　　set the end of speedUp’s aList to 1
　　
end script

のように間接アクセス。これで10倍以上の（こまかく計測していないのですが）スピードアップが図れました。たかだか1,000項目ぐらいではテストデータとしては小さすぎるので、数万アイテムぐらいのテストデータを作って、別途試してみたいところです。

このほか、ソートルーチンにいつものshell sortではなくCocoaベースのソートルーチンを投入してみました。ちょっとこちらの効果は定かではないのですが、前述の近似色サーチのAppleScriptObjCプログラムでは、

　スピードアップいっさいなし：８〜10秒ぐらい
　＋Cocoaベースのソートを投入：３〜４秒ぐらい
　＋Script文による間接アクセス適用：１秒以下

ぐらいの差が出たので、Cocoaベースのソートルーチンもそれなりに効いているのでしょう。このCocoaベースのソートルーチンは、{{age:20, aName:”ひよこさん”}, {age:43, aName:”ぴよぴよ”}}のような構造のリストをソートするものです。入れ子のリスト……というと厳密には正しくはないですね。レコードのリストというべきか。KeyItemには”age”とか”aName”といったラベルを指定します。

OS X 10.7, Lionからはネットワーク経由での複数GUIログインができるようになりました。つまり、１台のLionのMacに対して、LAN経由でWindowsとかiPadなどの上で動くVNCソフトウェアから同時にログインしてMac上のGUIアプリを使えるようになっています。

GUIログインしたユーザーアカウントで、それぞれアプリケーションを起動して、１台のMacの中で複数のユーザー環境間でAppleEventを投げ合ってアプリケーションをコントロールすることができるようになりました。

じゃあ、現在のユーザーアカウントから、「画面共有」アプリをコントロールして、複数GUIログインを実行できないのか？　複数GUIログインを行うプロセスそのものもAppleScriptで自動化してしまえば、実行するのに時間がかかって一度に１つしか起動できないアプリケーション（InDesignとか、Illustratorとか、SAPとか、、）を１台のマシン上で同時に複数起動。１つのAppleScriptから複数のアプリケーションを同時にコントロールするようなことができるんじゃないか？　と、考えていろいろ試してきました。

結論からいえば、「すべての手順を自動化できてはいない。けれど、複数のGUIログインしたユーザー環境の間でアプリケーション制御はできている」というのが現状です。

まず、普通に「画面共有」アプリにlocalhost接続を命令すると「自分の画面は共有できません」といってハネられます。しかし、ポート番号をつけてやるとその制限を無視されるようになります。

AppleScriptエディタ上で「open location “vnc:localhost:5901″」などと書いて実行すると、現在使用中のマシンに対して「画面共有」アプリ経由で多重ログインが行えます。

＃　ポート番号は5900〜6000の間で使用可能（vnc用にリザーブされているポート番号）
＃　「vnc://localhost」ではなく「vnc:localhost」でした（転記ミス）

ユーザー認証が通ると、画面を切り替えるか、仮想画面を使用するか聞いてくる。仮想画面を選択すると……

現在のMacの画面内に、同じMacに別アカウントからアクセスするウィンドウがオープンする。

ここまできちんと機能が実装されていながら、「画面共有」でlocalhost（自分）を指定するとハネられる仕様になっているのは、動作に一部問題があるから？　別アカウントのユーザー環境を操作しようとすると、レインボーカーソルが回りっぱなしになってリモート側の操作が行えなくなることが多々ありました（電源ボタンを押してダイアログを出すと解除された）。

ユーザー名「user1」、パスワード「user1」というアカウント（同一マシン上）に対してリモート制御。すでに起動してあるiCalに対してコントロール。これを行う前に、かならず「システム環境設定」の「共有」で「リモートアップルイベント」をオンにしておく必要がある。

別ユーザー上のiCalに「hiyoko」という新しいカレンダーを作成してみたところ。

別ユーザーのiCal上に「hiyoko」カレンダーが作成された。LANごしにコントロールしているわけではないので、スピードも速い。

「画面共有」アプリのウィンドウを縮小したところ。別アカウントのウィンドウが左側に小さく表示されている。

「画面共有」アプリのウィンドウはクローズしてしまっても、ログイン状態は維持される。ためしにクローズしてみても……

別ユーザーアカウント「user1」「user2」はログイン状態が維持されていることが分かります。

１台のMac上で複数ユーザーアカウントのログインを行い、それぞれの環境でGUIアプリケーションを起動してアプリケーション制御を行う……といっても、扱いはLANごしに別マシン上の別アカウント上のアプリケーションをコントロールしているのと同じです。

そのため、リモートのAppleEventを受け付けるアプリケーションでないと直接は制御できない。最近は、セキュリティ維持のためにリモート制御を受け付けないアプリケーションが増えた。

しかし、制御先のユーザー環境にAppleScriptで作ったアプレットを起動しておいて、そのアプレット経由でコントロールするようにすれば、リモート制御非対応のアプリもコントロールできます。

こんな感じで、あり余るCPUパワーを生かすようなシステムを作りやすくなってきた……のかもしれません。

AppleScriptによる並列処理サンプルのバージョンv3aです。v3を外部公開できるよう、実際のメイン処理部分をすべて削除して、並列処理の評価用に最小限のダミー処理を付加したものです。

本サンプルは、

（１）並列処理呼び出し部分（呼び出す側）「parallelMain_v3a」
（２）並列処理実行テンプレートAppleScript（呼び出される側。スレッド）「mainScript_v2a」

から構成されます。

（１）をAppleScriptエディタで「parallelMain_v3a.app」の名前で、アプリケーションとして保存します。「実行後、自動的に終了しない」にチェックを入れておいてください。

（２）については、通常のAppleScript書類として保存しておいてください（ここでは、「mainScript_v2a」の名前で保存されているものと仮定して説明します）。

parallelMain_v3a.appをFinder上でダブルクリックするなどして起動すると、並列実行するAppleScriptファイルを聞いてきます。「mainScript_v2a」を指定してください。

次に、処理対象フォルダを聞いてきますので、適当にファイルが入っているフォルダを指定してください。本サンプルプログラムではファイルに対して処理は行いません。ただし、処理終了マーク（ラベル）を振るため、ラベルが変更されては困るファイルが入っていないことが前提です。

最後に、結果の書き出し先ファイルを聞かれるので、適当な名前を指定しておいてください。ダミーデータ（乱数データ）がリスト形式で書かれます。

あとは、メイン側がThreadのアプレットを自動生成して起動し、処理ファイルを１つずつThread側に渡して、処理結果を受け取ります。

今後の改良の方向性は、

（a）Threadがコケたりエラー終了した場合のリカバリ
（b）テンプレートAppleScriptがいまひとつ簡潔ではないため、テンプレートのうちThreadとして振る舞うために必要な部分と本当の処理部分を分割して、並列処理を行いやすくする
（c）開発効率を優先して雑に書いた部分をもう少しなんとかする
（d）できれば、CPU負荷を計測してスレッド数を自動で増減させたい（CPUコアの個数分だけThreadを生成し、まだCPUの処理能力にアキがあれば追加するような方向で）

といったところでしょう。

AppleScriptを並列処理するAppleScriptの改良型、v3の実行中のムービーです。

先週末には出来上がっていたのですが、挙動がおかしい箇所があったので地道にデバッグしていました。

並列処理デモv3（5.7MB）

AppleScriptによる並列処理 v2を実際に使ってみての評価です。

■前提となる話

たまたま、大量かつそこそこの容量のテキストファイルの処理をする必要があったので、マシンのCPU性能を生かすために並列処理を行わせてみた。

通常のデスクトップ用アプリケーションを複数同時起動できるわけではないし、複数のAppleScriptアプレットから同時に１つのアプリケーションにアクセスした場合にきちんと排他処理してくれたりするかどうかは不明（昔は、FileMaker Proがbegin transaction〜end transactionの構文をサポートしていたが、他で見かけたことがない）。そんなに高度なことを期待してもダメ。

InDesignとかIllustratorの処理を１台で並列実行とかいう話は無理。ただし、もしもMac OS X10.7になって複数ユーザーが同時ログインして別々のGUI環境を同時に実行できるとかいう環境になってくると、１つのユーザー環境から他のユーザー環境上のアプリケーションをコントロールできる可能性は……ないこともない。

AppleScriptのプログラムを動的に実行バイナリに変換して、同じ仕事を手分けして処理するという程度の話がこの話のゴール地点。テキストファイルの大量処理という話ならけっこう使える。

ひととおり使えるレベルのプログラムに育ったら、１台で複数の処理をやるのと同様に、複数のマシンで分散処理を行うプログラムを作ってみるとよさそう。安くてそこそこの性能のマシンを複数台集めるとか、オフィスや学校にあるMacを夜間に動かして仕事を分散処理させるのはけっこうよさそう。

■評価

処理対象のファイル一覧をスレッド数で分割して、まとめて渡すというやり方はよくない。処理対象のファイルにはサイズにバラツキがあるので、それぞれのスレッドの処理時間がバラバラ。「数」で割って仕事を割り振るのは、無駄が多いことが分かった。

たとえば、４スレッドで並列処理を行っても、割り当て分を終わらせたスレッドは早々にプログラムを終了してしまう。処理が早く終わったスレッドは、処理が終わっていないスレッドの未処理分を処理すべきなのに、それができていない。最後のほうでCPUの利用効率が落ちてしまう。

また、途中でトラブルに遭遇して停止した場合、１スレッド文の処理がいきなりすべて無駄になってしまうのは時間の無駄すぎます。

そのため、１ファイルずつスレッド側に渡して処理するように変更すべきだと思われました。……というか、もう出来上がってテスト中です。

以前に掲載したAppleScriptで並列処理を行うプログラムの改良版です。

１ファイルあたり数千〜数十万行のテキストファイルを数百個処理する必要に迫られ、さまざまな高速化手法を投入してみたものの、通常のAppleScriptでは与えられたファイルを順次実行するだけ。昨今の複数CPUコアが常識化したMacでは、１つのCPUコアが忙しいだけで、他のコアはほとんど遊んでいる状態です。

メニーコアの、無駄に遊んでいるCPUのパワーを絞り出すため、ぴよまるソフトウェアではAppleScriptの並列実行に取り組んできました。

以前に掲載したもの（v1）は、並列処理を行ううえで必要な技術のテストを行うことが目的だったので、実用性はほとんどありませんでした。

今回のv2では、並列処理実行数を柔軟に指定でき、実際に実戦でテストを行って実用性を確認できています。純粋に４スレッド指定した状態で、１スレッド状態の４分の１の時間で処理を終了しています。１時間以上かかる処理が15分程度で終了する、という感じです。

v1では、メイン側とサブ側の間でファイルI/Oを用いてイベントのやりとりを行っていましたが、その後に助言をいただいたりテストを行う中で、「openハンドラ経由でデータをやりとりする場合に、ファイルでやりとりする必要はない」ことが分かってきました（これは知らなかった！）。

コマンド内容を一度ファイルに書き出さず、相手側のアプレットのopenハンドラにlistやrecordを直接渡せるため、信頼性や処理速度の向上が期待されます。

また、v1では（ファイルI/Oの信頼性計測のために）イベントを頻繁にやり取りしていましたが、実際にはそんなに頻繁にイベントのやりとりを行うわけではありません。「一度パラメータを与えれば終了時までイベントのやりとりは行わない」ケースが多いことが予想されます。v2では最初と最後だけイベントをやり取りするようにしてテストを実施しました。

まずは、こちらのAppleScriptを実行形式（実行後終了しない）で保存してください。AppleScriptを呼び出すためのアプレットです。

次に、並列実行されるAppleScriptです。こちらは、普通のAppleScriptとして保存し、アプレット実行時に「並列実行するAppleScriptを選択してください」とダイアログが出るので、その際に指定してください。

この試作品v2では、多数のファイルの処理を行うケースを前提にしており、処理対象ファイルをスレッド数で分割してそれぞれのスレッドに渡すようになっています。

4コアのCore i7の環境で、通常タイプのAppleScriptにくらべて処理時間は大幅に（CPUパワーの許す範囲でスレッド数を増やして）短縮できました。

並列処理で大量のデータを処理する際には、メモリー使用量にも気をつけ、アクティビティ・モニタで監視しながら実行するのがよいでしょう。

▲AppleScript実行中に大量のデータを抱えすぎてえらい状態になっている例

今回は、何度もテスト実行を行いながらスレッド数の最適化を行いましたが、CPUのコア数や世代（Core Duo、Core 2 Duo、Core iなどなど）を取得してスレッド数の自動判定や増減をコントロールできるとよさそうだと思われました。

また、並列処理を行う対象のAppleScriptは、若干書き換える必要がありますが……書き換えを最低限で済ませられるような仕組みも作るとよさそうです（choose fileとかchoose folderのイベントハンドラをAppleScript自身で横取りするとできそう）。

Appleからはほとんどドキュメントもサンプルも出てきていないので、実際にどう書いたらよいのかさっぱり分らなかったAppleScriptObjCですが、海外で電子媒体（PDF）の参考書が出てきたため、ようやく書き方や使い方が分ってきた今日このごろ。

・Hamish Sanderson「Learn AppleScript」/Chapter 30「Creating Cocoa Applications with AppleScriptObjC」（50ページ、25ユーロ（だったか））
サンプルを多数掲載するのではなく、動作原理についてやさしく詳しく解説している入門書的な内容。図版がグレースケールで掲載されていることぐらいしか本書の入門書としての欠点が見つからない。かなり分りやすい。

・Shane Stanley「AppleScriptObjC Explored」（132ページ、$US29.95）
サンプルプロジェクトが豊富なので、さわって動かして学習できる。ただし、細かい動作原理についてはあまり詳しく解説していないので、プログラムを組めるようにはなるものの疑問は残る。

……これらを参考に、AppleScriptObjCのプログラムを組めるようになってきたものの、やはり実戦で使ってみると分らないこともたくさんあります（MacScripterのフォーラムが情報源）。

これまでにハマったポイントをいくつかご紹介しましょう。AppleScript Studioのつもりで扱うと、いろいろとハマるポイントが……

■ウィンドウをクローズして再オープンしようとしたら固まる

アプリケーションのメインウィンドウ上のボタンをクリックして環境設定用のサブウインドウを表示。
環境設定ウィンドウを一度クローズして、再度オープンすると…………クローズボタンが押されたままの状態で固まっており、それ以降の操作を受け付けない。終了させるしかない。
いろいろ検索しまくってみたら、Interface Builder上で「Release When Closed」のチェックを「外す」とうまく動くことが分った。これは、一体どういうことなんだろう？

■eppcでLAN上のマシンをコントロールしようとしたらエラー

LAN上の他のMacをeppc://で指定してメッセージを送ってコントロールしようとしたら、アドレスが分らないと言われた。
AppleScriptエディタ上で実行する分には問題ない。

エラー回避のため、リモートマシンに命令する部分のAppleScriptだけテキストファイルに書き出して、osascriptコマンドでシェル経由で間接実行するようにしてみた。

この回避策はうまく行ったが、これがAppleScriptObjCの処理系のバグなのか、それともプロジェクト中のInfo.plistでeppcのURLプロトコルを宣言してあげないと通信がブロックされるのか、実際に試してみないとなんともいえない。ためしに、Info.plistにeppcのURLプロトコルを書いてみたが、状況に変化はなかった。

■「eppc://」のURLをshared user defautsに保存しようとして拒否された

LAN上のMacをコントロールするアプリケーションを作っていて、LAN上からマシンを選択するようにしてみた。

　choose URL showing {Remote applications}

でLAN上のプログラムリンクがオンになっているマシンを検索して、それをNSTextFieldにstringに変換しつつストア。
NSTextFieldの内容をShared User Defaultsにバインドして、そのまま初期設定ファイルに保存させようとしたら……ダメ。

　　eppc://192.168.0.80:3031

のような（ただの）URLの文字列なのに、どうやっても保存できない。

さんざん試してみたところ、プロトコルを示す「eppc://」と、ポート番号を示す「:3031」を削除しないと保存できなかった。
AppleScript Studioではやりたい放題だったが、AppleScriptObjCではMac OS Xの機能の新たな一面を知ることになった。
っていうか、なんか微妙にめんどくさい。

ただ、出来上がったアプリケーションは「これ、本当にAppleScriptで作ってあるの？」という凝った動きができるし、GUIを操作する部分がやけに高速。そのうち、Mac OS X上でAppleScript Studioのアプリケーションが動かなくなるであろうことを考えると（Snow Leopard上では動く）、AppleScriptObjCへの乗り換えを次期OS「Lion」までに行っておくのがよいのではないでしょうか。

GUI Scriptingでできることは、Mac OS Xのバージョンアップとともに、徐々に広がりを見せつつありますが……実際に試してみて「ついにここまで来たか」と驚かされました。

思えば、Safari自体もバージョンアップにともなって、アクセシビリティ系の機能が向上。このあたりは、読み上げなどの機能がアップしたぐらいにしか考えていなかったのですが……よくよく考えると、アクセシビリティ系の機能がSafariを通じてWebコンテンツにアクセスできるのであれば、AppleScriptもGUI Scriptingを使ってWebコンテンツにアクセスできるのではないか？

やってみたら、大成功。「HTMLコンテンツ」の中にあるフォーム部品（radio button）や画像をクリックしたり、テキストで書かれていることを取得したり……自分には、DOM経由でアクセスするよりも簡単に操作できました（このへんは個人差が……）。

▲UI BrowserでSafariのUIを調査……

▲Safariの「HTMLコンテンツ」から、さらに下位階層を掘り下げていく……

▲リンクのテキストにアクセス……

このサンプルは、本BlogをSafariでオープンして、ページ上部にあるメニュー「ABOUT」のリンクをクリックします。

この仕組みを利用して、Webブラウザに表示されているフォームにテスト用のデータをAppleScriptから投入し、連続テストを行うことも可能です。

ちなみに、このリストは「ブックマックバー」が非表示の状態で実行したものであり、「ブックマークバー」を表示させた場合には、リンクのクリック部分が、

click static text 1 of UI element 2 of list 1 of UI element 1 of scroll area 1 of group 2 of window 1

となります。

こういうことを考えると、（外部からコントロールできないことが確実な）Flashのコンテンツは勘弁してほしいという気に……。

AppleScriptからアプリケーションの状態を調べたい、というニーズは多いようで……検索エンジンのキーワードで割と頻繁に調べられているようです。

個別のノウハウについては本Blog上で紹介していますが、体系的にノウハウを整理したことはないので、ここでまとめて紹介しておきます。

（１）アプリケーションがインストールされているかを調べる

アプリケーションの状態を調べるといっても、それがインストールされていなければ調べようがありません。最初にやるべきなのは、AppleScriptを実行するマシンにコントロール対象のアプリケーションがインストールされているかどうかを確認することです。

アプリケーションの存在確認は、Info.plistに書かれているCFBundleIdentifierを確認する必要があります。

Info.plistの内容確認は、Xcode Toolsをインストールすると一緒にインストールされる、「Property List Editor」で閲覧／編集が可能です。

Property List Editor上でキー値がそのまま表示されていない場合には、メニューの「View」から「Show Raw Keys/Values」を実行するとCFBundleIdentifierを確認できます。

このid値をもとに、Finderに対してapplicaion fileを求めると、インストールされている場合にはそのうち一番新しいバージョンのアプリケーションファイルへのaliasが得られます。

（２）起動中のアプリケーションから情報を取得する

インストールされていることが確認できたら、launchなりactivateのコマンドを送って起動。そののち、起動中のアプリケーションから各種情報を取得する、というのが定石です。

たいていは、アプリケーションのプロパティを取得すれば、アプリケーションが持っている情報が得られます。ただし、ここで得られる情報はアプリケーション側のAppleScript対応度によってまちまちで、バージョン情報やアプリケーション名が分るだけ、というケースもあれば……現在選択中のオブジェクトの情報が分ったり、各種環境設定情報が分る場合もあります。

さらに、アプリケーションのプロパティを複数まとめて「properties」で取得できないアプリケーション（iTunesなど）もあるため、そういう場合にはAppleScript用語辞書をしらべて、ひとつひとつプロパティ値を取得する必要があります。

（３）System Events経由でプロセス情報を調べる

アプリケーションに対して直接問い合わせを行った場合に、環境設定情報やドキュメントの情報は取得できますが、アプリケーションプロセス自体の情報はあまり調べられません。

そこで、アプリケーション本体ではなく、System Eventsにプロセス情報を確認することになります。

ここでは、CFBundleIdentifierによってプロセスの特定を行っていますが、Mac OS X上で気をつけるべき点があります。たとえば、Adobe Illustratorであれば……複数の異なるバージョンをインストールして、同時に複数バージョンを起動しているケースがあるということです。

そのため、厳密にアプリケーションプロセスを指定する場合には、バージョン情報なども指定する必要も出てくることでしょう。

ただし、System Eventsから取得する意義があるのは、アプリケーションが最前面にあるかどうかを示す「frontmost」、可視状態になっているかどうかを示す「visible」、そしてUNIXから見た場合のプロセスIDである「unix id」ぐらいです。

unix idを取得できれば、あとはshellのpsコマンドをdo shell scriptコマンド経由で実行し（ps -lp [process id]）アプリケーションプロセスの状態を調べられます。

ここまでくれば、PhotoshopだろうがiPhotoだろうがPreviewだろうが、単なるUNIXのプロセスとして扱えます。killするなりゾンビプロセスになっていないか調べるなり、CPUへの負荷状態を調べたりできることになります。

だいたい、AppleScriptでアプリケーションプロセスの「状態」を調べるノウハウというのは、こんな感じです。

読者の方からメールでお寄せいただいたプログラムの中に入っていて、「え？　なにこれ？！」と驚いてしまったのが、このopenハンドラでファイルパス以外のものを渡すというやり方。

AppleScript Studioのアプリケーションに外部のAppleScriptから命令を渡すような場合に、コマンド入りのファイルを作成して、openハンドラ経由でそのファイルをAppleScript Studioアプリ側にオープンさせ、ファイルを経由してコントロール。

AppleScript Studioアプリケーションの内部ハンドラを外部からコントロールすることは事実上無理で、さまざまな迂回のための手段が考え出されてきましたが、ファイル経由でコマンド送信するのはなかなかいいやり方でした。……そう、処理スピードを考えなければ。

ファイルI/Oが毎回発生するので、スピードはいまひとつです。ただ、信頼性という意味では並列処理で連続して発生させても問題がなかったので、大丈夫だと考えています。

そのうえ、openハンドラをファイルI/Oを経由せずに呼び出せるのであれば、それに越したことはありません。

そんなところに飛び込んできた、openハンドラに渡せるのがファイルパスだけではないという情報。

さっそく、ためしてみました。

たしかに、openハンドラにファイルパス以外のものを渡しても大丈夫でした。ただ、openハンドラの受信パラメータに複数指定してしまうと、肝腎のファイルを（ドラッグ＆ドロップで）渡したときにパラメータエラーになってしまいます。

そんなわけで、受信パラメータは１つに変更。その内容を判断して、処理するようにいろいろ試してみました。

AppleScriptで並列処理を行うサンプルです。メイン（GUI）側はAppleScript Studio（Xcode 3.1.4 on Mac OS X 10.5）、サブ側は通常のAppleScriptで記述しています。

子プログラムからメインプログラム（画面つきのプログラム）に向けて、ファイルシステム経由でイベントを６プロセス並列で送信。子プログラム側では1〜1000まで順次カウントアップし、すべての子プログラムがカウントアップを終了したら、その時間を表示するようになっています。

→　テストプログラムをダウンロードする

使用方法は……アーカイブを展開したら、「docOpen1」アプリケーションを起動して、「START」ボタンを押すだけです。

結果は、手元のマシンでは……

　　CoreDuo 2.0GHzのMacBook Pro：95〜100秒
　　Core2Duo 2.4GHzのMacBook Pro：90〜95秒
　　Core i7 2.66GHzのMacBook Pro：55〜60秒

といったところです（Mac OS X 10.6.3上で計測）。Core i7のMacBook Proでは６プロセス並行して走らせてもまだCPUに余力があり、HyperThreadingで仮想的に4コアのCPUとして振る舞えることが、こうしたタイプのプログラムの実行に有利に働いているようです。Core 2 Duo 2.4GHzの環境ではCPUの全能力を必要としていたAppleScriptのプログラムが、余裕で動いてしまう様にはほれぼれします＞Core i7

▲MacBook Pro Core i7 2.66GHzで本サンプルが稼働中の負荷

本サンプルの本当の目的は、並列処理時の子プログラムからメインプログラムへの状況・結果通知のテストでした。それぞれの子プログラムが並列でてんでバラバラにメッセージを投げた場合でも、イベントを取りこぼさずに正しく処理できることを確認できました。

パラメータをファイルに書き出して、そのファイルをメインプログラムでオープンさせるようにイベントを投げるというシンプルな処理ですが、並列処理時や長期間に渡る処理を行わせた場合の時間計測など、さまざまな用途が考えられます。実際に、ぜんぜん速度を要求されない「アドレスブック.app（のプラグインAppleScript）からAppleScript Studioアプリへのデータ転送」に、このファイルシステム経由のイベント送信を使って実装したことがあります。

本当は、こんなに短い間隔で連続的に子プログラム→メインプログラムの方向でイベントを送るようなシーンは考えていませんでした。かなりまとまった処理を子プログラムに行わせて、子プログラム側の処理終了後にその実行結果なりエラー内容なりを親プログラム側に伝えられればよい、というスタンスです。

さらに……本来であれば子プログラムの生成については、ダイナミックにその数を増減させられるのですが、GUIのプログラムに経過を表示する関係で、本サンプルでは６プロセス固定で行っています。

とても高価なため自分の手元にはないのですが、もっとCPUコア数の多いMacProなどで処理を行った場合の速度などが分かると有意義でしょう。速いマシンでの実行結果（秒数）については、コメント欄にて教えていただけると助かります。

もしも、現在お使いの環境がMac OS X 10.4.11などの古い環境（Mac OS X 10.5より前）の場合には、Mac OS Xのバグについても考慮しておく必要があります。

Mac OS X 10.5以前は、フォルダ名に濁点や半濁点を含む文字列があった場合……

　　例：ぴよぴよ（半濁点を含む）
　　例：びっくり（濁点を含む）

ファイル名/フォルダ名をFinderから取得して文字ごとに取り出すような処理をすると、「濁点と文字が分離されてしまう」というバグがありました。

▲「Webログ」フォルダを選択した場合の実行結果（Mac OS X 10.4.11）

長い間、US Appleの担当者に散々文句を言って、ようやく10.5で直った次第です（ただ、その一方で10.5以降ではカタカナと平仮名の区別ができなくなるというおそるべきバグが……）。

回避方法は、一度stringにcastしてからunicode textにcastする、というものです。ものすごく、意味不明な処理を書かなくてはならず、本当にイライラするところですが……動かないよりはマシということで、長年この記述を行ってきました。いまでも、Mac OS X 10.4.11上で動作させる必要のあるAppleScriptは、そのような処理を書いています。

Mac OS X上でパスを記述する際に、気をつけるべき点があります。それが、ローカライズド・フォルダ。基本的かつ重要なフォルダについては、それぞれの言語環境に合わせてローカライズした名前をユーザーに見せる仕組みがローカライズド・フォルダですが……裏を返せば、Finder上で見えてる名前と本当の名前が違う場合がある、というわけです。

ふだん見ている「書類」や「デスクトップ」といったフォルダ名は、本当のフォルダ名ではありません。Finder上でカスタムアイコンが付いているようなフォルダは軒並みローカライズド・フォルダで表示されており、実際には「Documents」とか「Desktop」という名前がついています。

このあたり、AppleScript上でパスを記述する際に問題になるかもしれません（普段から英語で表記していたので、その存在を忘れていました）。

「フォルダの本当の名前」を確認するのに一番よいのは、Terminal.appを起動して確認するとか……あるいは、ちょっとしたAppleScriptを記述して

　　set a to choose folder

実際にAppleScriptから「本当の名前」を確認してみることです。

昨今のOSはほとんどそうですが、Mac OS XはマルチユーザーのOS（複数ユーザーの使用を前提としたOS）であるため、ユーザーごとにホームディレクトリが異なります。また、Finder上でハードディスクの名前もユーザーが自由に変えられるようになっています。

このため、ホームディレクトリへのパスや、その他の重要なフォルダへのパスについても、プログラム上に直接文字列で書いておくと、他のマシンや他のユーザー環境で実行できなくなってしまいます。

そこで、途中までのパスについてはコンピュータからpath to命令で取得し、その後のパスのみ文字列で書いておき、それらを結合するというのが一般的なパスの記述方法です。

set picFol to path to pictures folder from user domain
–> alias “Cherry:Users:maro:Pictures:”

さらに、上記サンプルで出てきていますが、「ドメイン」の概念が必要になります。
たとえば、「ライブラリ」フォルダというものは、

　　Macintosh HD:システム:ライブラリ:
　　Macintosh HD:ライブラリ:
　　Macintosh HD:Users:hiyoko:ライブラリ:

の３種類があって、それぞれ「system domain」、「local domain」、「user domain」のドメイン指定によって指定できます。

たいていは、自分のユーザーディレクトリの下にあるフォルダを扱う場合がほとんどなので、user domainを指定することになるでしょう。

AppleScriptにおけるパス記述方式は、Mac OS形式、POSIX path形式、URL形式の３つがあります。出現頻度および重要性もこの並びのとおりです。

■Mac OS形式

フォルダ名を「:」で区切って記述する、Classic Mac OSから引き継がれたパス記述形式。AppleScriptの世界でもっともよく使われます。「東京都練馬区中村橋」という住所をMac OS形式で記述すれば、

　　東京都:練馬区:中村橋:

になります（中村橋がファイルではなくフォルダの場合）。「中村橋」がファイルである場合には、

　　東京都:練馬区:中村橋

になります。

ハードディスクの名称が「Macintosh HD」で、ユーザーが「maro」の場合のホームディレクトリは、

　　Macintosh HD:Users:maro:

と表現されます。aliasはこの形式で表現されます。

■POSIX path形式

UNIXの世界で用いられるパス記述形式です。ディレクトリ（フォルダ）階層を「/」で区切ります。また、パスの途中にスペースなどが入る場合には、パス全体をクォートでくくる必要があります。

さきほどの東京都練馬区中村橋は、

　　/東京都/練馬区/中村橋/

のように表現されます。特筆すべき点は、このPOSIX pathはルート「/」を頂点とするツリー構造であり、HDDの名前が変わろうがその構造は変わりません。

ハードディスクの名称が「Macintosh HD」で、ユーザーが「maro」の場合のホームディレクトリは、

　　/Users/maro/

ハードディスクの名称が「Hiyoko」で、ユーザーが「maro」の場合のホームディレクトリも、

　　/Users/maro/

という形式で表現されます。AppleScriptの世界におけるパスはMac OS形式で統一されることが望ましいところですが、shellコマンドを呼び出すような場合には必要になりますし、一部の出来の悪いアプリケーションがこのpathを必要とします（CocoaではPOSIX pathが使われるため）。パス処理関連で代表的な出来の悪いアプリケーションとして、Adobe Acrobat DistillerとKeynoteがあります。

とくに、Adobe Acrobat Distillerでは、POSIX形式のパスにクォート処理を行って渡すとエラーになるなど、本当にチェックしてから発売しているのか疑問に思えるほどです。

Keynoteでは、ファイルのオープンにaliasを要求するのに、画像を連続配置するmake image slidesコマンドではPOSIX pathを要求します。

こうした、出来の悪いアプリケーションが存在することを意識したうえで、Mac OS形式とPOSIX path形式を使い分ける必要があります。また、これらの形式は相互変換できるように命令が用意されています。

■URL形式

ほとんど登場する機会はないのですが、Webブラウザなどにファイルを指定するような場合に使います。基本的にはPOSIX pathと同じですが、先頭にプロトコルを示す「file://」が付くことと、マシンのローカルに存在していることを示すために、localhostからパスが始まります。

ハードディスクの名称が「Macintosh HD」で、ユーザーが「maro」の場合のホームディレクトリは、

　　file://localhost/Users/maro/

という形式で表現されます。URL形式では空白文字や一部の特殊記号、日本語の文字列などはURLエンコードされるため、パスの途中に空白文字を含むフォルダが存在する場合でも、クォート処理を行う必要はありません。

set a to choose folder

tell application “Finder”
　　set aInfo to URL of a
end tell

–> “file://localhost/Users/maro/“

なお、AppleScriptの標準命令ではURL形式からMac OS形式に戻すことができません。本Blog上に掲載している「URLエンコードされたファイルパスを元のテキスト（POSIX Path）に戻す」サブルーチンを用いてPOSIX pathに変換し、そこからaliasに変換することはできます。

AppleScriptにかぎらず、HDD内のどこかに入っているファイルとか、自分のホームフォルダの「書類」フォルダとか、意図したものを指し示して処理を行いたいという場合がものすごく多くあります。

一般的に、そういうファイルシステム中における階層的な位置情報を「パス」と呼びます。英語でいうとpathです。

パスは住所の表記によく似ています。ただ、人に伝える住所はちょっと間違いがあってもなんとかなりますが、プログラム中に記述するパスには一切間違いが許されません。

「東京都練馬区中村橋」という住所があったとして、人に伝える場合には「とうきょうと 練馬く中村橋」でも伝わりますが、プログラム中ではこれが１文字間違っただけでも別の住所と見なされることになります。たとえ、空白文字（スペース）が抜けたとか、そうしたささいな間違いも許容されません（1バイトのアルファベットの大文字小文字の違いは同一視されます。これは、Mac OS Xが標準採用しているHFS plusの仕様です）。

そんなわけで、プログラム中にパスを書いておくのは、けっこう骨が折れる作業です。

さらに、プログラムを他人のマシン上でも動作させることを考えると、HDDの名称やユーザー名も違う可能性が高いので、ユーザーの環境情報を取得しつつ、パスを組み立てるという作業が必要になります。このあたり、昔のClassic Mac OSでは必要のなかった話ですが、Mac OS Xになって少々複雑に（ちょっとだけですが）なった話です。

「ちょっと気の利いた複数folder選択」を発展させ、選択したフォルダの一覧を確認表示するようにしたAppleScriptです。

最大の見どころは、フォルダパスを一覧表示するさいに、どのパスかを示す文字の長さをそろえて、フォルダパスの内容確認を行いやすくした「umekusaKit」です。

これで、選択した複数パスの一覧を表示し、処理前に確認するように書いておけば、ささいなミスもなくなるに違いありません。

ちなみに、この一覧表示で「Cancel」ボタンをクリックすると……

のように、処理を中断します。

どうも、プログラムを見直してみると……もっと汎用的なサブルーチンに仕立てて、もっと簡単に利用できるようにできそうな気がします。まだ、手直しできる余地が大きそうですが、使用頻度はあまり高くなさそうなので……このままかもしれません。