各所で話題になってるSnow Leopardですが、その中でちょっと嬉しいけど地味な新機能としてテキストの自動置換機能があります。正式名称はなんていうのか知りませんが、システム環境設定→言語とテキスト→テキストで設定できるアレです。テキストエディットとかでは使えるんですが、サードパーティのアプリはそれぞれが対応する必要があります。
対応と言っても大掛かりな実装は必要なく、テキストの自動置換機能を有効にしたいNSTextViewに対して- setAutomaticTextReplacementEnabled:YESを送ってやるだけです。これはSnow Leopardで新たに登場したもので、その名の通り自動置換を行うかどうかをセットするためのものです。ちなみにInterface Builderから"Text Replacement"にチェックをいれても変更できます。おお、簡単。
Snow Leopardでは他にもテキスト周りの新機能（スペルの自動修正とか）があり、それに関するメソッドがNSTextViewに追加されています。追加されたメソッドの一覧がADCで見られます。
いつの間にか正式版が出てた我らがQSB (Google Quick Search Box) ですが、TechCrunchでQSBはTwitter検索ができないなんて言われちゃったから、できるようにしてみようじゃありませんか。幸いQSBはプラグイン機構を備えてるので結構簡単に実現できた。いつのまにかSDKも出てるし。
というわけでできたのがこのTwitter検索プラグイン。twitter検索のAPIを使ってるからちょっと重いけど、公式の検索APIは精度がお話しにならないのでこっちにしました。
インストール方法は、ダウンロードしたzipの中身のTwitterSearch.hgsを~/Library/Application Support/Google/Quick Search Box/PlugInsに置いてQSBを再起動して環境設定からオンにするだけ。QSBのバージョンによっては起動時にプラグインを有効にするかどうかを問うダイアログが出てくるけど、そのまま有効にしちゃってください。
つい最近までマイコミジャーナルで連載されていたダイナミックObjective-Cの書籍版、Dynamic Objective-C
Webでの連載はCocoa初心者向けの入門記事みたいなのではなくて、Objective-Cを使ってる人がそのディープな領域にのめり込んでしまうような、そんな魅力を伝えてくれるもの。Objective-Cのランタイムの話だとか、実装はどうなってるかみたいな深い（そしてマニアックな）話題を提供してくれて、かなり読み応えがありました。中盤以降はGoFのデザインパターンをObjective-Cではどのようにして実装できるかかも解説されてます。
書籍版はWeb版と内容はほとんど同じらしいけど、やっぱり読みやすさは紙媒体が一番だと思うから欲しい。というわけで当たるといいなー…
Macでホットキーを処理しようとするとたまに困るのがバッティング。基本的に、RegisterEventHotKey()を使って登録されたホットキーが複数のアプリケーション間で重複したときはその全てのアプリケーションにイベントが送られることになってる。AとBとCの3つのアプリケーションがそれぞれF2にホットキーを割り当ててたとすると、F2キーを押したときにその3つのアプリケーションでそれぞれ処理が行われるといった具合。
ところが欲張りなあなたはホットキーイベントを他のアプリに渡したくない、独り占めしたいと思うかもしれない。そんなあなたに贈るのがkEventHotKeyExclusive。Leopardで追加されたオプションで、これをRegisterEventHotKey()のの第5引数として渡せばホットキーイベントを独り占めできる。
ちなみにCarbon EventsのドキュメントはTigerの時のものだからこれに関する記述はありません。もうLeopardリリースから1年半経つのに…
最近、Automatorを使う機会が増えたのでちょこっと。
AutomatorもAppleScriptもOSXにおける定型作業を自動化するためのものですが、AppleScriptは割と使われているのにAutomatorはあまり使われていないような気がします。おそらく、理由としては昔からある技術で書籍や情報が多い、柔軟なスクリプティングが可能だからといったところでしょうか。
特に日本ではAutomatorに関する情報はあまり見かけません。かつてOS9時代にAppleScriptの書籍が多く出版されたのとは対照的です。また、アクションを組み合わせてワークフローを構築するというAutomatorの特徴が逆に「単純作業しかできない」というイメージに繋がるのかもしれません。
…と書くとAutomatorの良い所がないように見えますが、そうでもありません。AppleScriptより良い部分もたくさんあります。
Automatorは基本的にアクションをドラッグ＆ドロップしてワークフローを構築します。これの利点はなんと言っても作業効率。スクリプトをキーボードから入力する必要のあるAppleScriptより断然早く目的のものが出来上がります。文法がやや特殊でそれぞれの文が長くなりがちなAppleScriptは慣れるまでが大変でしょう。
Automatorのワークフローは、ほとんど何も考えなくても直感的に組むことができます。ある程度意識しなければいけないことといえば、入力と出力の型でしょうか。アクションの出力が「ファイル／フォルダ」だったら、次のアクションの入力もそれに合わせるといった具合です。それでも、file、alias、POSIX file、Finderのitem…とファイルの表現だけでもたくさん存在するAppleScriptよりずっと簡単です。
Automatorでは、ユーザが実際に行った操作を記録してワークフローにすることができます。AppleScriptでも同じようなことができますが、Recordableなアプリケーションに限られていて、最近では忘れられている感があります。AutomatorではアプリケーションがRecordableであるかどうかに関係なく記録できます。
例えばAppleScriptで画像ファイルの形式を変換しようとすると、まずスクリプトから画像アプリケーションを起動してそこにメッセージを送るのが一般的です。この時の起動時間は意外とイライラの素になります。しかしAutomatorではアクションそれ自体がそのような作業を行ってくれるので外部アプリケーションの起動は必要ありません（もちろん例外はあるでしょうし、OSAXを使えばまた話は変わりますが）。
AppleScriptによるスクリプトもAutomatorワークフローもともにスクリプトメニューに登録していつでも好きなときに実行することができますが、Automatorワークフローはそれに加えてFinderのコンテクストメニューから呼び出せる「プラグイン」として使用することもできます。
まあ、ループはできるけど条件分岐はできなかったりとかでまだまだ未熟な部分はありますけど、Automatorの中からAppleScriptを呼び出したりもできますし、それぞれの長所を活かした使い方をするのが1番でしょう。
