Pagesの座標系

Posted on 9月 19, 2021 by Takaaki Naganoya

ここしばらくPagesで書類を作る日々が続いていました。間もなく終わりそうな気配です。

Pagesは不思議なワープロというか簡易DTPアプリケーションで、Keynoteから派生したという独特の出自からして、さっさと何かページレイアウトを作って仕上げる……という味付けのアプリケーションであります。

さっさと作るのは、比較的苦もなくできます。１ページもののレイアウトぐらいならそうでしょう。

複数ページのレイアウトになってくると、やや大変です。ルーラーを表示して、ページのレイアウト範囲に補助線を引いて参考にするという作業が……できないことはないのですが、毎ページルーラーを引き直す必要があります。

書類のマスターページという概念がなく、いきなりテンプレートを作らされます。

それでも、１書類で巨大な内容を作らない。書類を極力小分けにする、といった方法でなんとか使いこなしてきました。

昔のバージョンのPages（iOSとソース共通化する前、旧Pagesと呼ぶ）は、もっとDTPソフトっぽい機能を有しており「普通のユーザーが使えるInDesign」とも言われ、けっこうよかったのですが……。

そんな現在のPagesではありますが、いろいろと対策が進んで作れるドキュメントの幅や分量も増えてきました。いま、200ページぐらいのコンテンツをPagesだけで作っていますが、もちろん書類は小分けにしまくっています。

その、Pagesの書類も分量が増えてくると……ヤツを入れたくなってきます。入れないとわからなくなってきます。ツメです。英語で表現すると、辞書のIndexといえばいいんでしょうか。辞書のページの端についている、アルファベットごとに検索しやすくするために印刷されている記です。

DTP系の人間にはおなじみの「手で作るのはごめん被りたいアイテム第１位」のアレです。手で作るなんて正気の沙汰ではありません。

でも、Pagesにその機能がないので、手作りしました。手作りしたのちに、やっぱプログラムで制御しないとしんでしまうと思い、いろいろ調べだしました。

そして知るのです。Pagesの座標系が全ページつながった独自のものであることを。

つまり、ツメの（縦方向、Y軸）の各ページ単位の座標系がないので、各ページのY座標の原点からの相対座標を計算するためには、ページの物理的なサイズ（座標的なX、Y軸の上限値）を知る必要があります。

ページの物理的なサイズを取る手段があるだろ……ない。

テンプレートには物理的なサイズの定義とかが……ない。

現在編集中の書類のページのサイズがわからないのは、けっこう困りますが……オブジェクトのサイズは計測できるので、あらかじめ各テンプレートの上にページいっぱいのサイズでオブジェクトを作っておいて、そのオブジェクトのサイズ（width、height）を調査。

テンプレート名称なりIDから、ページサイズ表を検索して、座標的なサイズを取得するしかないでしょう。

ヤバイ本のiOS版を発売

Posted on 9月 5, 2021 by Takaaki Naganoya

「空前絶後　あなたの知らないヤバイAppleScriptの世界」のiOS版、FileMaker Goを使って読む電子ブックの販売を開始しました。1,000円です。

→ 販売ページ

なんでこれを作ろうと思ったか？

PDF版をiOS上で読んでいただくことも可能ですが、画面の縦横比とかなんとか。とにかくPDF版の読書体験がよくありません。

そして、AppleのiBooks Storeに本を出すのに、ISBNだ何だといろいろうるさく、これに付き合っていられません。

そのため、いろいろ検討したうえでFileMaker Goに白羽の矢を立て、このアプリケーションを読書用のプラットフォームとして活用するために実験を繰り返していました。

小さな画面で文字を読むのは、ガラケーの時代から大変なことですが、スマホで読んでも大変なことに変わりはありません。

レイアウトに一緒に画像を入れるのも大変なので、基本的に文字コンテンツだけです。一応、なんとかすれば画像表示用レイアウトも混在させて、画像を見ていただくことは可能です。

これまで、PDF版（フル・レイアウト）のオマケとか、サブセットとして出すとか（AppleScriptポケットリファレンス）、そういう試みはしてきましたが、.fmp12単体で売ってみるというのははじめてのことです。iPhoneだけで暮らしたことが皆無なので、まだちょっと見落としていることがあるかもしれませんが、失敗も含めて貴重な経験になることでしょう。

FileMaker Goのデータベースアプリケーションとしての出来については、いまひとつ評価が定まっていないというか、バージョンごとに少しずつ問題があるという見立てになっています。期待をしすぎてはダメというところなんでしょう。

ですが、単にレイアウト切り替えをするとか、フィールドに入れた文字を読むというだけであれば問題が出るとも思えません。

