Archive for 11月, 2013

2013/11/28 Dockの表示/非表示制御

Dockを表示させたり、隠したりするAppleScriptです。

たまたま、全画面を半透明ウィンドウで覆って処理を行うプログラムをAppleScriptObjCで組んでいて、Dockが表示されていて邪魔でした。ここで可能な選択肢は、

(1)Dockよりも上にウィンドウを表示する
(2)ウィンドウ表示する前にDockを隠す

のうちのどちらか。

(1)は別に難しくはないものの、この間「自分のウィンドウをOSの最前面に配置してdisplay dialogを実行」して、自分のウィンドウよりも「下」にダイアログが表示されてクリックできずに再起動 という悲しい目にあったので、却下

(2)は割といい方法ですが、Dockの制御はあまりやらない処理なので、Scriptのストックがありませんでした。

というわけで、Dockの表示/非表示(隠す)のやりかたをまとめておきました。OS X 10.5以降であれば動くはずです。動作確認をOS X 10.6〜10.9で行いました。

なお、OS X 10.6上でログイン直後にSystem Eventsを呼ぶ(起動項目にAppleScriptアプレットを登録するなど)と、System Eventsの起動が終わり切っておらずエラーになる可能性があるので注意が必要です。

スクリプト名:Dockを隠す
tell application “System Events”
  set autohide of dock preferences to true
end tell

▼新規書類に ▼カーソル位置に ▼ドキュメント末尾に

スクリプト名:Dockを表示する
tell application “System Events”
  set autohide of dock preferences to false
end tell

▼新規書類に ▼カーソル位置に ▼ドキュメント末尾に

2013/11/25 本来あるべきiWork 13のAppleScript対応機能

さる2013/11/22のiWork 13のアップデートによって、iWork 13のPages v5.0.1に、ごく一部のAppleScript対応機能が実装されました(初版のv5.0リリース時にはAppleScript用語辞書は付いていませんでした)。

他のiWork 13アプリといえば……Keynote v6.0.1は相変わらず、操作系の(リモコン操作系の)命令のみ。Numbers v3.0.1はAppleScript用語辞書自体がついていない状況が続いています。


Pages Suite	Classes and commands for Pages.

export options n
	properties
		title (text) : Epub title
		author (text) : Epub author
		cover (boolean) : Epub first page is cover

document n [see also Standard Suite] : A Pages document.  syn document
		responds to export.

export v : Export a document to another file
	export document : The document to export
	to file : the destination file
		[as epub/‌text/‌PDF/‌Word/‌Classic] : The format to use.
		[with properties export options] : Optional export settings.

実際に、使えるか試してみたところ……これらの命令はApple純正アプリにありがちな「ダミー命令」ではなく、実際に使えました。

pages_pdf.jpg
▲PDF形式でAppleScriptからExportして、プレビュー.appでオープンしたところ

pages_epub.jpg
▲ePub形式でAppleScriptからExportして、iBooks.appでオープンしたところ

pages_word.jpg
▲Word形式でAppleScriptからExportして、Word v14.3.7でオープンしたところ

pages_pages09.jpg
▲Classic(Pages 09)形式でAppleScriptからExportして、Pages v4.3でオープンしたところ

Apple純正アプリケーションのうち、近年一番有害な「ダミー命令」は、iBooks AuthorのAppleScript用語辞書(すべて)です。まともに動作しないのに、ダミーのAppleScript用語辞書が付いている状態です。初心者があれを見て「AppleScriptで命令を出しても使えない」と勘違いしてしまうので、おもいっきり有害です。

スクリプト名:Pages 5でファイル書き出し
set aFile to choose file name
set aFile to aFile as string

tell application “Pages”
  
  
export document 1 to file aFile as PDF with properties {title:“test”, author:“Piyomaru”, cover:false} –PDF。拡張子「.pdf」
  
  
–export document 1 to file aFile as epub with properties {title:”test”, author:”Piyomaru”, cover:false}–epubファイル。拡張子「.epub」
  
  
–export document 1 to file aFile as Word with properties {title:”test”, author:”Piyomaru”, cover:false}–Wordファイル。拡張子「.doc」
  
  
–export document 1 to file aFile as Classic with properties {title:”test”, author:”Piyomaru”, cover:false} –昔のPages ‘09のフォーマット。拡張子「.pages」
  
end tell

