Naganoyaマウスカーソルを指定座標に強制的に移動させて、マウスクリック(プレス)を行う補助アプリケーション+呼び出しAppleScriptです。画面上の部品や座標をクリックする機能マウスカーソルの強制移動とクリックは、AppleScriptではなるべく避けるべき操作ですが、ごく一部の操作を実行するため、ごくごくまれに必要になることがあります。Events」に「click」コマンドがあり、指定のGUI部品か、あるいは画面上の座標をクリックするようになっています。これはあくまで「指定のGUI部品や指定座標をクリックしたというメッセージ」を対象(アプリケーション)に送るというものであり、実際にマウスカーソルを移動させてクリックを実行するものではありません。強制マウス操作ツールの歴史それでも、アプリケーションがAppleScriptに対して機能を解放していない機能を呼び出す必要があって、かつ、メニューやボタンのクリックなどで実行できないような場合には、止むを得ず指定座標のクリックをごくまれに行うことがあります(1年に1度ぐらいの頻度)。10.14で(SIPを解除しないかぎり)スクリプトエディタ上ではサードパーティのFrameworkを呼べなくなりました(AppleScriptドロップレット上ではバンドル内のFrameworkを呼べます)。呼び出し側から一番簡単に利用できる方法は、指定座標のクリック機能を持つアプリケーションをXcode上でAppleScriptで作成しておき、sdefを定義して、AppleScript対応アプリケーションをAppleScriptで作るものです(豆腐をすりつぶして「ひろうす」を作るようなこの迂遠さ。Google翻訳で絶対に伝わらないニュアンス。パンをすりつぶしてパンを作るような、、、)。そのため、いままでFrameworkで運用してきたプログラムを、アプリケーション化してsdefを付加し、スクリプタブルなバックグラウンドアプリケーション(Dockに表示されない、メニューやウィンドウが表示されない)にする必要が出てきます(まんまとAppleにタダ働きさせられているような気がするので気分はよくありませんが)。自分ではほとんど使わないマウス強制移動&クリックツールを作ってみたそこで、sdef(AppleScript用語辞書)をつけたライブラリやアプリケーションを作る方向で調査を行っていました。実際にパラメータの受け渡しをどのように行えるのか、どのあたりでハマるのか、どのぐらいの作業量になるのか。その1つの到達点として、この補助アプリケーション「mouseClick」を作ってみました。Sroreでいちゃもんをつけているのを見かけて、遠い目になりました)。このツールは、AppleScriptからコマンドで操作する専用のものであり、画面上には何も表示されません。簡単なAppleScriptでマウスカーソルの移動とクリックを実行できます。初回実行時はシステム環境設定の「セキュリティとプライバシー」>「プライバシー」>「アクセシビリティ」でmouseClickに「コンピュータの制御を許可」しておく必要があります(管理者権限が必要、2回目以降は操作不要)。forceClickでは、画面の左上を原点とした座標系を使用しています。MacOS時代からこの手の「指定座標の強制クリック系ソリューション」を(止むを得ず)使ってきた身からするとなかなか感慨深いものがあります。Libraries(共有ライブラリ。以下ASLと略)にsdef(Script辞書)をつけて、AppleScriptや他のOSA言語との間で共通して呼び出し可能なライブラリを書くシリーズの続きです。単なるASLにsdefを付けて、各種OSA言語からの呼び出しに対応するようにしてみました。パラメータの省略や別表記のゆらぎを許容するようにしてみました。総仕上げで、Script用語辞書の中にドキュメントをHTMLで表記し、サンプルScriptをワンクリックでスクリプトエディタに転送されるようにしてみましょう。最近、AppleScript用語辞書の中に表や資料が記載されているものがあります。それらは、sdef中にdocumentationタグで書かれているものです。documentationタグ内にはhtmlタグが記載されており、この中にHTMLで書かれたコンテンツが格納されています(ただ漫然と文字列で書いてあるだけですけれども)。ここに、applescript://リンクつきのサンプルが掲載されていることもあるのですが、なぜかApple純正アプリケーションではサンプルそのものが間違っていたりして驚かされます(動作確認ぐらいしようよ)。見た目がスクリプトエディタのデフォルト色分けそのままで美しくありません。そこで、本Blog掲載時に使用しているHTML書き出しプログラムを使用して、applescript://リンクつきのサンプルを掲載してみましょう。見やすくなりましたし、サンプルがすぐに試せるのはいいと思います。sdefはAppleScript記述・構文確認時のテンプレートとしても、実行時のデータとしても使われるので、サイズが大きくなるとこれをparseするのに余計な時間がかかるため、あまり大きくしたくないという開発側の事情もあります。CCの巨大なAppleScript用語辞書。Adobeはまともにメンテナンスできていない巨大な用語辞書を持つアプリケーションでは、改行コードすら削除してサイズを小さくしようとしているぐらいであり、フレンドリーなドキュメントを内包することが唯一にして無二のソリューション「ではない」ことも知っておくべきでしょう(実行速度低下というデメリットもあるので)。sdefから改行コードを削除してサイズを小さくするというのは、CPUの実行速度が遅かった頃のノウハウであり、いまでも本当にそれが必要なのかは疑問です。実際、Keynote、Pages、Numbersなど比較的あたらしめの(それほど機能が多くない)アプリケーションでは「まっとうに読める。改行つき、インデントつき」sdefが格納されています。Naganoya昨日作ったAppleScriptライブラリ「checkboxLib」をアップデートしてみました。typeの記述を正しく昨日のバージョンは問題が見つかっていました。AppleScriptから呼び出す分には問題がなかったのですが、JXAから呼び出すとエラーになっていました。sdef(AppleScript用語辞書)をつけたライブラリは、AppleScriptで記述しつつも従来のOSAXのような運用が可能で、とりわけ他のOSA言語からも使える共有モジュールとして運用できる点が重要です。今日明日ですぐに必要になるわけではありませんが、AppleScriptで記述したライブラリにsdefさえ添付しておけば、JXA側からも呼び出せる共有モジュールとして運用できる「ことになっています」。Librariesの設計思想です。そのため、JXA側からの呼び出しもテストしていたのですが、なかなかお題目どおりには行かず、ちょっとMacScripter.netのBBSで相談して、対処を行ってみました。sdefを書くにあたっては、既存のアプリケーションの膨大なsdefのストックがあるので、それを参考にしていました(たまに記述が間違っているものがあって困ります)。その中で、データタイプにAppleScriptでしか利用できない「list」というタイプを指定していたのが問題でした。AppleScript側からの呼び出しだけで検証していては、AppleScriptからの呼び出し時だけ正常に動く「バグ」を抱えたままの状態である可能性を否定できません。他のOSA言語からの呼び出しも検証しておかないと、潜在バグのあぶり出しが行えません。</parameter>と、修正。これで、JXA側からも呼び出せるようになりました。JXAからの呼び出しに対応(2)〜enumをそのまま処理しないとりあえず予定していた機能は実現できたわけですが、sdefにenum(定数)を定義して使ってみたくなりました。パラメータをダイレクトパラメータ(文字列、数字など)のみで指定するだけは不満が出てきそうです。して、「こんな感じかな?」と手探りでenumを定義してみたのですが、例によってAppleScript側ではエラーにならないのに、JXA側ではエラーになりました。結局、ライブラリ側のパラメータ受信部分でenumをそのまま処理せず、いったん文字列に変換して処理するようにしてみました。いずれも、AppleScript側だけだとエラーになりませんでしたが、JXA側からの呼び出しもできるようにしておけば、他のOSA言語やObjective-C/Swiftなどの言語からの呼び出し時にも問題が出ないことでしょう。現状でJXAの存在意義はその程度です。JXAからのライブラリ呼び出しについては、現行バージョンでもパラメータの省略時にエラーが出るのですが、「パラメータの省略はできないもの」と割り切っても問題はなさそうです。最終的にsdefは上記(↑)のようになりました。enumの宣言部分の書き方がこなれていなかったので、その部分を修正。このsdefをスクリプトエディタでレンダリングすると、このようになります。Naganoyaアイテム番号の入ったリスト(配列変数)をもとに、ヒットしなかった項目を返すというAppleScriptです。これは、なにがしかのデータとなにがしかの書類上に配置されたデータの照合を行って、存在が確認されなかったデータの一覧を作成するために作成したものです。存在確認といえば、たいていは「存在していたデータそのもの、あるいはデータのアイテム番号一覧」といったものを出力するようになっています。そこに、「存在が確認できなかったデータの一覧が欲しい」という要望が出てくることも、だいたいは普通の出来事です。この手の「言語化すると大したことはないが、実施に精神的な抵抗感をおぼえる処理」といいいますか、「後片付け的な処理」というのは、書くのが面倒で後回しになりがちなものでもあります。事実、実際に書いてみたら、、、既存のサブルーチンの組み合わせで作りましたが、1日たって見直してみると何が書いてあるのかよく思い出せないレベルです(既存のサブルーチンの組み合わせが過ぎて、意味がわかりにくいのかも)。Libraryを入れて、Library側の機能を呼び出すことができます。Libraryでメイン側で宣言した変数値を参照する基礎的な内容のAppleScriptです。mainTest.scptd基礎は大事なので、ちょっと怪しいと思ったら必要な部分だけ組み立てて動作確認を行っています。冒頭で(暗黙のrunハンドラの前で)global宣言を行えば、サブ側でも同じ値にアクセスできることを確認しました。一度、巨大なプログラムでやらかしたことがあって、global変数はあまり使わないように自粛していたのですが、必要とあらば仕方ありません。▲メイン側のAppleScript。Libraryを入れて呼び出す▲メイン側のAppleScriptのバンドル内に、「EverythingToTextKit.scptd」(リストやレコードなどのデータなどすべてテキスト化するライブラリ)と、「sub1.scptd」(サブ側のScript)を格納している▲サブ側のAppleScript。Naganoyarecord型変数に対して、ラベルを指定して変更するAppleScriptです。各種データ型に対応しています。scriptで実行するとか。提唱者本人が書いているので間違いない)。特定のラベルを指定してデータを取り出したり、設定したりはできますが、ラベルを動的に生成して設定するようなことはできませんし、指定のラベルが存在するかどうかを確認する機能もありません(エラートラップを仕掛けて値の取り出しを確認するぐらい?)。NSMutableDictionary)に変換し、Cocoaの機能を使って加工することが一般的になってきました。CocoaのNSDictionary/NSMutableDictionaryにはAppleScriptのGUIアプリケーションのオブジェクトは格納できませんが、アプリケーションのオブジェクトを扱わない用途には問題ありません。本Scriptは、そんな中で(巨大なAppleScriptのプログラムを書く中で)些細なサブルーチンを整備する必要があったために書いたものです。いう細かい部品を積み重ねていくと、いろいろと巨大な概念を積み上げていくのに便利なもので。いう指摘はあるかもしれませんが、そこはマイナスの数を指定することで引き算は実現できます。AppleScriptだけで書くこともできます。本ルーチン(↓)では、記述性を高め、取り出したり入れたりといった記述を省略することが目的です。valueForKey:aKey–指定キーの存在チェック。NaganoyaNumbersの表のカラムを表現するアドレス文字列(26進数)と数値の間のエンコーダーおよびデコーダーのAppleScriptです。2004/2008で採用されたカラムアドレス形式に対処するためのScriptでした。Excel上のセルのアドレス(場所)を指し示す方法は、「R1C1」(行とカラムを数値指定)形式、あるいはAppleScriptの行オブジェクトとセルオブジェクトで指定する形式でした。そこへ新たに「A1」形式......画面上で表記されている行、カラムと親和性の高い形式が採用されることになりました。当初は相互変換のための関数なども用意されていなかったと記憶しています(間違っていたらご指摘ください)。そのため、Scripterが自力でこのA1形式に対応する必要が出てきました。そんな中、Excel書類にAppleScriptを埋め込んで実行するAppleScriptを開発。本ルーチンはそのScript開発のために作成したものです。2008でVBAの処理系が外されてMac上のVBA的なマクロ処理はAppleSctiptに一本化されるという話になっていたため(当時の話)、これを好機ととらえ、マイクロソフトのご担当にデモして、US本社で紹介していただくということになりました。その会議上でVBAの復活プランが発表され、自分の提案したプランは廃案に(まさか当時のREALbasicのコンパイラの開発者を引き抜いてきてVBAの処理系をスクラッチで書かせるとは思いませんでしたわー)。2011でVBAの処理系が復活。本ルーチンも割とHDDの肥やしとして絶賛在庫状態になっておりました。2011でVBAの処理系が復活したことを知らない方がいて、「VBAで動いているマクロをAppleScriptに移植してほしい」という問い合わせがあるのですが、「Excelの最新版を購入してください。VBAがありますよ」とお返事しています。最新のExcelが動く環境を購入する費用よりも安く仕事としてお受けすることは困難なので。そこから年月が流れ、AppleがNumbersをリリース。2004/2008と同じ形式になっているために、しまいこんでいたルーチンをふたたび引っ張り出してきた次第です。一応、条件つきで使えるものの、作りが古い(やっつけ仕事な)点が気になります。誰かがもっといいルーチンを作って使っているに違いありません。一応、本ルーチンでは1〜1351の範囲での動作を確認しています。改良したいところではあります。実用上は、Numbersでそこまで大きなデータは扱わない(はず)ので、問題はあまりないものと思われます。Naganoyaリモート操作ソフト「TeamViewer」の画面から、ユーザーIDとパスワードを取得するAppleScriptです。Scriptingの機能を使って、画面上から情報を取得し、正規表現で抽出してみました。TeamViewerで実家のMacなど、離れた場所にあるマシンをメンテナンスする必要がある場合に、実家から電話がかかってきて、TeamViewerのパスワードとIDを口頭で教えてもらって接続する必要があるわけですが、親が高齢のためそれが心もとなくなりつつある昨今、確実に確認するために作成したものです。その場で、(自分のために)「TeamViewerを起動してIDとパスを確認して自分あてにメールで送ってくるAppleScript」を作りかけたのですが、途中からビデオ編集の仕方を教えろなどと言われて説明する羽目に。Viewを表示するAppleScriptです。Lib」が定番ですが、高機能なぶんライブラリ中にFrameworkが含まれていたりして、場合によっては困ることもあります。見た目をカスタマイズしたい場合にも、あまりいじくれなくて困ることもあります(とくにデータの文字サイズを変更できなくて困ること多し)。そのため、AppleScriptだけで書いた表UI表示用の部品も、たまに必要になることがあります。alertShowHelp:–ダークモードの判定。ダークモード時:true、ライトモード時:falseが返る。Naganoya指定の画像ファイルをグレースケールのPNG画像ファイルに変換するAppleScriptです。Framework化してみたところ、グレースケールの画像を要求されたため、画像をグレースケール化するルーチンを作ってみました。結局、MNISTの手書き画像認識はうまく行かなかったのですが(全部「0」が返ってくる、、、)、グレースケール変換ルーチンは実用的だったので載せておくことにしました。Naganoyaアラートダイアログ上にTextViewを表示して、指定のテキストを閲覧するAppleScriptです。前バージョンの「自分のソースコード」表示というのは意味不明だったので、プロセス一覧を取得してみましたヘルプボタン(?)を付け、アラートダイアログのウィンドウ背景を半透明に設定。Modeの切り替え時に読みづらい文字なども出てきたため、モード判定を行って表示色などを変更しています。アプレット書き出ししたときに、スクロールビューがマウスのスクロールホイールの操作に追従したスクロールを行ってくれないので、そのあたり何か追加でNSScrollViewに設定を行う必要があるのだろうかと。Mode(以下同様)▲ヘルプボタンをクリックしたところ。本当にアンカーを指定して指定のヘルプコンテンツを表示させることもできる模様。(Enhanced)で書き出して実行したところ。alertShowHelp:–ダークモードの判定。Naganoyaアラートダイアログ上にTextViewを表示して、指定のテキストを閲覧するAppleScriptです。これといって何か表示するものを思いつかなかったので、自分自身のソースコードを取得して表示しています。Debugger上で実行した場合には自分自身のソースコードをテキストビュー上で表示します。読み取り専用のスクリプトやアプレットで実行している場合にはソースコードを取得できません。何か適宜自分で表示させたいテキストを与えてみてください。Naganoya指定のAppleScript書類のソースコードを取得し、構文色分け情報をもとにコメント部分の文字列のみを取得するAppleScriptです。Assistant」に入っています)。Cocoaの機能を利用して処理すると、スクリプトエディタを操作せずにAppleScript書類から情報を取得できます。GUIアプリケーションを操作しないぶん、並列処理にも有利です。本Scriptを実行すると、指定のAppleScript書類をバックグラウンドでオープンして、書式情報を取得し、コメントに該当する箇所の文字のみを取得して返します。library)ほんの少し修正することで、ソースコードからコメント部分のみを削除したテキストを取得することも可能です。Objectでキー検索を行い、キーが合致する要素に定義されているオブジェクトを取得するAppleScriptです。ような、キーとなるラベルには「空白文字や使用禁止文字を含まない」文字しか使えませんし、キーに何らかのオブジェクトを指定することはできません。10.10が出た頃)。いう(CocoaオブジェクトをキーにしたDictionaryの検索)プログラムを組もうとして、Dictionaryから「valueForKey:」でvalueを取り出そうとして(エラーに遭遇して)試行錯誤していました。1:"Red"}実際にはこれは「objectForKey:」で取り出さないとエラーになってしまうんですね。その確認のために書いた基礎確認用のAppleScriptです。基礎の再確認はとても大事です。Naganoya与えられた1次元配列のデータのすべての順列組み合わせパターンを計算し、そのとおりに配列を並べて連結した文字列を、すべての順列組み合わせパターンについて生成して返す(Permutations)AppleScriptです。初版ではありもののサブルーチンを組み合わせて、検証を行うには十分なものでした(v2)。本来その用途に作成したものではないルーチンを寄せ集めて作ったので、組み合わせ数が増えると処理時間がかかりすぎるきらいがありました。そこで、こうした処理(Permutations)を英語でどう呼ぶのかを調べ、AppleScriptの実装例を調べたら、灯台下暗し。MacScripter.netにありました。そのままではいまひとつ使いにくかったので、きちんと組み合わせた文字列を1次元配列で返すように組んでみたところ、オリジナル版よりは処理時間はかかっていますが、初版からくらべると大幅に処理速度とメモリ使用効率が改善されました。“ATCG”.....}4要素の順列組み合わせ計算:5倍速5要素の順列組み合わせ計算:10倍速6要素の順列組み合わせ計算:30倍速7要素の順列組み合わせ計算:67倍速8要素の順列組み合わせ計算:(計測不能)というように、大規模データになればなるほど高速化の度合いが高くなります。AppleScriptにしては大規模データを扱う演算なので、Cocoaの機能を積極的に利用することで高速化を行なっています。Thunderbolt)で処理時間を計測してみたところ、2012のMBPのほうがわずかに高速でした。NaganoyaiTunes上で選択中の全トラックの再生開始位置を15秒に設定するAppleScriptです。元に戻す(0秒に変更する)ものも掲載しています。いうことになるわけですが、、、友人がFacebookに投稿していた「ちょっといいノウハウ」をそのままAppleScriptで自動化したものです。素材となる曲を選ぶ際に、冒頭のイントロ部分を聞き飛ばすために必要なようです(業務系の、DJとか楽曲の選定を行う業務系のプロの方々)。指定した時間の箇所から再生を開始します。Naganoya与えられた1次元配列のデータのすべての順列組み合わせパターンを計算し、そのとおりに配列を並べて連結した文字列を、すべての順列組み合わせパターンについて生成して返すAppleScriptです。InDesignやIllustratorなどの書類上に元データをレイアウトした際に、複数のテキストフィールドに分解してレイアウトされていることがあります(見た目重視で)。その分割されたテキストフィールドを元データと比較する際に、位置情報などをもとに「このあたりが一緒になってそうだ」とあたりをつけるわけですが、左→右、上→下という順序に基づいて配置されているという保証はありません。見た目やインパクト重視で、あえて順番を変えているケースも考えられます。そこで、並び順について「考えられるかぎりの全ての順列組み合わせでつないでチェック」するという脳筋な(マッチョな)方法を考えてみたりもするわけです。実際、この手の計算にはコンピュータは実に向いている道具なので(やらない方がおかしい?)。そんな計算を行うために作成したAppleScriptですが、意外や意外、すべての順列組み合わせパターンを計算するルーチンは作ってありませんでした。性格的に、このあたり作ってないと気がすまないと(自分でも)思うものの、これだけ数千本も数万本もAppleScriptを書いておいて、手付かずの処理があったというのは逆に掘り出し物というべきなんでしょう。そのため、過去に作った一番近いルーチンを流用して、すべての組み合わせパターンを計算し、そのうえで「すべての要素が異なる組み合わせ」だけを抽出しています(すべての組み合わせを計算するのに、「AAAA」とか「AAGG」とかの要素が重複する項目は削除)。元になっているルーチンは、製品コードなどの複数桁から構成され、それぞれの桁で数値の範囲が異なるという規則性を持つコードを、すべてのパターンについて生成するというものでした。製品カタログ掲載データなどで「ありがち」な仕様です。上限値}とコードの生成ルールを定義しておいて、そのルールにもとづいてすべてのパターンのコードを展開していました。出来上がったプログラムにそれほど時間はかけていませんが、それなりの行数に(圧縮記述をせず、見やすく、高度な処理を書けば、行数が増えるのは当然のことなんですけれども)。「もう少しシンプルに書けそうなもんだけどー?」という気持ちでいっぱいですが、まずは機能を実現することが重要です。この処理自体を「Permutations」と呼ぶことを見つけ、MacScripter.netにそのものズバリの処理がずらずらと並んでいるのを見て脱力しました。再帰で処理するのかぁ。項目数を増やすとやっぱりメモリが足りなくなって、処理がきつくなるのは同様の模様で。NaganoyaCotEditorで編集中のMarkdown書類を、MacDownでPDF書き出しして、Skimでオープンして表示するAppleScriptです。CotEditorにMarkdownのプレビュー機能がついたらいいと思っている人は多いようですが、MarkdownはMarkdownで、方言は多いし標準がないし、1枚もののMarkdown書類だけ編集できればいいのか、本などのプロジェクト単位で編集とか、目次が作成できないとダメとか、リンクした画像の扱いをどうするのかとか、対応しようとすると「ほぼ別のソフトを作るのと同じ」ぐらい手間がかかりそうです(メンテナー様ご本人談)。そこで、AppleScript経由で他のソフトを連携させてPDFプレビューさせてみました。これなら、誰にも迷惑をかけずに、今日この時点からすぐにMarkdownのプレビューが行えます(当然、HTML書き出ししてSafariでプレビューするバージョンははるかかなた昔に作ってあります)。Scriptingの実行が許可されない)。OS側のスクリプトメニューに登録して実行する必要があります。Scriptingを利用してメニュー操作を行なっているため、システム環境設定で許可しておく必要があります。Scirptingを用いてCommand-Dで指定して一律に場所指定が行えるデスクトップフォルダ)に同名のPDFが存在しないかどうかチェックし、存在すれば削除するといった処理が必要ですが、面倒だったのであらかじめMarkdown書類をUUIDにリネームしておくことで、書き出されたPDFも同じくUUIDのファイル名になるため、論理上はファイル名の衝突を回避できるため、削除処理を省略しています。"編集中のファイルはMarkdown書類ではないようです。Scriptingを使用。Naganoya指定のMarkdown書類をメモ.app(Notes.app)に新規エントリとして登録するAppleScriptです。▲テストに使ったMarkdown書類Markdown書類をUTF-8のテキストとして読み込み、それをHTMLに変換し、そのままメモ.app(Notes.app)に新規エントリとして登録します。Markdown書類のHTMLへの解釈はオープンソースのMMMarkdownを利用しています。自分はMarkdownエディタにMacDownを用いているため、使用しているMarkdown書類もMacDownが解釈する、割と自由度の高い(HTMLコードをそのまま書いておいても許容するような)Markdownのコードを与えて処理してみましたが、これらはMMMarkdownでHTML変換する際にスルーされたせいか、装飾がかなり再現されているように感じます。Markdownタグの互換性はエディタごとに大きく異なるため、確認はお手元のエディタ用のMarkdown書類で行なってください。~/Library/Frameworks/)▲MMMarkdownを用いてMarkdown書類をHTMLに変換し、メモ.app(Notes.app)に登録した内容。表以外はけっこう反映できているタイトルやメモ.app(Notes.app)上の登録先などは適宜変更してみてください。何も考えずに、手元にあったMarkdown書類を処理してみたところ、http://のリンクや、applescript://のリンクなどもそのまま反映。色情報もそのまま反映されているようです。10.14.5上で、Applet形式で実行。どちらか好きなものを選んでください。Framework入りでAppletに書き出したものをダウンロードできるようにしておきました。10.14以降ではこちらもお試しください。フレームワークのリンク先が間違っていたようで、バイナリを書き出しし直しました。10.14環境で一部Scripterが言っているような「アプリケーション操作の認証を再度求められる」ような現象には遭遇していません。Naganoya最前面のKeynote書類の文字色を置換するAppleScriptです。Keynoteは文字色の置換をする機能が実装されていないので、個別に手で色を変更するか、あるいはスタイルを編集して一括で修正するやり方になります。そこで、AppleScriptで色置換を行う処理を書いてみました。表の背景色を置換する処理を書いたときの部品を大幅に使いまわしています。文字色の取得や判定は、テキストアイテムの1文字目の情報で判断しています。途中で色を変更しているような場合にはうまく検出できません(処理スピードを重視したことと、自分の利用方法の範囲ではそういう文字ごとに異なる色を指定するところまではサポートしなくてよいと考えたためです。仕事ならもうちょっと真面目に作り込むかもしれませんが、、、、)。ポップアップメニュー中の色名の動的な推定に、オープンソースの「DBColorNames」をフレームワーク化した「dbColNamesKit.framework」を利用しています。~/Library/Frameworks)▲左上の時刻部分の色を置換したい▲本Scriptを実行した直後。最前面のKeynote書類のすべてのテキストを走査して文字色を取得する▲取得した文字色リスト。この中から置換対象を選択する。