いえ、正直なところiPad mini＋FileMaker Go 18（前バージョン）で読んでいたときに、突如としてフィールドが真っ白になってレコード表示がうまく動かなくなったということはありました。

それでも、iPhone＋FileMaker Go 19であれば、とくに問題らしい問題に遭遇したことはありません。RAMが少ないと環境だと問題があるのかもしれません。

とりあえず、「何かあったとき」のために……筆者に文句を送信できるよう、電子ブックに感想送信フォームをつけておきました。

個人的には、.fmp12形式のままBOOTH上で販売したいのですが、その点について提案したもののお返事をいただいていません。

macOS 12 beta6、Cocoa Scriptingの速度低下なし

Posted on 8月 31, 2021 by Takaaki Naganoya

macOS 12 beta6が出てきました。beta 5でM1 Mac上でのAppleScript実行速度低下が大幅に改善され、そのアップデート版であるbeta 6で「先祖返り」していないかを確認。beta 5と同程度か、少し高速になっている処理もあるようです（気持ち速いぐらい）。

でも油断はできません。macOS史上最悪最低のmacOS 10.13のときには、Release前には何も問題がなく順調にバグがつぶされてきたのに、Release版はBeta以下という出来でした。

あのmacOS 10.13の開発プロジェクトを思えば、Release版を見るまで結論は出せません。

追記１：
Beta 6に、NSDataDetector経由で電話番号を取得できないというバグを見つけました（レポート済み）。プログラミング言語ではなく、ユーザー環境の設定言語に依存して発生するようです。いまのところ、日本語環境で問題が発生し、英語環境では発生していません。

Numbersの書類上で選択中の範囲のセルの値をシャッフル

Posted on 8月 24, 2021 by Takaaki Naganoya

Numbersの書類上で選択中の範囲のセルの値をシャッフルするAppleScriptです。Numbers書類の表の上で節度ある範囲（テスト用なので…100個ぐらい？）のセルを選択して実行し、シャッフされたデータをNumbersに描き戻します。

＃　単なるデモScriptなので、数千とか数万個のセルを選択した場合には、CSVに書き出してNumbersでオープンし、そのデータ内容をコピペで元のNumbersに書き戻したほうが処理が速いことでしょう。

実際にmacOS 12 beta5でどの程度、処理速度が向上したかを確認するために書いてみました。

–> Watch macbookpro10,1_10.14_macminim1_12 demo

上記の画像で左がMacBookPro 10,1（Intel Core i7 2.66GHz、macOS 10.14.6）、右がMacmini9,1（Apple M1 3.2GHz、macOS 12 beta5）です。

これまで使用してきたMacBook Pro Retina 2012と現行のM1 Mac miniの速度差は気になります。macOS 11上ではM1 Mac miniのほうが10倍遅かったわけですが、最新のmacOS 12 beta5ではどうなのか。

きっちり両方とも揃えてスタートできているわけではありませんが、それでもM1のほうが２倍強ほど高速になっていることがわかります。このぐらいだと友人知人におすすめしても恨まれないレベルだと思います。

ただ、お勧めするにしてもmacOS 12の正式版が出てからですね。自分のMac App Storeに出しているアプリも、macOS 12がリリースされる前にUniversal Binary版を出すと「M1対応にしても速くなっていない」などと文句を言われそうです。

逆に、macOS 12の正式版がリリースされたら「Intel版のままなのに信じられないほど速くなった」ということになりそうです。

AppleScript名：セルの値のシャッフル.scptd

—
–　　Created by: Takaaki Naganoya
–　　Created on: 2021/08/22
—
–　　Copyright © 2021 Piyomaru Software, All Rights Reserved
—

use AppleScript version "2.7" — High Sierra (10.13) or later
use framework "Foundation"
use framework "GameplayKit"
use scripting additions

tell application "Numbers"
　　tell front document
　　　　tell active sheet
　　　　　　try
　　　　　　　　set theTable to first table whose class of selection range is range
　　　　　　on error
　　　　　　　　return –何も選択されてなかった場合は終了
　　　　　　end try
　　　　　　
　　　　　　tell theTable
　　　　　　　　set mySelectedRanges to value of every cell of selection range
　　　　　　　　set cellList to cell of selection range
　　　　　　end tell
　　　　end tell
　　end tell
end tell

–1D Array Shuffle
set anArray to current application’s NSArray’s arrayWithArray:mySelectedRanges
set randomArray to anArray’s shuffledArray() as list — requires macOS 10.12