▼新規書類に ▼カーソル位置に ▼ドキュメント末尾に

しかし、元のiWork 09のAppleScript用語辞書とて「本来あるべきレベル」には遠く達してはいません。

では、iWork 13のAppleScript機能はどこに向かっているのでしょう? いえ、どこに向かうべきなんでしょう?

「元の状態に戻る」ことがベストかと言われれば……現在よりはベターではあるものの、ベストではないと思います。

ちょうどよい機会なので、AppleScriptを書く側から見た、本来あるべきAppleScript対応機能をリストアップしてみることとしましょう。

状態の取得/設定

まず、どういう書類(document)をオープンしているのか、どういうウィンドウ(window)をオープンしているのか、AppleScript側から検知できる必要があります。

また、documentのオープン/クローズもできる必要があります。選択中の部品(selection-object)、選択中のテキスト(selection)を取得できる必要があります。テキストについては、選択中の範囲に別の内容を設定できると有用性が増すでしょう。

ここで、「見えないWindow」の情報を取得できてしまうケースが見られます(CotEditor、Pages 5.0.1)。実に無意味で有害なので、やめてほしいです。見えないWindowをカウントできてしまうと、「ああ、AppleScriptの機能を全然チェックしてないんだなぁ」とガッカリしてしまうところです。

書類上の情報取得

次の項目と対になる内容ではあるのですが、書類(document)をオープンして、その内容をAppleScript側から取得できる必要があります。

書類上に配置されるオブジェクトをそれぞれ識別できる必要がありますし、そのオブジェクトが保持している情報(表オブジェクトだったら、表のセルに入っているデータとか、表の経線種類とか)を取得できると便利です。

このあたりの機能については、アプリケーション側がAppleScriptによる自動処理をどの程度重視しているかによって、どの程度の分量になるかが変わってきます。

書類のAppleScript側からの生成

GUI側からだけではなく、AppleScript側から書類を作成して、書類上に各種オブジェクトを配置してデータを作成する機能です。

このあたりの機能が、Keynoteではめちゃくちゃ弱くて、「書類の生成もできる。ページも作れる。だが、ページ上にオブジェクトを置いて設定することができない」という状態でした。

あ、Numbersは新規書類作成「自体が」まっとうな手段ではできないので、そこはまともにしてほしいですね。

書類上のオブジェクトに名前をつけて識別する機能

InDesignでいえばScript Labelに相当するもの、他のアプリケーションでもname属性を各オブジェクトに設定できる場合があります。AppleScriptからの処理のために、オブジェクト識別のためのラベルなり名前なりを使えると便利です。

OmniGraffleのように、name属性がなくてもURL属性を識別用に用いたりすることもできます。

とにかくGUI側からは見えないがAppleScriptからは見える属性値が用意されていると、AppleScriptからの処理がやりやすくなることでしょう。

Microsoft並みの誠実さが求められるApple純正アプリのAS用語

OSはともかく、言語や開発環境に対するマイクロソフトの真摯な姿勢は評価されるべきです。

Appleも、Apple純正アプリのAppleScript用語辞書については、サードパーティのお手本となるような内容にしていただきたいものです。

2013/11/20 AppleScript Librariesの目指すもの

OS X 10.9, Mavericksには「AppleScript Libraries」というライブラリ管理機能が、AppleScript登場20年目にしてようやく装備されました。

一般的には、これは「ライブラリ管理機能」として知らされていますが、「本当にそうなの?」というのがこの話の内容です。

ライブラリアンとしては機能が貧弱

一般的なライブラリアンの機能を表にまとめてみました。AppleScript Librariesがこれらのどの機能もサポートしていないことが分ります。

lib1.png

数年前からAppleScript向けのライブラリ管理の議論をはじめていたのですが、途中ですべてのルールを変えた出来事が起こりました。Mac OS Xのセキュリティ機能の強化の流れです。

動的な書き換えやダウンロードが行いにくい世界へ

これから先、AppleScriptでも、コードサイン、サンドボックス化、そしてMac App Storeへの登録前のバリデーション(妥当性)チェックが当たり前になっていくことでしょう。

AppleScriptで作ったソフトウェアを「外販」する場合には、少なくともMac App Storeで売る場合には当然これらの条件を満たす必要が出てきますし、他のコンピュータ上で動かす場合にこれらの条件を満たす必要が、遠くない将来に発生することでしょう。おだやかな移行かもしれないですが、いきなり昔のように「なんでもアリ」な世界には決して戻らないことでしょう。

