View表示ダイアログを表示するAppleScriptです。項目選択を行う簡易ユーザーインタフェース(ダイアログ)で、選択肢の数が多い場合に備えて項目のキーワード抽出機能を付加したものです。Viewと組み合わせて試してみました。データを返すAppleScriptです。試作品なので、あちらこちらに「お可愛らしい」実装が転がっています。NSBoxがまだまともに使いこなせていないあたりとか(Xcode上で部品として配置するのは楽勝ですが、プログラムから動的に生成して使用するのは別なので)。抽出キー数は可変で外部から指定できるとよいのですが、本Scriptでは固定です。各抽出条件も外部から供給するのが本来あるべき姿ですが、ハードコーディングしています。あと、TableViewの下側に謎の余白があるのは、めんどくさくなってそのまま放置しています。これで外部から各種パラメータを指定できるようにして、sdefつけて1命令で呼び出せるようにしておけば、レコード数の多い選択項目から条件抽出しつつ項目選択できてよいでしょう。プログラム内容自体は、高度でもなければ高尚でもありません。実にダラダラとGUI部品のパラメータを設定しているだけです。if–このあたり、複数条件をハードコーディングしているのは超絶頭悪い。NaganoyaiTunesLibrary.framework経由でiTunes/Music.appのライブラリのジャンルごとの再生回数を集計するAppleScriptです。10.14.6)で0.7秒程度で終了します。10.15.1で0.6秒程度です。10.15以降(Music.app)でも同様にiTunesLibrary.framework経由でライブラリへのアクセスが行えます。Naganoya指定のRTFファイルから書式情報を取得し、フォント名とフォントサイズのペアをスタイルを反映させたポップアップメニューで選択。RTFの内容を解析したのち、ダイアログが表示されます(ここの所要時間は読ませるRTFのサイズ次第)。ポップアップメニューで書式を選ぶと、すぐさま抽出した箇所をすべてまとめて表示します。dataダイアログ表示前に書式ごとの抽出を完了し、個別のTabViewに抽出後の文字データを展開しておくので、ポップアップメニューから選択すると、展開ずみのデータを入れてあるTabViewに表示を切り替えるだけ。切り替え時に計算は行わないため、すぐに抽出ずみの文字データが表示されるという寸法です。今回は短いサンプルデータを処理してみましたが、サンプル抽出時にあらかじめ範囲指定するなどして、データ処理規模を限定することで処理時間を稼ぐこともできることでしょう。テキストエディットでオープン中のRTF書類のパスを取得して、それを処理対象にしてもいいでしょう。やっつけで作ったのでスクリプトエディタ上でCommand-Control-Rで実行しないと動きません(メインスレッド実行をプログラムで強制しても、途中でクラッシュしてしまいます)。それほど時間もかけずに作ったやっつけプログラムなので、あまり原因追求も行えずそのままです。NaganoyaiTunes/Musicのライブラリに入っている楽曲データのジャンル分けのゆらぎ吸収を行う、ジャンル名のいわゆる「名寄せ」を行うAppleScriptです。▲1つのアルバム中でもジャンル名に表記ゆれがあるのは勘弁してほしいiTunes/Musicライブラリ中の全楽曲の最終再生日時を24時間の各時で集計を行い、ジャンルごとに再生時間に偏りがないかどうかを分析するため、さらにジャンルごろに集計してみました。「名寄せ」(なよせ)は昔から情報処理に見られる泥臭い地道な処理で、データ上の表記ゆれを吸収するための処理です。地名などの固有名詞で多く見られます(念のためにWikipediaで調べたら、異なる業界では割とブラックな言葉として用いられている模様)。このジャンル名が英語で入っていたり日本語で入っていたりと、ゆらぎが発生しているので、同様のジャンル名であれば同じものとして合算して集計してみました。英語で表記されたジャンル名ではなく日本語で表記されたものを採用(=すべてアルファベットで書かれたものを不採用)しています。それほどいじめ抜いていない(自分の環境でしかテストしていない)ので、ジャンル名の名寄せリストはもう少し鍛えておく必要があるものと思っています。IDで指定したアプリケーションからすべてのLocaleを取得し、ダイアログ選択したLocale内のすべてのstringsファイルを読み込んでNSDictionary化して指定のキーワードを含むものを抽出するAppleScriptです。stringsファイルのパスをリストで返します。調査のための下調べを行うものです。getLocalizationsFromBundleID–指定アプリケーションファイルの、指定Localeにおけるローカライズ言語リストを求める。IDで指定したアプリケーションのバンドル中(/Contents/Resources/)のすべてのLocalizationに存在する指定のstringsファイル内で、指定キーの値を取得するAppleScriptです。macOSの日本語環境では、Finder上でコピーしたファイルのファイル名の後方に「のコピー」といった文字列が追記されますが、他のLocaleでどのような文字列が使用されているか調査するために作成したものです。getLocalizationsFromBundleID–指定アプリケーションファイルの、指定Localeにおけるローカライズ言語リストを求める。Naganoya指定フォルダ以下のすべてのファイル名とフォルダ名から絵文字を除去するAppleScriptです。StanleyのremoveEmojiルーチンを使っています。10.14.1で絵文字が大幅に追加されたため、これらの絵文字をファイル名に用いていた場合には10.14.1以下のバージョンのOS環境にそのままファイルを持っていくことができません。コピーできない(エラー)という状態になります。絵文字自体に害はないのですが、規格がコロコロ変わる(追加される)ことで、ファイル名に用いるのには問題があるということでしょう。▲もともとのファイル名、フォルダ名。絵文字を大量に使用している(普段はファイル名に絵文字は使っていません)▲本Scriptで一括で処理したファイル名、フォルダ名。pathを用いて指定フォルダ以下すべてをリネームするようなScriptは組んでいなかったので、ちょっと考えさせられました。10.13.6の環境に持っていけました。絵文字がないと寂しい感じがします指定フォルダ以下のファイル/フォルダを一括取得するのに、今回はあえてSpotlightを使っていません。ファイルサーバー上のファイル/フォルダを処理する可能性がありそうなのと、外部ライブラリを使わないほうがよいと考え、このような構成になっています。NaganoyaバンドルIDで指定したアプリケーションのResourcesフォルダ中の、指定ロケールのstringsファイルをすべて読み込んでkeyを取り出すAppleScriptです。アプリケーション内の指定のローカライズしたメッセージ(テキスト)の内容を取り出すことはできますが、そのためにはキーを知っておく必要があります。そのキーを取り出してローカライズされた文字列を取り出すため、キーを調査してみました。これをそのまま何かのツールなりScriptに使うというものではなく、いわゆる「下調べ」のためのScriptの部品です。ありもののルーチンを再利用しただけのプログラムでできていますが、ありものはありもので、数千本のAppleScriptのストックからそれを探し出してくるのも一苦労です。アプリケーションバンドル内のResourcesフォルダ以下の(各lprojフォルダ以下の)stringsファイルの中身はまんま(シリアライズした)NSDictionaryなので、そのままDictionaryに読み込んでallkey()などのメソッドを実行できます。昔のstringsファイルはテキストファイルだったような気がしますが、テキストファイルだとparseしないといけないんで、ビルド時にparseしておいてDictionaryの状態でファイルに書いておくのは正しいと思います。8あたりから、アプリケーションのローカライズのルールが変更になったようで、基本となる言語環境がBase.lprojになり、英語はen.lprojといった1ローカライズ言語という位置付けに変更になりました。NSLocalizedStringFromTableInBundleを使ってアクセスしようかとも思ったのですが、こちらはまだ目的を達成できていません。11上で実験的に作成したAppleScriptアプリケーションのバンドル構造(左)。ローカライズしていない状態だとEnglishではなくBase.lprojが作成される。右はKeynote.app/Contents/Resources/ja.lprojフォルダの内容。getLocalizationsFromBundleID–指定アプリケーションファイルの、指定Localeにおけるローカライズ言語リストを求める。Naganoya指定のテキストをAppleScriptとみなして構文確認して、指定の構文要素が入っていないかチェックするAppleScriptです。scriptすると、一応いろいろ保護機能はあるものの、セキュリティ的にリスクの高い操作になってしまいます。scriptコマンドで実行されてしまったらと思うとゾッとします。ためしに実行してみたら、実行権限がないので実行できないエラーになりましたそこで、文字列をいったんAppleScriptとして評価(構文確認)し、コマンドなどの危険と思われる構文要素が入っていないかどうかチェックするものです。これら、「コマンド」および「追加コマンド」といった構文要素が入っていたらtrueを返します。scriptしてよいかどうか判定できるようにするものです。repChar–リストに入れたレコードを、指定の属性ラベルの値で抽出。Naganoya指定のAppleScriptのテキストを構文確認して、構文的に「変数・プロパティ、サブルーチン名」部分に該当する部分のテキストを取得して、目的のテキストに差し替えるAppleScriptです。Debugger上の生産性を向上させるために書いたものです。Debuggerはいわゆる「デバッグ」段階では役に立ちますが、快適にScriptを書くための機能はほとんどありません。いわゆる、ブレークポイントの設定、プログラムのステップ実行、ステップ実行時の変数値のリアルタイムモニタリング、という「デバッガ」の機能は持っていますが、巨大なScriptを書いたときの特定のサブルーチンを前回実行時に指定したパラメータで再実行して結果を比較といった機能は備えていません(切実にほしー。自分で作りたいぐらい)。記述中のAppleScriptの選択部分の構文要素を検出して特定の構文要素(コメントとか変数名とか)についてのみ処理を行うような機能が用意されていない点が残念です(スクリプトエディタ用は数百本書いて使っているので)。プロパティ文の記述などは毎回同じようなものをコピペで足すだけなので、書き足すのがかったるいと思っていました。そこで、編集中のAppleScriptの範囲から構文要素を考慮して変数名だけ書き換えてくれるといった機能を足してみました。{}実際にメモリ上でコンパイル(構文確認)して、書式付きテキストを取得し、そこから構文色分け設定に基づいて該当する構文要素をピックアップ。該当する構文要素の箇所を置換します。値が近すぎると)エラーになります。先日報告された「RGB以外の色空間の色」で設定してある場合でもRGB色空間に色データを変換して処理しています(まさかCMYKとかグレースケールで色設定しているユーザーがいるとは思わなかったわー)。Debugger上での動作を確認していますが、Applet書き出ししたときにまだ謎なメッセージを出すようです。何か、明示的にメインスレッドで実行する必要のあるものがあったでしょうか。Naganoyaリモート操作ソフト「TeamViewer」の画面から、ユーザーIDとパスワードを取得するAppleScriptです。Scriptingの機能を使って、画面上から情報を取得し、正規表現で抽出してみました。TeamViewerで実家のMacなど、離れた場所にあるマシンをメンテナンスする必要がある場合に、実家から電話がかかってきて、TeamViewerのパスワードとIDを口頭で教えてもらって接続する必要があるわけですが、親が高齢のためそれが心もとなくなりつつある昨今、確実に確認するために作成したものです。その場で、(自分のために)「TeamViewerを起動してIDとパスを確認して自分あてにメールで送ってくるAppleScript」を作りかけたのですが、途中からビデオ編集の仕方を教えろなどと言われて説明する羽目に。Naganoya指定のAppleScript書類のソースコードを取得し、構文色分け情報をもとにコメント部分の文字列のみを取得するAppleScriptです。Assistant」に入っています)。Cocoaの機能を利用して処理すると、スクリプトエディタを操作せずにAppleScript書類から情報を取得できます。GUIアプリケーションを操作しないぶん、並列処理にも有利です。本Scriptを実行すると、指定のAppleScript書類をバックグラウンドでオープンして、書式情報を取得し、コメントに該当する箇所の文字のみを取得して返します。library)ほんの少し修正することで、ソースコードからコメント部分のみを削除したテキストを取得することも可能です。Debugger上でオープン中の2つのAppleScript書類のうち、名称が同じハンドラ(サブルーチン)の内容同士を比較して、お互いに合っているかどうかをチェックするAppleScriptです。Lib内のフレームワークが呼べないため)。▲本Scriptはスクリプトエディタの環境設定で行うAppleScriptの構文色分け設定色が「RGBカラー」でないとエラーになります。CMYKとかグレースケールカラーで指定して、そのままRGBに変換されずに保持される(CMYK色はアクセスしているうちにRGBに変換されるが、グレースケールは保持される)ため、色空間の判定を行ってRGB色に変換してから処理する必要があります(自分用メモ)スクリプトエディタ上で設定する構文色分け設定をもとに、AppleScriptの構文要素を考慮したハンドラ一覧を作成し、2つのAppleScript書類の間に共通して存在するハンドラ名のハンドラ(サブルーチン)のAppleScriptソースを取得。インデント(tab)を削除したのちに比較を実行。共通名称のハンドラすべてをチェックして、結果を表インタフェースで表示します。初版(v1)では実行するたびに1つのハンドラをチェックしていたのですが、あまりにかったるいので即座にループですべて調べてまとめて結果を表示するようにしました(v2)。Object(JavaScriptでいうところのClosureみたいなもの)で論理分割された同名のハンドラが複数回登場するパターンは想定していません。複数検出するとエラーになります。Debuggerを対象にせずスクリプトエディタを対象にしてもよいのですが、些細な変更で実現できるため、興味のある方はやってみてください。あと、本Scriptは必要に迫られまくって作ったものなので、動作でおかしい箇所があったらぜひぜひご指摘を。個人的には、ハンドラ名称を構文要素を考慮しつつ取得している一方で、ハンドラの内容は単なる文字列検索で取り出しているというあたりにアンバランスさを感じます。10.14.5上のスクリプトエディタで、構文色分け情報を何回設定しても「黒」になるという現象に遭遇したのですが、他のユーザー環境上での再現性については未知数であるため、まだレポートできない状況です。その後、本ツールは強化されて、構文色分け設定にRGB以外の色が設定してあってもRGBに変換して処理する機能や、構文色分け設定を参照したコメント除去機能や、各種書式情報の取得を3倍高速化するカラーキャッシュなどの機能を実装したプログラムに(必要に迫られて)成長しました。Objectの使用は考慮していない。Debugger上でオープン中のAppleScript書類で、選択中の文字列の構文要素名を取得するAppleScriptです。Editorのほうが生産性が上がってしまった今日このごろ。▲筆者がこれでもかと強化しまくっ。