tell application "Numbers"
　　tell front document
　　　　tell active sheet
　　　　　　tell theTable
　　　　　　　　repeat with i from 1 to (length of cellList)
　　　　　　　　　　tell item i of cellList
　　　　　　　　　　　　set value to item i of randomArray
　　　　　　　　　　end tell
　　　　　　　　end repeat
　　　　　　end tell
　　　　end tell
　　end tell
end tell

★Click Here to Open This Script　

macOS 12 beta5でAppleScript処理系の大幅なスピードアップ。M1もIntelも

Posted on 8月 18, 2021 by Takaaki Naganoya

以前から本Blogでは、M1 Mac＋macOS 11上でAppleScriptの実行、とくにCocoaの機能呼び出しが10〜77倍遅くなるという件についてレポートしてきました。

–> macOS 11, AppleScriptをFirestormではなくIcestormで実行か？！

CPUの乗り換え直後ということもあり、淡々とAppleにバグレポートしつつ、周囲には「まだM1に手を出すべきではない」と話していたものが、最新のmacOS 12 beta 5においてどの程度変わったのでしょうか？

２つのスピード低下問題

AppleScriptのコミュニティ的には「macOS 10.15をインストールするとCocoa Scriptingが遅くなる問題」（Intel Mac）があり、そのうえに「M1でAppleScriptの実行＋Cocoa Scriptingが遅くなる問題」の２つの問題を抱えていました。

macOS 10.15以降の速度低下問題は、自分がmacOS 10.15を「ダメ環境」としてパスし、M1 Macの導入にともないOSバージョンを１つ飛ばしてmacOS 11に移行したときにはじめて認識しました。

Mac App Storeに出している、AppleScriptで組んだアプリケーションの数々が、さぞやM1 Mac上で処理速度が向上して、より快適に使えるに違いない……と、ルンルンで箱を開けてテストをしだして、「遅い！！ MacBook Pro Retina 2012より遅いとはどういうこと？！」と、落胆の表情に変わるまで１日も必要ありませんでした。

とくに期待していた時間のかかる大規模データ処理が、MacBook Pro Retina 2012の10倍以上遅いという結果に言葉を失い、Appleにこれを「バグレポート」としてレポートすることになったのです。

メール.appの起動やSafariの操作など、日常的な操作の範囲では噂どおりの処理性能を発揮していたのに、AppleScriptの処理だけ遅いというのは、これはもう明らかに「異常事態」です。

ベンチマーク比較対象

身の回りにあるMacをかき集めて調べてみました。現用機でこのベンチマークに参加していないのは奥方様のMacBook Air 2015ぐらいです。

今回、青い色で指し示しているmacOS 12 beta 5環境が注目点です。M1 Mac miniおよびIntel Mac mini 2014にmacOS 12 beta 5をインストールし、速度の変化を検証しました。

結論から言うと、macOS 12 beta 5ではM1 MacでmacOS 11.xの30倍、Intel Macで10倍ぐらいCocoa Scriptingの実行が高速になっています。

これは、冒頭で説明した（１）macOS 10.15で発生した何らかの内部的なミス　（２）M1 Mac上でAppleScriptの処理系が明らかにIcestorm（電力効率のよいローパワーCPUコア）で処理されてしまっていたこと　の２つの問題が解消されたため、と推測しています。

これらの組み合わせによって、Intel MacでもM1 Macでも処理速度が大幅に向上した、という「現象」のみが確認できているだけです。

ベンチマーク１：Permutation

DNAの塩基配列「T」「C」「G」「A」のすべての順列組み合わせパターンを計算する計算（Permutation）です。桁数が多くなるとデータ量と計算量が膨大に増えるのと、Cocoa Scripting導入の有用性を示す演算内容（Vanilla AppleScriptより桁違いに高速）でもあるため、４〜８桁のPermutationを採用しました。以下、グラフ内の横軸の単位はすべて「秒」です。

Machine 4が前の開発環境（MacBook Pro Retina 2012）で、これを基準に「速い」「遅い」という比較を行っています。

アップデート前のM1 Mac mini＋macOS 11の環境はMachine 4よりもはるかに遅くて「使っていられない」状態でしたが、アップデート後の環境（Machine 1’）ではMachine 4の２倍強、アップデート前からは平均で27倍の速度向上を実現。

Intel MacでもmacOS 11から12への移行で11〜21倍程度、高速化しています。

ベンチマーク２：乱数配列の生成とソーティング

M1＋macOS 11の環境では「要素数の多い配列の操作」と「乱数の生成」（AppleScriptのrandom number）がとくに遅いという傾向が出ていたので、10万要素、20万要素、30万要素の配列でベンチマークを行いました。ただし、本ベンチマークでは乱数の生成を最速の方法で計算しているため、M1 Macで1.3倍速、Intel Macでも同程度の速度向上になっています。とくに、要素数が少ないほど速度向上の割合が増えており、これは歓迎できる傾向です。