ということは、これらのルールが強化された状態でも使えるライブラリアンでなければならない、と考えました。プログラムを作るのに便利な機能が提供されているけれども、それを利用して作ったものはよそに配れないし、オンラインで販売することもできない……という状態は避けたいと考えました。

そうなると、必然的に「自動アップデート」とか「自動ダウンロード」の機能は組み込みにくくなります。アプリケーションまるごとアップデートする、というような仕組みにする必要があるでしょう。

当時は、「ライブラリ作成環境でScriptのかたまりを静的に作り、それを配布する」ような運用を検討していました。ただ、無償でそれをやり続ける人はいないでしょう。

言語拡張をユーザー自身で行えるようにする仕組み、OSAXの代替

AppleScript Librariesは、2つの機能を目指したものだと思います。ライブラリアン的なものと、ユーザー自身による言語拡張の手段です。

前者については、ライブラリアンとはなかなか言いにくいレベルなので……Scriptの分割記述/再利用を助けるための仕組み、であると思います。ライブラリアンだと思うから腹が立つ(場合がある)のであって、決してこれは「ライブラリアン」ではありません。

主に、後者の「OSAXの代替」の話を書きます。

以下に、現在の多層的なAppleScriptの世界を図にしてみました。細かいことをいえば、Spotlightによるファイル検索機能などもパッチワーク的なAppleScriptの世界を構成する要素ではあるのですが、とりあえず置いておきましょう。おおまかに見るとこんな感じです。

非常に雑多な要素が、時代の変遷とともに積み重ねられ、統一されないまま混在している状態です。現在のAppleScriptの世界では、(最低でも)これらの要素技術をマスターしている必要があります。

lib2.png

この中で、OSの進化とともに足かせになってきた部分があります。数値で10E10以上が指数表示になるとかいう、基礎的な仕様の部分もそうではあるのですが、OSAXと呼ばれるプラグイン機構であるとか、Classic Mac OS 8.5の時代から引き継いでいる「なんちゃらScripting」「なんとかEvent」というAppleScript専用の支援ツール類です。

これらは、Carbonベースで作られており、段階的に廃止へと向かっています。

lob4.png

DataBase Events(whoseなどのAppleScriptのフィルタ参照機能でレコードにアクセスする超ド変態データベース)などは、利用者もそれほどいなさそうなので、いつ廃止されてもおかしくなさそうですが……全体的に、徐々に廃止されてきた流れは見てとれると思います。

例外はSystem Eventsで……ここには、他のアプリケーションから機能がどんどん移管されています。

ilb5.png

AppleScriptの命令を拡張するOSAXなどの機能を提供する(誰が?)仕組みとしても、このAppleScript Librariesは利用されていくのだと考えます。

lib3.png

このレベルで考えれば、AppleScript Librariesに腹は立たないでしょう。むしろ、将来的に「●●がなくなったけど、どうしよう?」という問題を(ユーザー/開発者側で自主的に)解決するための手段になるかもしれません。

2013/11/19 MavericksのGUI Scriptingのclick命令にバグ

OS X 10.9, MavericksのGUI Scriptingの一部の命令にバグが確認されました。

System EventsのProcess Suiteの「click」命令にバグがあるようです。

gui_script_bug2.png

click命令で「click at {X座標, Y座標}」と指定すると、エラーになります。10.9.1では……直らないでしょうね、、、

gui_script_bug1.png

2013/11/18 印刷可能なプリンタ一覧から選択してプリント実行 10.9

印刷可能なプリンター一覧から選択してプリントを実行するAppleScriptの改修版です。

昨日掲載したAppleScriptでは、PDF出力用のバーチャルプリンター(CUPS-PDF)にダイアログなしで印刷出力してPDFを作成するというワークフローがOS X 10.9上で確認できませんでした(ダイアログを表示させると出力できていました)。

また、接続されていても「一時停止中(省エネモード)」のレーザープリンターを指定できなかったため、若干処理内容を見直してみました。身の回りに動作確認が可能なOS X 10.9以外の環境が少なくなっているため、OS X 10.9上でのみ動作確認してあります。

まず、バーチャルプリンターとしてCUPS-PDFではいまひとつの様子なので、同様にオープンソース&フリーで配布されている「PDFwriter for Mac v1.2.1」をOS X 10.9にインストール。