ベンチマーク３：AppleScriptのrandom number関数を用いた乱数配列の生成とソーティング

AppleScriptのrandom number関数を用いて1〜99999999の範囲の乱数を1万回生成して配列に追加するベンチマークです。初回実施時にはこれでM1 Mac mini＋macOS 11の環境が、MacBook Air 2011＋macOS 10.13の５倍の処理時間がかかるという衝撃の数値が出た内容です。

macOS 11から12 beta 5へのアップデートに伴い、M1 Macで30倍、Intel Macでも12倍速度が向上していることを確認しています。

macOS 11の正式版がmacOS 12？

どこまでも「次世代Apple Silicon Mac用OSのβ版」という印象が強かったmacOS 11から、AppleScript＋Cocoa呼び出しについては機能の改善が行われ、macOS 10.15で失った処理速度をIntel Macでも回復できているように見えます。

自分が大規模データ処理＋演算速度の目安に用いている、「約700箇所の日本全国のゲームセンターについて、全国の鉄道駅（約8,000箇所）との距離を求め最短のものを最寄駅とし、それぞれ最寄駅までの距離が短い順にソートする」計算の結果を見てみると、

MacBook Pro Retina 2012：７分13秒
iMac Pro：４分17秒
M1 Mac mini：１分42秒

と、iMac Proを大きく上回る結果を叩き出しています。あまりに速いので、計算内容が間違っているのではないか？　とか、計算結果が出力されないのではないか？？　などと疑問に思って何度も調べてみましたが、きちんと計算されています。間違いなく、これまでに遭遇したMacの中で最も高速にAppleScriptを実行する環境といえます。この速さは、異次元のレベルです（力説）。

正直なところ、Cocoa Scripting Course本掲載のサンプルAppleScriptをM1 Mac mini＋macOS 11で動かしたときには「イヤな汗」が出まくりました。高速なCocoa Scriptingだぜキャッホー（奇声）！　などとノリノリで書いていたものが、

「残念なお知らせです。いま、Vanilla ScriptingのソートルーチンにCocoa Scriptingのソートルーチンが抜かされました」

などと書けるでしょうか？　いや、書けるわけがない（反語）。本件は、Cocoa Scripting本の続刊を書く手が止まってしまうぐらいの（よくない方向への）インパクトがありました。

かくして、そこから詳細な調査や問題傾向の炙り出しなど、表沙汰にできない調査と資料作成がはじまったわけで、一応こういう形で（いい方向に）問題が解決されて本当によかったデス。これで解決されなかったら、海外のYouTuberにチクリまくってセンセーショナルな方向で炎上させるしかない、と割と本気で思っていたほどでした。だいたい、自分にしかレポートできないのに、時間と何かを失って何も得られない膨大な作業。Appleが自分でチェックする能力がない一方で、この無償奉仕労働を強いられるのが納得できません。

macOS 12については期待が持てる内容ですが、これがいまだ現用環境であるmacOS 10.15やmacOS 11へのフィードバックが可能な内容なのか、あるいはmacOS 12の登場を待たなくてはならないのかは現時点ではわかりません。

ただ、ここ数年というもの（2020年は珍しい例外）、このぐらいの時期（８月後半）になると「またAppleの現場が無茶な仕様追加を行って開発プロジェクトが崩壊した」「Release版のひどさがいまから感じられるので、アップデート禁止」といった話題しか出ていませんでした。それが、「macOS 12には期待できる」という話ができるのは、喜ばしいことでしょう。

＃　Beta版では素晴らしかったのに、Release版で別物が壊滅的な出来でリリースされた「macOS 10.13」という悪しき前例があるので、Betaがよくても安心できない今日このごろです。「どうして10.13がああなったのか」という説明は一切ないままなので、いまひとつ信頼できません

Mac App Storeに出している各種アプリケーション（すべてAppleScriptで記述）の動作が、macOS 12 beta5上であればひじょうに高速です。

UNI detector+macOS 12 beta5 DEMO

Watch kamenoko_M1+macOS 11 DEMO

Watch Kamenoko_M1_macOS 12 beta5 DEMO

FileMaker Proに組み込んで大規模なCocoaの機能を呼び出しているAppleScriptの動作も快適になっています。

Watch M1+macOS11 MkMapView Demo

Watch M1+macOS12 beta5 MkMapView Demo

CotEditorと組み合わせて動かしている「CotEditor PowerPack v3」のAppleScriptも、macOS 12beta 5上できわめて高速に動く様子がわかります。