print1.png

プリントキューの一覧を求めるのに「lpstat -p」ではなく「lpstat -v」を実行するようにしました。これでスリープ中(一時停止中)のレーザープリンターも指定できます。

テストで、印刷を実行するアプリケーションにSafariを指定していましたが、いまひとつ「そんな処理はなかなかしないだろー」感が強いので、Pages(v4.3)をコントロールして書類をPDFに出力させるようにしてみました。

print3.png
▲Pages v4.3上でPagesの書類をオープンした状態

print2.png
▲PDF出力したものをPDF Viewer(Skim)でオープンしたところ

print4.png
▲プリント(PDF)出力されたファイル

なお、PDFWriterを指定してPDF出力させると、/private/var/spool/pdfwriter/(ユーザー名) のフォルダ内にファイルが生成されることを確認しました。

スクリプト名:印刷可能なプリンタ一覧から選択してプリント実行 10.9
set pList to getPrintCues()
set aPrinter to first item of (choose from list pList with prompt “出力先のプリンタを選択してください”)

set aPrintSetting to {copies:1, starting page:1, ending page:9999, target printer:aPrinter}

tell application “Pages”
  activate
  
tell document 1
    try
      print with properties aPrintSetting without print dialog –ダイアログなしで印刷
    on error
      display dialog “プリント中になんかのエラーが発生しました。たぶん、キャンセルされたんでしょう” buttons {“OK”} default button 1
    end try
  end tell
end tell

(*
–とりあえずSafariで印刷してみた。Safariである必要はない
tell application “Safari”
  activate
  tell document 1
    try
      print with properties aPrintSetting without print dialog –ダイアログなしで印刷
    on error
      display dialog “プリント中になんかのエラーが発生しました。たぶん、キャンセルされたんでしょう” buttons {”OK”} default button 1
    end try
  end tell
end tell
*)

–プリントキューの名称一覧を取得(10.9用)
on getPrintCues()
  set aRes to do shell script “lpstat -v”
  
set aList to paragraphs of aRes
  
  
set bList to {}
  
  
repeat with i in aList
    set j to contents of i
    
set jj to trimStrings(j, “device for “, “:”) of me
    
set the end of bList to jj
  end repeat
  
  
return bList
  
end getPrintCues

–任意の文字列から指定開始子、指定終了子でトリミングした文字列を取り出す
on trimStrings(aString, fromStr, endStr)
  set fromLen to length of fromStr
  
set eLen to length of endStr
  
  
set sPos to offset of fromStr in aString
  
if sPos = 0 then return “”
  
set body1 to text (sPos + fromLen) thru -1 of aString
  
set ePos to offset of endStr in body1
  
if ePos = 0 then return “”
  
set body2 to text 1 thru (ePos - 1) of body1
  
  
return body2
end trimStrings

▼新規書類に ▼カーソル位置に ▼ドキュメント末尾に

2013/11/17 印刷可能なプリンタ一覧から選択してプリント実行 10.4〜10.9

印刷可能なプリンター一覧から選択してプリント実行するAppleScriptのMac OS X 10.9対応版です。GUI Scriptingは使用していません。

printdialog.png

lpstatコマンドを呼び出して、その結果をparseしてプリンタ名を取り出す……という、あまり工夫もへったくれもない内容ではありますが、このlpstatコマンドが返す文字列が、OSのメジャーアップデートごとに微妙にフラフラと変わっているため、メジャーアップデートのたびに地道に調査して反映するという作業が必要になっています。

例によって、出力する紙のサイズの指定はできません。

10.5から10.8まではlpstatの実行結果が(日本語環境では)日本語文字列で返ってきて「おいおい……」と、思っておりましたが、10.9でlpstatの実行結果が英語で返るように変更になりました(このほうが常識的)。

本当は、CUPS-PDFを指定してPDF出力を(プリントダイアログを非表示で)実行したかったのですが、なーぜかプリントダイアログを非表示にするとPDF出力が(/var/spool/cups-pdf/me に)行われなかったので、いろいろ試しているところです。

スクリプト名:印刷可能なプリンタ一覧から選択してプリント実行 10.4〜10.9
–要・Mac OS X 10.4以上
set pList to getPrintCues() of me
set aPrinter to first item of (choose from list pList with prompt “出力先のプリンタを選択してください”)