Watch CotEditor_M1＋macOS11 DEMO

Watch CotEditor_M1＋macOS12 beta5 DEMO

Numbers.appで選択中の範囲のセルをシャッフルするAppleScriptをmacOS 12beta5で動かしたもので、左がIntel Mac mini 2014、右がM1 Mac mini 2020です。
numbers_selection_shuffle_intel_M1_12beta5

これはAppleScriptに関する処理だけにとどまるものではないようです。Terminal.app上で動作させる各種CLI系のプログラムの動作時のCPU Coreの割り当ても変化しており、よりパフォーマンスを発揮する方向に「味付け」が変化しているように見えます。

ただ、CLIベースのプログラムについてまとまったベンチマークを行なっているわけではないため、実際に動作させている数少ない膨大な処理時間のかかるプログラム（PDF内の画像サイズ圧縮のために併用しているGhostScript）を見ている範囲で、アクティビティモニタ上のCPU各コアの動きが変わっているように見える、ということです。

CotEditorで最前面の書類の内容をすべて選択してコマンド実行

Posted on 8月 13, 2021 by Takaaki Naganoya

CotEditorでオープン中の最前面の書類の内容をすべて選択してコマンド（半角→全角　文字変換）を実行するAppleScriptです。

データ処理内容の確認のためにCotEditor上で処理したときに「あれ？　書類の内容を全選択する処理って書いたことなかったわ〜」と気づいて、慌てて書きました。

AppleScript名：最前面のドキュメント内を全選択して全角変換.scpt

tell application "CotEditor"
　　tell front document
　　　　set tLen to length
　　　　set aRange to {0, tLen}
　　　　set range of selection to aRange
　　　　change roman width selection to full
　　end tell
end tell

★Click Here to Open This Script　

M1への各種Framework移行

Posted on 7月 30, 2021 by Takaaki Naganoya

M1 Mac miniをメインマシンに変更してはや１か月ぐらい。普段のアプリケーションを利用する使い方では、ほとんどIntel Macと差がないというか、違いが分からない感じで使えています。

M1 Mac上でAppleScriptを動かすとIntel Macの10〜77倍遅いケースがままある（Cocoa Scripting時）ので、高性能マシンに乗り換えた感じはまったくしません。KeynoteとかMail.appとかSafariが速いだけの環境です。AppleScriptでバリバリにプログラムを書いているなら、iMac Proのほうが快適でしょう。Mac Proについては……三角関数の計算を間違える問題マシンとして認識しているので、まったく食指が動きません（価格的に無理ですが）。

ただ、M1 MacはCPUが熱くならないので放熱ファンで風を送らなくてよく、夏でも静かなのは助かります。

＃　macOS 12になって、Cocoa Scripting速度が大幅に改善されたので、（OSのバグや不具合はありますが）自分の使っている範囲では高速で快適です

Frameworkの移行

macOS 10.10以降、AppleScriptからオープンソース系のCocoa Frameworkが呼べるようになって、ほぼObjective-Cのコードを直接呼び出して実行できるようになって大変便利な状態になっています。Swiftで書かれたプログラムもBridging Headerを書けば呼べるらしいのですが、自分はいまひとつです。

Intel Mac環境でビルドして利用していたIntel BinaryのFrameworkを、そのまま呼び出すことはできていません。FrameworkについてはRosetta 2で翻訳されて実行できるという状況にはないので、Universal Binaryビルドを行う必要があるものと認識しています。

FrameworkのUniversalビルド

オープンソースのFrameworkのXcodeプロジェクトをそのまま手元に置いてあったので、Xcode 12でオープンしてビルドして、そのままAppleScriptから呼び出して実行できるものもありました。

「これなら問題なくいけるかも？」

……ある意味Yesともいえるし、Noともいえる状況です。

HTMLReader.frameworkあたりはほぼ何も考えずにUniversal Binaryビルドできました。これがないととても困るので助かります。

Intel MacとM1 Macではハードウェアの構成が違うので、そうしたIntel Macのハードウェアを前提としているものはもう、まるっきり動きません。オーディオ出力先のデバイスを変更するものは、まるっきりダメ。各種センサー類から情報を取得するもの（SMCkit）もダメでした。

macOS内蔵Frameworkでも互換性がないものも

Private Frameworkになりますが、ServerInformation.frameworkの中に入っている各種ハードウェアの名称テキストが、M1 Macについては入っていなかったりで。Intel Macとまるっきり同じ情報が入っているわけではないというのが意外でした。

macOSのバージョン間の違いによる「差」