set aPrintSetting to {copies:1, starting page:1, ending page:1, target printer:aPrinter}

–とりあえずSafariで印刷してみた。Safariである必要はない
tell application “Safari”
  activate
  
tell document 1
    try
      print with properties aPrintSetting with print dialog –「with」を「without」にすると、ダイアログなしで印刷
    on error
      display dialog “プリント中になんかのエラーが発生しました。たぶん、キャンセルされたんでしょう” buttons {“OK”} default button 1
    end try
  end tell
end tell

(*
プロパティ:

copies integer — プリントする書類の部数
collating boolean — プリントの丁合をとるかどうか
starting page integer — 書類からプリントする最初のページ
ending page integer — 書類からプリントする最後のページ
pages across integer — 物理的なページ上に横方向に並べる論理ページの数
pages down integer — 物理的なページ上に縦方向に並べる論理ページの数
requested print time date — デスクトッププリンタが書類をプリントするべき時間
error handling standard/summarized/detailed — エラーの処理方法
fax number text — 書類の送信先ファックス番号
target printer text — 出力先のプリントキューの名前

–用紙サイズを指定できないのはどういうことなのか?(汗) 用紙サイズ指定できなかったら意味ないやんけ!
*)

–プリントキューの名称一覧を取得
–10.8, 10.9用に書き換え
on getPrintCues()
  set P to paragraphs of (do shell script “lpstat -p”)
  
set pList to {}
  
  
set osVer to (system attribute “sys2″) as number
  
  
repeat with i in P
    set j to contents of i
    
    
if osVer = 9 then
      –10.9
      
set aPName to trimStrings(j, “printer “, ” is idle. enabled since “) of me –また、10.4の仕様に戻しましたね
    else if osVer = 8 then
      –10.8
      
set aPName to trimStrings(j, “プリンタ”, ” は待機中です。”) of me
    else if osVer = 7 then
      –10.7
      
set aPName to trimStrings(j, “プリンタ”, ” は待機中です。”) of me
    else if osVer = 6 then
      –10.6
      
set aPName to trimStrings(j, “プリンター “, ” は待機中です。”) of me
    else if osVer = 5 then
      –10.5
      
set aPName to trimStrings(j, “プリンタ “, ” は待機中です。”) of me
    else if osVer = 4 then
      –10.4
      
set aPName to trimStrings(j, “printer “, ” is idle. enabled since “) of me
    end if
    
    
if aPName is not equal to “” then
      set the end of pList to aPName
    end if
  end repeat
  
  
return pList
end getPrintCues

–任意の文字列から指定開始子、指定終了子でトリミングした文字列を取り出す
on trimStrings(aString, fromStr, endStr)
  set fromLen to length of fromStr
  
set eLen to length of endStr
  
  
set sPos to offset of fromStr in aString
  
if sPos = 0 then return “”
  
set body1 to text (sPos + fromLen) thru -1 of aString
  
set ePos to offset of endStr in body1
  
if ePos = 0 then return “”
  
set body2 to text 1 thru (ePos - 1) of body1
  
  
return body2
end trimStrings

▼新規書類に ▼カーソル位置に ▼ドキュメント末尾に

2013/11/17 AppleScriptObjCでNSDatePickerに値を設定、取得

AppleScriptObjCで、ウィンドウ上に設置したNSDatePickerに日付の値を設定したり、NSDatePickerから値を取得するサンプルです。

NSDatePicker(以下、DatePicker)は、日付情報を入力するための標準GUI部品。最近は、カレンダー.appで使われているようなカレンダー表示付きのDatePickerなどもあり、これも普通に利用できるとよいでしょう(最悪、自前でカレンダー表示インタフェースを実装してカレンダーから日付を選択してもいいですし)。

DatePickerから値を取得するサンプルは海外のBBSにもあったのですが、DatePickerに日付情報を設定する処理が見つからなかったので、そこを補ってみました。

date1.png
▲起動時にDatePickerに現在の日付を設定

date2.png
▲ボタンをクリックすると、DatePickerから各種日付情報を取り出してダイアログにテスト表示

本サンプルでは、GMT(グリニッジ標準時)との時差を+0000で指定していますが、本来の意味においては正しくないような気がします。日本標準時(JST)はGMT+9.0なので、そのあたりを正しく指定して大丈夫なようにタイムゾーンを考慮してNSDateを指定できるとよいだろうか、と(ぼんやり)考えています。

AppleScriptのdateオブジェクトにはタイムゾーンの要素はないので、AppleScript的な処理の方法とCocoa的な価値観の間で揺れている「どちらから見ても中途半端」な感じのコードになっていますが、AppleScriptObjCのサンプルコードがAppleから出ているわけでもないので、とりあえずは「こうやれば動く」的なコードを出してみて、「ここはこうすべき」的な意見が出れば変えていく、というところでしょうか。

このサンプルが「とりあえず動く」レベルであることを認識する必要があり、同時に複数のタイムゾーン上の日付を扱うと(このレベルの実装だと)混乱するよ、ということを参考までに書いておきます(滅多にないんですけれども)。

本掲載リストは、Xcodeから選択中のAppleScriptファイル(テキストファイル)を取得して、AppleScriptObjC Explorer 2をコントロールしてテキストエディットに書式つきデータでコピペして、テキストエディットからHTML書き出し(AppleScriptで自動処理)しているのですが……Xcodeの外部エディタのAppleScriptObjC Explorer 2を経由するために、ハンドラの書式が「setString_(aVar)」スタイルから、「setString:aVar」スタイルに書き換えられてしまっています。

添付のXcodeプロジェクト中では「setString_(aVar)」スタイルで記述していますので、OS X 10.8上でも編集、実行できるはずです。

→ Xcodeプロジェクトのダウンロード(50KBytes)

AppleScriptObjCファイル名:datePickAppDelegate.applescript

– datePickAppDelegate.applescript
– datePick

– Created by Takaaki Naganoya on 09/11/22.
– Copyright 2009 Takaaki Naganoya. All rights reserved.


script datePickAppDelegate
  property parent : class “NSObject”
  
property datePicker : missing value
  
  
  
  on applicationWillFinishLaunching:aNotification
    
    tell current application
      set aCurDate to current date
      
set aYear to (year of aCurDate) as string
      
set aMonth to (month of aCurDate as number) as string
      
set aDay to (day of aCurDate) as string
      
    end tell
    
    set dStr to aYear & “-” & aMonth & “-” & aDay & ” 00:00:00 +0000″
    
log dStr
    
    set aDate to current application’s NSDate’s dateWithString:dStr
    
log aDate
    
    datePicker’s setDateValue:aDate
    
  end applicationWillFinishLaunching:
  
  on applicationShouldTerminate:sender
    return true
  end applicationShouldTerminate:
  
  
  
  
on clicked:sender
    
    set theDate to my datePicker’s dateValue()
    
set theCal to current application’s class “NSCalendar”’s currentCalendar()
    
set theComponents to theCal’s components:254 fromDate:theDate
    
    –Get Date properties
    
set theYear to theComponents’s |year|()
    
set theMonth to theComponents’s |month|()
    
set theDay to theComponents’s |day|()
    
set theHour to theComponents’s hour()
    
set theMinute to theComponents’s minute()
    
set theSecond to theComponents’s |second|()
    
    display dialog ((theYear as text) & return & theMonth as text) & return & theDay as text
    
  end clicked:
  
end script

▼新規書類に ▼カーソル位置に ▼ドキュメント末尾に

2013/11/17 MavericksのAppleScriptObjCについての電子ブック「Everyday AppleScriptObjC」が発売に

Shane StanleyがMavericks上のAppleScriptObjCについての電子ブック(PDF+サンプルコード)をオンライン販売開始しました(Kagiで1,600円)。

everydaycover.jpg

全78ページのPDF、AppleScriptObjCのサンプルスクリプトを提供しています。

すべて英語で書かれていますが、それほど難解な表現はないので分りにくいことはないでしょう(英文でも、文系の人が書いた文章は本当に分らなくて……海外のお客(文系)の難解な文章に比べれば、なんと分りやすいことか(涙))。

本書でいうAppleScriptObjCは、Xcode上で記述するものではなく、AppleScriptエディタ上で書く「Cocoa-AppleScript」のことです。Xcode上のAppleScriptObjCについては何も資料がなかったので、待ち望まれていた1冊といえます。

books_table.png

ただ……本来であれば、こうした書籍はメーカーであるApple自身が作るべきもので、そうした「まっとうな」仕事がApple社内で認められないために、なかば「外注化」しているという事実は、いかがなものかと思われます。