これはFrameworkまわりの話ではありませんが、M1への移行は最新のmacOSへの移行でもあります。新しいという言葉から「改良されている」「よくなっている」と無条件に思ってしまいがちですが、「なくなっている機能がある」「削られた機能がある」という側面も無視できません。

macOSのバージョンが違えば、その構成ファイルも変わっています。とくに、Menu Extrasの構成が大きく変わっており、身近なところではScript MenuがmacOS 10.14でMenu Extrasから独立した小型アプリケーションに置き換わったりもしています。これがScript Menuだけでなく他のMenu Extrasでも同様の動きが起きており、どんどんその数が減少しています。

Menu Extrasの中の実行ファイルを呼び出しているようなScriptは、M1 MacつまりmacOS 11.x環境に持って行ったときに動かなくなります。ファイルそのものが存在していないので「当然」ではあります。

Macの製品名を求める（M1以降対応）v1a

Posted on 7月 29, 2021 by Takaaki Naganoya

実行中のMacの製品名を求めるAppleScriptです。もともと、AppleScriptで作成して使用しているアイデアプロセッサ「Kamenoko」で行っている処理なのですが、

M1上で実行すると、製品名は間違えるわ、仕様は合っていないわで散々でした。あ、マシンのアイコンは取ってきていますね。その他のデータはマシン移行をしたときにそのまま前のマシンのデータが残っていたためでしょう。

調べてみると、M1 Macでは従来どおりの製品名データを持っていないようで、Intel Macでは取得できていた製品の名前をわかりやすく記述するデータがありません。各国語にローカライズされていて便利だったのですが。

そこで、M1 MacかどうかのCPUタイプ検出を行い、そのうえで処理を分けることにしました。動作原理上、購入してセットアップしたてのマシンでこのファイルが存在しているかどうか、検証が必要だと思います。

AppleScript名：Macの製品名を求める（M1以降対応）v1a.scpt

—
–　　Created by: Takaaki Naganoya
–　　Created on: 2021/07/28
—
–　　Copyright © 2021 Piyomaru Software, All Rights Reserved
—
use AppleScript version "2.7" — macOS 10.13 or later
use framework "Foundation"
use scripting additions

set hRes to retModelName() of me
–> "Mac mini (M1, 2020)"–macOS 11.5
–> "Mac mini Intelデュアルコアプロセッサおよび統合型グラフィックス搭載、2014年後期に投入。"–macOS 12beta
–> "15インチMacBook Pro, Retinaディスプレイ, Intel Core i7 (Mid 2012)"–macOS 10.14.6

on retModelName()
　　set cRes to CPU type of (system info)
　　
　　if cRes begins with "ARM" then
　　　　–Apple Silicon Mac
　　　　set sText to "defaults read ~/Library/Preferences/com.apple.SystemProfiler.plist" & " ’CPU Names’ | cut -sd ’＼"’ -f 4"
　　　　set hRes to do shell script sText
　　　　return hRes
　　else if cRes begins with "Intel" then
　　　　–Intel Mac
　　　　set hRes to retModelInfo() of me
　　　　return hRes
　　end if
end retModelName

on retModelInfo()
　　tell application "System Events"
　　　　set osVersion to system version of (system info)
　　end tell
　　— macOS 10.15.3 –> 15
　　
　　considering numeric strings
　　　　if osVersion ≥ "10.15" then
　　　　　　–macOS 11.0以降
　　　　　　set pListPath to "/System/Library/PrivateFrameworks/ServerInformation.framework/" & "Versions/A/Resources/ja.lproj/SIMachineAttributes.plist"
　　　　else if osVersion > "10.14" then
　　　　　　–macOS 10.14まで
　　　　　　set pListPath to "/System/Library/PrivateFrameworks/ServerInformation.framework/" & "Versions/A/Resources/Japanese.lproj/SIMachineAttributes.plist"
　　　　end if
　　end considering
　　
　　set aRec to retDictFromPlist(pListPath) of me
　　set hwName to (do shell script "sysctl -n hw.model")
　　set aMachineRec to retRecordByLabel(aRec, hwName) of me
　　set aMachineRec2 to first item of aMachineRec
　　return |description| of _LOCALIZABLE_ of aMachineRec2
end retModelInfo

on retDictFromPlist(aPath)
　　set thePath to current application’s NSString’s stringWithString:aPath
　　set thePath to thePath’s stringByExpandingTildeInPath()
　　set theDict to current application’s NSDictionary’s dictionaryWithContentsOfFile:thePath
　　return theDict as record
end retDictFromPlist

on retRecordByLabel(aRec as record, aKey as string)
　　set aDic to current application’s NSDictionary’s dictionaryWithDictionary:aRec
　　set aVal to aDic’s valueForKey:aKey
　　return aVal as list
end retRecordByLabel