そうはいっても、Apple社内で作るよりもShaneが書いたもののほうが良いものになることは想像に難くありません。

Xcode上でAppleScriptObjCのプログラミングを行っているユーザーにとっても、有用な1冊であることでしょう。

たしかに、役に立つ1冊ではあるのですが……10.9上でのAppleScriptObjCの機能拡張が多すぎて、OS X 10.8のサポートのためには10.9で拡張された新機能を使わないことが望ましいわけですし、なかなか悩ましいところです。

2013/11/15 プロ向けの新たなAppleScriptエディタ「tell」が登場?!

プロフェッショナル向けAppleScriptエディタ「tell」がサードパーティから登場するもようです(2014年春を予告)。誰にでも手の届く価格で……と低価格を表明しています。

tell.jpg

AppleScriptの編集プログラムとしては、OS X標準添付の「AppleScriptエディタ」の性能が割といいところまで向上してしまったために、サードパーティのエディタの付け入る隙が少なくなっているように思えます。

定番のScript Debugger(199ドル)

deb.png

AppleScriptの編集プログラムで定番といえば、カナダLate Night Softwareの「Script Debugger 5.x」を置いてほかにないでしょう。ステップ実行やトレース、変数内容のモニタリングなど、このソフトウェアなしに行うことはできません。

グラフィカルにオブジェクト階層をブラウズするとか、アプレットのデバッグなど、必要にして十分な機能を持っています。
ただ、AppleScriptエディタがScriptableになってしまったので、「必要な機能は自分で作る」とばかりに機能強化を行ってしまった結果、よほどバグの取れない複雑なScriptを書いてしまわないかぎり、Script Debuggerの必要性は(個人的には)薄れてしまいました。

むしろ、入門者にこそこうしたソフトウェアが必要とされているはずであり、需要と供給のミスマッチ(入門者には価格が高い)が起こっているように思えます。ここに、他のデベロッパーの付け入る隙はありそうです。

Smile(フリー)

smile.png

「これで日本語が使えれば完璧なのに」とため息をついてしまう、フランスSatimage SoftwareのSmile。Smileは、AppleScriptに各種OSAXを追加して数値演算関連の機能を強化し、専用のエディタを併用することでグラフなどのビジュアル出力を行えるようにした統合環境(Smile Lab)です。

ここのところ、OSのアップデートに追いついていないのか、インストールしても起動できません。本当に、何をやっているのやら、、、、

AppleScriptObjective-C Explorer 2(2,700円)

asoce.png

Shane StanleyによるAppleScriptエディタ。AppleScriptObj-C寄りの機能を売りにしています。

AppleScript用語辞書のついたAppleScript Librariesを作るのであれば、本ソフトウェアのMavericks対応版(5,400円)は必須といっても過言ではありません。

ただ、AppleScriptObjCのデバッグが劇的に楽になるとか、そこまでのご利益はありません。Script Debuggerとの連携機能を打ち出してはいるものの、AppleScriptObjCのプログラムのデバッグにはあまり足しにはなりません。

新顔のAppleScriptエディタが首を突っ込める余地は?

いま、プロ向けAppleScript編集プログラムの市場でガラ空きなのは、AppleScriptObjCのプログラムのデバッグ機能でしょうか。これを備えたプログラムは急速に支持されると思います。

あとは、Objective-Cのプログラムを読ませると、それを呼び出すAppleScriptコードを自動生成してくれるものです。

AppleScriptのサンプルコードを大量にストックしておいて、必要に応じて参照するといった機能は既存のプログラム(Script Debugger)が提供していますが、価格によっては太刀打ちできることでしょう。

何はともあれ、新たなプログラムの誕生を楽しみにしていましょう。

2013/11/07 AppleがiWork ‘13でなくなった機能(AppleScript対応を含む)の半年以内の復活を表明

US Appleが最新版のiWork ‘13で削除された機能の復活についての記事を掲載しています。

About the new iWork for Mac: Features and compatibility
Learn about the new iWork for Mac.

その中で、NumbersとKeynoteのAppleScript対応機能については、

> Improvements to AppleScript support

と明記しているのですが、Pagesだけはこの項目がありません。

「やってはいるけど、半年以内には無理」ということなのか「やっていない」なのかが不明です。

あと、Appleが純正アプリのAppleScript対応機能を実装する、といった場合に現場のエンジニアが「仕事をしたフリ」をすることが多く、初版については「ただ(実用性のない)AppleScript用語辞書が付いているだけ」の状態がほとんどです。

Appleの開発者のほとんどはAppleScriptを書けない(本当)ので、まともな実装になっていなくても検査をパスしてしまいがちです。

# SafariのチームだけはAppleScript対応を頑張っていると思います。Safariチームの仕事はいいと思います。

また、KeynoteとNumbersのAppleScript対応機能も、決してほめられたレベルではなく……AppleScriptから書類の新規作成を行って、ページを追加して、各オブジェクトをひととおり生成する……という操作はできませんでした。Numbersでは、セルをデータで埋めるのに、内部オブジェクト経由だと遅くて使い物にならず、大規模データについてはタブ区切りにしてクリップボード経由でセルにペーストするという「大技」を繰り出す必要までありました。

こうした現状を考えると、「そのままそっくり同じレベルで再現されてもねぇ」と、思ってしまうところです。

なので、「半年以内に出てくるもの」について、AppleScript対応機能の面では過大な期待はできないと思います。1〜2年は1つ前のバージョンを使い続けることになることでしょう。

2013/11/01 iWorksのAppleScript対応機能、Couldn’tなのかDidn’tなのか?

iWork ‘13のAppleScript未対応問題については、主に海外でいろいろな受け止められ方をしています。Twitter界隈で反応を拾ってみると、主に脊髄反射で騒いでいる人、深く考えずにただ騒いでいるだけの人、騒ぐのが目的の人……と、いろいろです。

たいていは、MavericksになってOS自体のAppleScript機能強化が行われている中で、iWorkのAppleScriptサポートが大幅に後退しているのは、いかがなものか? という話でただ騒いでいるだけで、分析や考察を行っているものはほぼありません。

どちらかといえば、個人的にはこの問題以前に「iWork ‘13自体の完成度そのもの」に疑問を持っており、不完全な仕上がり状態でAppleScript対応されても困るよね、という感想を持っています。個人的には、当面の間はiWorkの旧バージョンを使い続けるでしょう。

そんな中、「iWork ‘13のAutomator対応度はどうなっているんだろう?」と思いたち、おもむろにAutomatorのアクションを調べてみると……iWork ‘13、正確に言えばそのうちのKeynote 6.0については、いくつかのAutomatorアクションが最初から用意されていることが分かりました。

automate.png

Automatorのアクションは、AppleScript用語辞書(sdefファイル)などのAppleScriptとのインタフェースを用意しなくても作れます。しかも、Apple社内にゴロゴロしているObjective-Cプログラマだけで。限られた時間とスタッフのパワーを考慮し、AppleScript対応をやっているほどの時間はない(couldn’t)が(よりエントリーユーザーに訴求する)Automator対応だけはやってしまおう、という判断をしたのだと受け止めています。

その一方で、「あえてしなかった」(didn’t)と見る向きもあります。KeynoteなどのApple製オフィス製品がサードパーティであるMicrosoftのOffice製品の売り上げを喰っていることに、Microsoft側が異議を申し立て、AppleがMicrosoftに遠慮した……というストーリーです。

もしも異議を申し立てるなら、もっと前に申し立てているでしょうし、トータルな機能で見ればPowerPoint以外はMS-Officeの方が圧倒的に上です(使いやすさや見せ方は別として)。

あとは、Appleの内部的な問題解決が優先されたという見方もできます。今回のiWork ‘13は、出来はともかく「見た目と機能」自体はiOS版とOS X版でそっくりです。書類の互換性についても、前バージョンより飛躍的に高まっていることでしょう。

iOSとOS Xの間で「ワンソースでiOS/OS Xの両OS用のアプリがビルドできる仕組み作り」がApple社内(あるいは協力関係にあるサードパーティとの間で)進んでいることは想像に難くなく、その社内的な試験や評価のための場としてiWorksが選ばれ、実証実験が行われた……というものです。

その実験およびブラッシュアップが優先順位の高いテーマであったために、AppleScript対応機能は割を喰った。OSのAppleScript機能を向上させるための策は講じたが、同時にiWorkのAppleScript機能をサポートするだけの余力はなかった……と、そういうことだと考えています。ここらへんの実装をApple社内でもAppleScriptエンジニアリングのチームしか実行できない、と考えるとおそろしく納得の行く話です。