on retRecordByKeyPath(aRec as record, aKey as string)
　　set aDic to current application’s NSDictionary’s dictionaryWithDictionary:aRec
　　set aVal to aDic’s valueForKeyPath:aKey
　　return aVal
end retRecordByKeyPath

–1D Listを文字列長でソート v2
on sort1DListByStringLength(aList as list, sortOrder as boolean)
　　set aArray to current application’s NSArray’s arrayWithArray:aList
　　set desc1 to current application’s NSSortDescriptor’s sortDescriptorWithKey:"length" ascending:sortOrder
　　set desc2 to current application’s NSSortDescriptor’s sortDescriptorWithKey:"self" ascending:true selector:"localizedCaseInsensitiveCompare:"
　　set bArray to aArray’s sortedArrayUsingDescriptors:{desc1, desc2}
　　return bArray as anything
end sort1DListByStringLength

★Click Here to Open This Script　

targetが重複しているFinder Windowをクローズする

Posted on 7月 22, 2021 by Takaaki Naganoya

日常的に生じている不満を解消するための、ちょっとしたかき捨てScript……になるはずだったものです。

Classic Mac OSからMac OS Xへの移行後、Finderの仕様で大きく変わった点が１つあります。「同じフォルダのウィンドウを複数枚オープンできるようになった」点です。

その結果、

といったように、同じフォルダを指し示すウィンドウが何枚もたまる現象が起きています。これは別にバグでも不具合でもありません。仕様です。

この重複Windowを掃除するためのScriptを書いてみました。

AppleScript名：ターゲットが同じWindowを取得（未遂）.scpt

tell application "Finder"
　　tell window 1
　　　　set aTarg to target
　　end tell
　　
　　set wList to every window whose target　 is equal to aTarg
end tell

★Click Here to Open This Script　

何も考えずに書き始めると、こんな（↑）感じでしょう。ただ、このScriptは動きません。フィルター参照は、たとえばファイル名や拡張子、ファイル種別（kind）あたりには使えるものの、この「target」属性に対しては効きません。

そこで、仕方なくちょっと腰をすえて書いてみました。これ（↓）を動かすと、

のように重複ウィンドウが一掃されます。これでいいはずです。

AppleScript名：targetが重複しているFinder Windowをクローズする.scpt

set clList to {}

tell application "Finder"
　　set wList to every window
　　–> {Finder window id 1775 of application "Finder", Finder window id 1612 of application "Finder", Finder window id 1740 of application "Finder", Finder window id 1641 of application "Finder", Finder window id 1630 of application "Finder", Finder window id 1618 of application "Finder", Finder window id 1599 of application "Finder", Finder window id 1592 of application "Finder", Finder window id 1586 of application "Finder", Finder window id 1580 of application "Finder", Finder window id 1575 of application "Finder", Finder window id 1569 of application "Finder", Finder window id 1563 of application "Finder"}
　　
　　set tList to (target of every window) as alias list
　　–> {alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Documents:AppleScript 12.0:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:", alias "Macintosh HD:Users:me:Public:ドロップボックス:"}
　　
　　–ターゲットフォルダをユニーク化
　　set bList to removeDuplicates(tList) of me
　　–> {alias "Macintosh HD:Users:me:Documents:AppleScript 12.0:", alias "Macintosh HD:Users:me:Public:ドロップボックス:"}
　　
　　–ユニーク化したターゲットでループ
　　repeat with i in bList
　　　　set j to (contents of i) as alias
　　　　set firstF to true
　　　　
　　　　–ウィンドウでループ
　　　　repeat with ii in wList
　　　　　　set jj to contents of ii
　　　　　　set tmpTarg to (target of jj) as alias
　　　　　　
　　　　　　if tmpTarg is equal to j then
　　　　　　　　–最初の１つ目のWindowだけ残す
　　　　　　　　if firstF = true then
　　　　　　　　　　set firstF to false
　　　　　　　　else
　　　　　　　　　　–２個目以降のWindowはクローズ対象リストに入れる
　　　　　　　　　　set the end of clList to jj
　　　　　　　　end if
　　　　　　end if
　　　　end repeat
　　end repeat
　　
　　–クローズ対象とされるFinder Windowを順次クローズ
　　repeat with i in clList
　　　　set j to contents of i
　　　　try
　　　　　　ignoring application responses
　　　　　　　　close j
　　　　　　end ignoring
　　　　end try
　　end repeat
end tell

on removeDuplicates(aList)
　　set newList to {}
　　repeat with i from 1 to (length of aList)
　　　　set anItem to item 1 of aList
　　　　set aList to rest of aList
　　　　if {anItem} is not in aList then set end of newList to anItem
　　end repeat
　　return newList
end removeDuplicates

★Click Here to Open This Script　

edama2さんがコメント欄に投稿してくださったプログラムを掲載しておきます。自分が「安全のためにこのぐらいの処理は必要（かも？）」と付けまくった処理を「それ別に実際のところ必要ないんじゃない？」と省略された感じです。

あとは、edama2さんのScriptだと「最前面のWindowのtargetと同じtargetを持つWindowをクローズする」という動作ですが、自分のScriptは「targetが重複しているWindowは１つを残してあとすべてをクローズする」という動作を行うので、厳密にいえば違うものです。

AppleScript名：targetが重複しているFinder Windowをクローズする v2.scpt

–　　Created by: edama2
–　　Created on: 2021/07/22

tell application "Finder"
　　tell front window
　　　　set aTarg to target
　　end tell
　　set aList to (every Finder window) as list
　　repeat with num from 2 to count aList
　　　　set anItem to (aList)’s item num
　　　　if (anItem’s target is aTarg) then close anItem
　　end repeat
end tell

★Click Here to Open This Script　

NSString’s stringWithFormat:がクラッシュするバグが修正された

Posted on 7月 18, 2021 by Takaaki Naganoya

macOS 11で発生していた「NSString’s stringWithFormat:」をAppleScriptから呼び出すとクラッシュするというバグが、最新のmacOS 11.5BetaおよびmacOS 12.0Betaで修正されていることを確認しました。
→ macOS 11.5正式版がリリースされ、修正されていることを確認。逆にいえば、AppleScriptでCocoa Scriptingを用いて作ったプログラムは、macOS 11.0〜11.4の環境を動作条件から外す（動作要求条件を11.5以上にする）必要があるということです。

クラッシュしなくなりましたね。問題点について、気がついたらレポートして念押しして、修正内容を確認するという地道な作業の繰り返し、積み重ねで世界の平和が維持されているのでありました。

▲Uni Detector v1.2.1もNSString’s stringWithFormat:メソッドがクラッシュしなくなったおかげで、ちゃんとCPUアーキテクチャごとの構成比率グラフを実行してもアプリケーションごとクラッシュしなくなりました

Shortcuts Events

Posted on 6月 9, 2021 by Takaaki Naganoya

macOS 12で搭載される「ショートカット」は、iOS上の自動化ツール「DeskConnect」をAppleが買収して発展させ、Apple純正ソフトウェアとして提供されているものです。簡単な自動化を行うためのツールです。

このショートカットがmacOS 12に搭載されることがKeynoteで発表されました。さらに、ショートカットからAppleScriptが実行できることが明らかにされ、AppleScriptからもショートカットを実行できるとのこと。

タイトルにも挙げている「Shortcuts Events」が、AppleScript専用のGUIなし補助アプリケーションであり、AppleScript側からショートカットのアクションを呼び出すことができるようです。

ただし、最初のmacOS 12β版ではまだAppleScriptからショートカットのアクションを実行できないことが、Release NotesのKnown Issuesに明記されています。

	10.4	10.5	10.6	10.7	10.8	10.9	10.10	10.11	10.12	10.13	10.14	10.15	11.0	12.0
Shortcuts Events														⬛︎
ColorSyncScripting	⬛︎	⬛︎
Database Events	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎
Digital Hub Scripting	⬛︎	⬛︎
FontSync Scripting	⬛︎	⬛︎
Image Events	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	★	★	★
Keychain Scripting	⬛︎	⬛︎	⬛︎
System Events	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎	⬛︎
URL Access Scripting	⬛︎	⬛︎	⬛︎

WWDC21でShortcuts for Macが発表に

Posted on 6月 8, 2021 by Takaaki Naganoya

WWDC21にて、macOS 12にShortcuts for Macが搭載されることが発表されました。同ツールはAutomatorを置き換え、iPhoneやiPad上のShortcutsとは異なるクリエイティブ系に寄せたアクションが実行できるとのこと。

Shortcuts内からもAppleScriptやShell Scriptを呼び出せるようになっており、Mac上でSiriからShortcutsの呼び出しが行える＝「Siriから（ShortcutsのAction上に記載した）AppleScriptが実行できるようになった」ことを意味しています。

Automatorの今後については、すでにAppleScript Studioランタイムがdeprecated扱いで、機能の追加は行われません。Xcode上に添付されているAutomator Acrtionのテンプレートも、すでにAppleScript Studioではなく「Cocoa AppleScript」（AppleScriptObjC）です。