macOS 15.2betaにおいて「写真.app」のバージョン番号が「10.0」ではなく「1.0」になっていた件、本日配信されたmacOS 15.2beta(24C5089c)において「10.0」に修正されていました。
カテゴリー: Bug
スクリプトエディタでFinderやスクリプトエディタ自身のAppleScript用語辞書をブラウズできない問題、解決か?
macOS 15.2 Beta(24C5079e)において、以前本BlogでレポートしていたスクリプトエディタでFinderやスクリプトエディタ自身のAppleScript用語辞書をオープンできない問題が解消されていることを確認しました。
ただし、本問題は再発する可能性が高いものと見ています。電子書籍「AppleScript最新リファレンス v2.8対応」のmacOS 15向けの改修を行なっていますが、
「macOS 15でFinderのAppleScript用語辞書を閲覧できない件」についての対処方法の追加記事が無駄になったことは、喜ばしいことなのでしょうか。きっと、再現して必要になるのでは? と思っているものです。
スクリプトエディタのコンテクストメニューに、絵文字を使ったファイル名のAppleScriptやフォルダが複数回表示されるバグの場合にも、Betaで修正を知らされてもRelease版では直っていなかったため、複数プロジェクト間で矛盾した設定や処理が行われていること自体が解消されてこなかったのでしょう。
Appleの会社組織が極度に縦割り化されているため、チーム間の連携とかチーム間にまたがる問題がいっこうに解決されないといった問題が発生しており、Aチームで修正を行っても他のBチームやCチームでは以前どおりの処理を行なってAチームの修正が無駄になるといった話を散々目撃してきました。
Apple、macOS標準搭載アプリ「写真」のバージョン表記を間違える
macOS 15.2betaにおいて、macOS標準搭載アプリ「写真」(Photos.app)の表示用バージョン番号が誤って「1.0」と記載されています。macOS 15 Betaの段階では「10.0」と記載されていたので、Release後にバージョン番号がおかしくなったのでしょう。
実際にAppleScriptからバージョンを求めても、”1.0″が返ってきます。
AppleScript名:macOS 15.2betaでPhotosのバージョンを間違っている検証 |
tell application "Photos" version –> "1.0" end tell system version of (system info) –> "15.2" |
なお、これまでの写真.appのバージョン履歴は以下のようになっています。
macOS上のアプリのバージョン記述ミスについては、これまでにも何度か発生しており、有名なところではmacOS 13上の「連絡先」(Contacts)がバージョン2539といった謎表記になっていることが知られています(おそらくこれはビルドNo.で、バージョン記述するのを忘れたままになっていたのでしょう)。
自社アプリがApp Storeの審査を通れないのでは? それ以前に、バージョン管理してるんでしょうか????
ステータスメニューからアプリ本体を最前面に(改)
GUIアプリを作ったときに、ステータスメニュー上に置いたアイコン>メニューからアプリ本体のウィンドウをアクティブにできないという問題が発生しています。
macOS 13、14、15とずーーっとこの動作なので、全世界的に困らされている状況があって……久しぶりにXcodeでGUIアプリをAppleScriptで作って、この問題に例外なく自分も悩まされていました。
その解決を行ったAppleScriptプロジェクトです。macOS 13.7.1上でXcode 15.2で試しています。
# 本記事投稿後にプログラムの見直しを行い、掲載リストおよびXcodeプロジェクトの差し替えを行いました。
GUIアプリ内から生成したステータスバー上のステータスアイテム。ステータスアイテムからメニュー表示。表示されたメニューから項目選択でメインウィンドウを最前面に表示する。
tell current application to activate
では何も起こりません(macOS 12まではこれで大丈夫だった)。
そういう操作を行なってもメインウィンドウが最前面に表示されず、メインウィンドウを強制的にアクティブにするようなコードを入れても、「UIがないプロセスから他のプロセスをアクティブにできない」といったワーニングが表示されるだけで、何も起こりません。
メチャクチャ困ります。
そこで、edama2さんに相談していろいろ試してみたところ、強制的にGUIアプリを最前面に持っていけました。
こちらの議論を参考にしています。
on activateMe:aSender
theWindow's makeKeyAndOrderFront:(me)
theWindow's orderFrontRegardless()
end activateMe:
当初、ウィンドウの生成を動的に行なっていましたが、その部分を削除しても動作することを確認できたため、削除しています。
なお、macOS 15.2+Xcode 16.1でビルドして実行してみたら、「tell current application to activate」だけでウィンドウを最前面に持っていけています。ここで紹介している処理は、macOS 13、14で同様の処理ができるように必要になってしまうようです。
macOS 13/14(+15.0〜15.1?)のバグと言って差し支えないでしょう。
AppleScript名:AppDelegate.applescript |
— — AppDelegate.applescript — process Control test — — Created by Takaaki Naganoya2 on 2024/11/01. — — script AppDelegate property parent : class "NSObject" — IBOutlets property theWindow : missing value property NSMenu : a reference to current application’s NSMenu property NSMenuItem : a reference to current application’s NSMenuItem property NSStatusBar : a reference to current application’s NSStatusBar property NSVariableStatusItemLength : a reference to current application’s NSVariableStatusItemLength on applicationWillFinishLaunching:aNotification my initMenu:me end applicationWillFinishLaunching: on applicationShouldTerminate:sender return current application’s NSTerminateNow end applicationShouldTerminate: on clicked:aSender my activateMe:(me) set aTag to (tag of aSender) as integer –Important!! set aTitle to (title of aSender) as string if aTag is in {41, 42, 43, 44, 45, 46} then my activateMe:aSender else if aTag = 100 then display dialog "Clicked" end if if aTitle = "Quit" then quit end clicked: on activateMe:aSender current application’s NSApp’s activateIgnoringOtherApps:(true) theWindow’s makeKeyAndOrderFront:(me) theWindow’s orderFrontRegardless() end activateMe: –Status Menu Structure on initMenu:aSender set aList to {"Piyomaru", "Software", "", "Function", {"1", "2", "3", "4", "5"}, "", "Quit"} set aStatusItem to current application’s NSStatusBar’s systemStatusBar()’s statusItemWithLength:(current application’s NSVariableStatusItemLength) aStatusItem’s setTitle:" TEST " aStatusItem’s setHighlightMode:true aStatusItem’s setMenu:(createMenu(aList) of me) end initMenu: on createMenu(aList) set aMenu to current application’s NSMenu’s alloc()’s init() set aCount to 10 set prevMenuItem to "" repeat with i in aList set j to contents of i set aClass to (class of j) as string if j is equal to "" then set aMenuItem to (current application’s NSMenuItem’s separatorItem()) (aMenu’s addItem:aMenuItem) else if (aClass = "text") or (aClass = "string") then if j = "Quit" then set aMenuItem to (current application’s NSMenuItem’s alloc()’s initWithTitle:j action:"clicked:" keyEquivalent:"") else set aMenuItem to (current application’s NSMenuItem’s alloc()’s initWithTitle:j action:"clicked:" keyEquivalent:"") end if (aMenuItem’s setTag:aCount) (aMenuItem’s setTarget:me) (aMenu’s addItem:aMenuItem) set aCount to aCount + 10 copy aMenuItem to prevMenuItem else if aClass = "list" then –Generate Submenu set subMenu to current application’s NSMenu’s new() (aMenuItem’s setSubmenu:subMenu) set subCounter to 1 repeat with ii in j set jj to contents of ii set subMenuItem1 to (current application’s NSMenuItem’s alloc()’s initWithTitle:jj action:"clicked:" keyEquivalent:"") (subMenuItem1’s setTarget:me) (subMenuItem1’s setTag:(aCount + subCounter)) (subMenu’s addItem:subMenuItem1) set subCounter to subCounter + 1 end repeat end if end if end repeat return aMenu end createMenu end script |
macOS 15:スクリプトエディタのAppleScript用語辞書を確認できない
macOS 15になって、起動中のアプリ自身が自分のバンドル内のリソースにファイルアクセスできなくなったためか(仮説)、スクリプトエディタで自身のAppleScript用語辞書を確認できていません(macOS 15.1)。
用語辞書を読まずにAppleScriptを書くことはできないので、従来のmacOS 13や14から比べると「困った改変」です。
一応、Script Debuggerを用いてスクリプトエディタのAppleScript用語辞書をブラウズすることは可能であるため、不可能になったわけではないのですが、スクリプトエディタで用語辞書をオープンできないと、辞書内容をファイル保存して、変更点の差分を検出できなくて(私が)困っています。
スクリプトエディタのAppleScript用語辞書は、バンドル内にsdefの形式で格納されなくなったため(.scriptsuites書類?)バンドルの中身を開けてコピーというFinderのような解決策をとることができません。
PostScript名で指定したフォントのウェイトを上げるループ処理のテスト
NSFontManagerを用いて、指定フォントのウェイト(太さ)を上げたり下げたりする処理ができますが、実際にやってみると「見えなかったもの」が見えてきます。
macOSには「ヒラギノ角ゴシック」のW0(PostScript名:HiraginoSans-W0)からW9(PostScript名:HiraginoSans-W9)まで異なるウェイトのフォントがインストールされています。そこで、W0から順次W9までウェイトを上げる処理を行なってみると、「ヒラギノ角ゴシックW2」にウェイトが割り振られていないことがわかります。
バグなのか、意図的なものなのか……多分バグだと思うのですが……。
AppleScript名:PostScript名で指定のフォントのウェイトを上げるループ.scptd |
— – Created by: Takaaki Naganoya – Created on: 2024/10/19 — – Copyright © 2024 Piyomaru Software, All Rights Reserved — use AppleScript version "2.4" — Yosemite (10.10) or later use framework "Foundation" use framework "AppKit" use scripting additions property NSFont : a reference to current application’s NSFont property NSFontManager : a reference to current application’s NSFontManager set aName to "HiraginoSans-W0" set aFont to current application’s NSFont’s fontWithName:aName |size|:9.0 –> (NSCTFont) "HiraginoSans-W0 9.00 pt. P [] (0x12870af00) fobj=0x11b1e90d0, spc=1.98" set fontM to current application’s NSFontManager’s sharedFontManager() set fRes to fontM’s weightOfFont:(aFont) –> 2 repeat 12 times set fRes to fontM’s weightOfFont:(aFont) log (fRes as number) set aFontName to aFont’s fontName() log aFontName (*2*) (*(NSString) "HiraginoSans-W0"*) (*3*) (*(NSString) "HiraginoSans-W1"*) — <– W2は????? (*4*) (*(NSString) "HiraginoSans-W3"*) (*5*) (*(NSString) "HiraginoSans-W4"*) (*6*) (*(NSString) "HiraginoSans-W5"*) (*8*) (*(NSString) "HiraginoSans-W6"*) (*9*) (*(NSString) "HiraginoSans-W7"*) (*10*) (*(NSString) "HiraginoSans-W8"*) (*12*) (*(NSString) "HiraginoSans-W9"*) set aFont to fontM’s convertWeight:true ofFont:aFont end repeat |
ヒラギノ角ゴシックW2のウェイトを取得したら3が返ってきました。ウェイトがW2とW3で重なっているんですね。
AppleScript名:PostScript名で指定のフォントのウェイトを取得.scptd |
— – Created by: Takaaki Naganoya – Created on: 2024/10/19 — – Copyright © 2024 Piyomaru Software, All Rights Reserved — use AppleScript version "2.4" — Yosemite (10.10) or later use framework "Foundation" use framework "AppKit" use scripting additions property NSFont : a reference to current application’s NSFont property NSFontManager : a reference to current application’s NSFontManager set aName to "HiraginoSans-W2" set aFont to current application’s NSFont’s fontWithName:aName |size|:9.0 –> (NSCTFont) "HiraginoSans-W0 9.00 pt. P [] (0x12870af00) fobj=0x11b1e90d0, spc=1.98" set fontM to current application’s NSFontManager’s sharedFontManager() set fRes to fontM’s weightOfFont:(aFont) –> 3 |
macOS 15:スクリプトエディタでFinderのAppleScript用語辞書が閲覧できない
Betaのときには起こっていなかった現象で、macOS 15.1で確認されています。
スクリプトエディタでFinderのAppleScript用語辞書を閲覧できません。
Finderは/System/Library/CoreServicesフォルダに入っており、このフォルダへのアクセスが「より厳しく」なったのでしょう。
ただ、実際にFinderがAppleScript対応しなくなったわけでもなければ、FinderのSDEFが除去されたわけでもありません。
実際にFinderの(パッケージ内容をコンテクストメニューから表示させたうえで)SDEFをコピーして、コピーしたものをスクリプトエディタで閲覧するとよいでしょう。
macOS 15 リモートApple Eventsにバグ?
macOS 13.7.1が動作中のMac mini M1から、LAN経由でmacOS 15.1が動いているM2 MacBook AirのFinderにRemote Apple Eventsで操作を行なってみたら、M2 Air(macOS 15.1)側のFinderがクラッシュするという症状に直面しています。
同じ操作をM2 Air側からM1 Mac miniに対して実行すると、問題なく結果が返ってきます。
バグ?
▲M1 Mac mini上で書いたAppleScript。コンパイル(構文確認)を行おうとすると、ユーザー認証までは進むものの、直後にmacOS 15環境側のFinderがクラッシュする
有害ではなくなっていたSpaces
Spacesは、macOS標準搭載の仮想デスクトップ機能であり、最大16個の仮想デスクトップを作れるようになっているほか、F3キーを押すと縮小表示を行うようになっているなど、ハード/ソフトともによく統合された機能です。
ただし、AppleScriptユーザー側からすると
「他の仮想デスクトップにアプリのウィンドウを置くとAppleScriptからアクセスできないカス機能」
「開発チームが他の機能のことを考慮していないクズ機能」
といった感想になります。
このため、さまざまな書籍で「AppleScriptとの互換性のない機能」のひとつとしてリストアップされ、AppleScript系の開発/運用現場では「安全のためにSpacesを使わないように」と注意するのが真っ先に行う恒例行事になっていました。
内蔵HDD/SSDの暗号化機能なみに、登場時にAppleScriptとの互換性検証が不十分なものについては「信用できない」として、以来、安全のために暗号化機能は極力使わないようにしてきました。
# HDDの暗号化機能が登場したときに、暗号化したHDDにAppleScriptからアクセスできないというバカみたいな不具合が発生。その後も、有効にするとeGPUが使えなくなるなど、この機能を作っている担当者だかチームのことが信じられません。
そして話はSpacesに戻ります。執筆中の電子書籍「Pages+AppleScriptで本をつくろう!」の注意点でSpacesについて言及し、確認のために「やっぱり今でも動かないのか?」と、試してみたら……他の仮想デスクトップ上に配置したPagesの書類の情報を取得できます。
「…………。」
何度試してみても、他の仮想デスクトップに配置したPages書類の情報を取得できます。
macOS 13.7.1と、macOS 10.13.7で試してみたところ、両方で動作しました。
このぐらいの範囲のmacOSで動くのであれば、さまざまな本でSpacesに関する「危険なので使用を推奨しない」という評価は取り下げる必要があることでしょう。
ただ、Pagesについては表示中のページから+6ページぐらいを超えるとオブジェクトのposition属性を取得できないといった不具合があり、これはmacOS 15で再テストしても発生が確認されています。
Script DebuggerがmacOS 15.x上で起動せず→起動
Script DebuggerがmacOS 15上で起動しない状況が続いています。
日本語ユーザー環境、英語ユーザー環境にかかわらずmacOS 15/macOS 15.1上でScript Debuggerが起動しません。
ちなみに、macOS 14.7ではユーザーディレクトリ下のFrameworkを実行できない問題も発生しており、macOS 14/15を信用せずにメイン環境をmacOS 13.7のままにとどめていますが、この判断が大正解のようです。
続報:
rm ~/Library/Preferences/.2xbG4@@Ght01%!020#u
rm ~/Library/Preferences/.2xbZ4@@Ght01%!010#u
rm ~/Library/Application\ Support/.1@xX4D@yyt02"!2&0#a
rm ~/Library/Application\ Support/.1@xX4D@yytT2"!2&1#a
とすることで、macOS 15.x上でもScript Debuggerが起動できました。実際には、Terminal上でこれをそのまま実行しても削除できなかったので、当該フォルダに移動してTerminal上でファイルを確認したうえで削除しました。
SDが起動できないと、Framework呼び出しを行なっているAppleScriptの実行や書き出しに支障が出るため、実に困ります。
ただ、SDのアップデートやメンテナンスが数少ない開発者によって支えられている以上、代替策も用意しておきたいところです。
Finderのfileのkind(種類)の日本語ローカライズ内容がmacOS 14以降で変更されている件(続報)
FinderやSystem Eventsで扱っているファイルの種別(kind)属性情報が、macOS 14以降で変更になっていて困っている件、その後の続報です。
おそらく、多言語ローカライズを行なっている下請け業者(いろんなメーカーのローカライズを担当している多言語ローカライザー企業)へのApple側からの指示内容に何か変化があって、不必要な部分までローカライズ内容の統一(≒修正)が行われてしまったのだろう、と見立てていました。
実際に身の回りのマシンで調査したところ、おおよそその見立てで間違っていないようです。
もとになっている英語版の表記については割と一貫性があって、コロコロ方針が変わっているようには見えません。
しかし、日本語ローカライズされた属性値については不可解というか「これを指示した人間の知性を疑う」という変わりっぷりであり、そこまで想定していなかったUS Apple側の指示内容がいいかげんだった、という想像を裏付けるものとなっています。
ローカライズにおいては変更しても意味がないし、変更することで悪影響が出る部分もあるわけですが、そこまで細かくチェックしていないということなんでしょう。
Script Debugger v8.0.8 ホームディレクトリ以下のFrameworkを実行できない障害が発生
# 訂正:Script Debugger自体を再起動したら動くようになりました。何をやってもmissing valueしか返らなくなってビビりました。
ユーザーディレクトリ下のCocoa FrameworkをロードしてAppleScriptから実行可能なScript DebuggerおよびそのEnhancesd Applet。最新版のv8.0.8で、ホームディレクトリ下に配置したこれらCocoa Frameworkの実行ができないことを確認しています。
ちょっと凝ったAppleScriptでバンドル内にFrameworkを入れて呼び出しているものについては、目下実行できない状況にあります。自分が確認したのはmacOS 14.7環境。呼び出したはいいものの結果にmissing valueが返ってきて、首をひねっていたところ、原因がScript Debuggerにあることを確認。
自分でビルドした野良Cocoa Frameworkや、Bridge Plusの内蔵Frameworkまで、みんな呼び出せない状況です(日本語ユーザー環境)。
画像の余白トリミングから2D Arrayの高速ソーティングなど、Framework呼び出しは日常的なAppleScriptの実行に欠かせないものです。
Pixelmator Pro v3.6.4でAppleScriptからの操作時の挙動に違和感が
Pixelmator Proでたまに実行する「1024×1024の画像からアイコン用の各種解像度の画像を作成する」AppleScriptですが、Pixelmator Pro v3.6.4で久しぶりに動かしたら、エラーが出てうまく動かなくなっていました。
このAppleScriptは、1024×1024の画像をオープンした状態で実行するものです。
すぐに、各サイズにリサイズしつつ、ファイル名に解像度を反映させた状態で書き出しを行います。
AppleScript名:アイコン書き出しv2.scptd |
— – Created by: Takaaki Naganoya – Created on: 2020/10/19 — – Copyright © 2020 Piyomaru Software, All Rights Reserved — use AppleScript version "2.4" — Yosemite (10.10) or later use framework "Foundation" use scripting additions set resolList to {1024, 512, 256, 128, 64, 32, 16} set aTargFileBase to (choose file name with prompt "Select Export base name") as string tell application "Pixelmator Pro" if (exists of document 1) = false then display dialog "There is no document" buttons {"OK"} default button 1 with icon 1 return end if tell front document set aWidth to width set aHeight to height if {aWidth, aHeight} is not equal to {1024.0, 1024.0} then display dialog "Wrong Image Size (1024×1024 required)" buttons {"OK"} default button 1 with icon 2 with title "Size Error" return end if repeat with i in resolList resize image width i height i resolution 72 algorithm bilinear export to file (aTargFileBase & "_" & (i as string) & "x" & (i as string) & ".png") as PNG undo end repeat end tell end tell |
これが、macOS 13.6.8+Pixelmator Pro v3.6.4の組み合わせで実行したらエラーが出て実行できなくなっていました。
問題点は割と明らかです。documentへのtellブロック内で、documentをパラメータとして要求するexportといったコマンドを実行したときに、tellブロックを認識せず、コマンドの直後にdocumentオブジェクトを表記しないとエラーになります。
解決策は、tellブロックでdocumentを指定するのをやめて、コマンドのパラメータとしてfront documentといったオブジェクトを表記することです。または、「属性値 of it」のようにdocumentへの参照を記述しておくことです(他の言語のユーザーが腰を抜かすので、なるべくitは使わないで記述していますが……)。
これで解決できるものの、macOS側で問題を起こしているのか、Pixelmator Pro側で問題を起こしているのかがわかりにくいところ。
おそらく、Pixelmator Pro側の問題かと思われますが、言い切ることもできないでしょう。
AppleScript名:アイコン書き出しv3.scptd |
— – Created by: Takaaki Naganoya – Created on: 2020/10/19 – Modified on: 2024/07/11 — – Copyright © 2020-2024 Piyomaru Software, All Rights Reserved — use AppleScript version "2.4" — Yosemite (10.10) or later use framework "Foundation" use scripting additions set resolList to {1024, 512, 256, 128, 64, 32, 16} set aTargFileBase to (choose file name with prompt "Select Export base name") as string tell application "Pixelmator Pro" if (exists of document 1) = false then display dialog "There is no document" buttons {"OK"} default button 1 with icon 1 return end if tell the front document set aWidth to width set aHeight to height end tell if {aWidth, aHeight} is not equal to {1024.0, 1024.0} then display dialog "Wrong Image Size (1024×1024 required)" buttons {"OK"} default button 1 with icon 2 with title "Size Error" return end if repeat with i in resolList resize image front document width i height i resolution 72 algorithm bilinear export front document to file (aTargFileBase & "_" & (i as string) & "x" & (i as string) & ".png") as PNG undo end repeat end tell |
macOS 14.xでAppleScriptのバグ
Hi @Apple,
just a quick note on a serious #Sonoma #bug.
get " " as integer
(this line crashes)Can someone please address this at the right spot?
(@applescripter, @applescriptguru, @applescript, @AppleScriptive, @Applescrip52206, @AppleS31305, @AppleScript12, @AppleScripter_)
— Torben Johannson (@BunterLotentony) May 24, 2024
空白文字をintegerにcastすると、処理系ごとクラッシュするというバグです。macOS 13.xではエラーになります(通常の動作)。
macOS 14.5ではクラッシュ(スクリプトエディタ上で動かせばスクリプトエディタがクラッシュ)します。
ほかにもいろいろあるんですけど(ーー;;;;;
macOS 14.xでScript Menuの実行速度が大幅に下がるバグ
基礎的なテストを行うために、コンスタントに時間がかかる処理でおなじみのPermutation(1次元配列の順列組み合わせ計算)をためしてみたところ、外部のアプリを操作しない処理内容にもかかわらず、この段階で8倍程度の時間がかかりました。外部アプリの操作を行うと、より一層時間がかかるもようです。
これは、macOS 11上でAppleScriptをM1のEコアで実行して、大幅にAppleScriptの実行速度が低下したバグを想起させるものです。
また、スクリプトメニューはAppleScript環境における「最終防衛ライン」です。このライン内にAppleによる妨害が行われると環境全体の有用性が大幅に下がってしまいます(もうそろそろ、Appleをあてにせずに自分でスクリプトメニューを作ることも考えてもいいのかも?)。
SED=スクリプトエディタ、MEN=スクリプトメニュー
6 digits
SED: 0.099387049675 seconds
MEN: 0.515756964684 seconds
7 digits
SED: 0.501626014709 seconds
MEN: 3.565899968147 seconds
8 digits
SED: 33.727347016335 seconds
MEN: 263.738371968269 seconds
これが、バグなのかAppleのエンジニアによる嫌がらせなのか、セキュリティ向上の美名のもとに行われている破壊活動なのかは不明ですが、こんなに処理速度を落とすことに正当な意味があるとは思えません。
また、「おまえんとこの最新鋭機種、10年前のへっぽこ最底辺マシンの10倍以上遅い処理があるぞ」とかバグレポートに書かれないと直さないんでしょうか? バグレポートに書く罵倒文句にもいい加減、在庫が尽きてしまいそうなのですが、、、
本件、AppleScriptランタイムに「osascript」を用いているものは、一律に遅くなっている可能性があるので注意が必要です、
macOS 13.6.5 AS系のバグ、一切直らず
macOS 13.6.5アップデート(13.6.5(22G605))が配信されましたが、AppleScript系のバグは直っていません。
Appleのエンジニアは、「会社から給料をもらって日々新しいバグを作るのが仕事」という状況です。新しい機能よりも、新しいバグの方が多いというのは、もはやメーカーではなくてクラッシャーと名乗るべきなのでは?
・スクリプトエディタ上のテンプレートから選択するCocoa-AppleScript Appletランタイムが動作しなくなった
・スクリプトエディタ上でscpt形式のAppleScript書類に書いた「説明」が白地に白文字で表示されて見えなくなる
・日本語環境で、特定のTTSキャラクタ名(Bells、Hysterical、Organ、Princess、Trinoids、Whisper)が指定できない
スクリプトエディタで記入した「説明」欄の内容が消えるバグ
macOS 13.6.4+スクリプトエディタ バージョン2.11 (229)の組み合わせで、AppleScript書類の「説明」欄に記入した内容が「消える」トラブルが発生しています。macOS 14上でも発生していることを確認しました。
▲スクリプトエディタ上で新規書類を作成して、AppleScript本文と「説明」欄の内容を書き込んでみた
▲スクリプトエディタで名称を指定して保存(.scpt形式)した状態
▲保存していったんクローズして、再度オープンしてみたところ。「説明」欄の内容が見えない
▲「説明」欄の内容を選択したところ。白い色の文字が存在していることがわかる
「消える」というよりは、「見えなくなる」というのが正しい状況と思われますが、macOSのマイナーアップデートでこうした変更が加わる(正確にいえば、APIなどの変更が行われた一方で、スクリプトエディタの修正が行われずに動作がおかしくなる)というのは納得できません。
なお、バンドル形式のAppleScript(.scptd形式)であれば、「説明」欄の内容が白く表示されることはないようです。
macOS 13 TTS環境の変化について
正確にいえばmacOS 12あたりから大幅に変わっていて、忙しさにかまけて詳細な調査は行なってこなかったのですが……必要に迫られていろいろ調べてみました(Piyomaru Context Menu Assistant関連で)。
変更点1:TTS Voiceから年齢(Age)という属性値が削除された
変更点2:TTS Voiceの名前(Name)という属性値がローカライズされて返るようになった
変更点3:AppleScriptのsayコマンドにTTS Voiceの名前(Name)を設定するとエラーになるものが多数出てきた
変更点4:TTS Voice低音質キャラクタと高音質キャラクタ(Premium、Enhanced)があった場合に、AppleScriptのsayコマンドで低音質キャラクタが指定されるようになった。高音質キャラクタ(Premium、Enhanced)を明示的に指定する方法はない(sayコマンドでは不可能。AVSpeechSynthesizerを呼び出して読み上げるのは可能)
変更点5:AppleScriptのsayコマンドでSiriボイスを指定できないが、システムのデフォルト読み上げ設定にSiri音声を指定していると、sayコマンドでTTSボイス無指定(システムのデフォルト設定ボイスを使用)でSiri音声で読み上げられる
変更点1は、ポリコレの一環なんでしょうか。別に機械音声なので「年齢を基準に処理するな」とかいう不満は誰も抱かないと思います。これを決定した責任者は、頭がおかしいです。
変更点2は、NameのほかにLocalizedNameとかいった属性値を持たせるべきだったんじゃないでしょうか。経験の足りないエンジニアがとりあえずやっつけで仕事をしてしまったように見えます。これを決めた責任者は頭がおかしいです。バカと言って差し支えないでしょう。
変更点3は、けっこう困ります。AppleScriptのデフォルトコマンドには、TTS Voiceキャラクタ名の一覧を取得する、といった命令が存在せず、なんとなく「システム環境設定に出てくる名前を指定して使ってね」といった無責任な状況になっていました。昔からあるTTS VoiceのうちBells、Hysterical、Organ、Princess、Trinoids、Whisperを指定してもエラーになります(OS内に存在しているのに)。これは、OSの内部が壊れているものと判断しています。いい加減にしてほしいです。
変更点4は、Apple社内がえらく混乱しているように見えます。ちゃんと状況を整理していないような、開発現場のカオスな状況しか感じません。エンジニアの人数はさほど増やしていないのに、OSの数を野放図に増やしすぎです。これは、そういう管理をしている管理職の頭がおかしいです。
変更点5は、おそらくApple側が意図していない動作だと思われますが、「いまだとsayコマンドでAppleScriptからSiriの音声が指定し放題」であるということです。sayコマンドでは音声の指定を行わないと、OSデフォルトの音声キャラクタが指定されます。このデフォルト音声をSiriの音声にしておいて、キャラクタ無指定でsayコマンドを実行すると、Siriの音声キャラクタで発声が行われます。
sayコマンドで指定できるということは、音声ファイルにレンダリング可能だということで、Appleがキャラクタ提供元とそういうライセンス契約をしているのであればよいのですが、バグによって意図しない使われ方をしてしまう可能性があるわけです。ただ、このような状況を作った責任はAppleにあるものであって、ユーザーにはありません。
追跡調査を行なってみたところ、shell commandの/usr/bin/sayは、これらの、AppleScriptのsayコマンドではエラーになるText To Speechキャラクタ「Bells」も問題なく指定できました。
macOS 13.6.3beta登場。Cocoa-AppleScript Applet改修はなし
macOS 13.6.3betaが出てきました。通常のmacOSでは、マイナーアップデートが.6台で終了することが多く、.7台まで行くことは「まれ」です。
誰もが目を覆いたくなるような大失敗だった「macOS 10.13」「macOS 10.15」(はじめてBlogに登場記事の掲載を拒否)といった、歴史に残る失敗OSバージョンでも、マイナーバージョン6ないし7で打ち止めです。
# 歴史に残る失敗バージョンのmacOSには、Apple Siliconで不具合出まくりのmacOS 11(永遠のβ)とか、Release後にバグが出まくるmacOS 12、13もあるわけで、いい加減にしていただきたいところです
早速、Cocoa-AppleScript Applet(通常環境ではない、Script Editorのテンプレートから作成する特殊なCocoa AppleScript環境)が動作するのかどうか確認してみたところ、相変わらず動きません。
Cocoa-AppleScript Appletが動かない問題が、macOS 13.x台で改修されるのかは、果てしなく怪しい雰囲気になってきました。
●Mac OS X v10.0 (Cheetah)~10.0.4 (2001年6月22日)
2001年3月24日
●Mac OS X v10.1 (Puma)~10.1.5 (2002年6月6日)
2001年9月25日
●Mac OS X v10.2 (Jaguar)~10.2.8 (2003年10月3日)
2002年8月24日
●Mac OS X v10.3 (Panther)~10.3.9 (2005年4月15日)
2003年10月24日
●Mac OS X v10.4 (Tiger)~10.4.11 (2007年11月14日)
2005年4月29日
●Mac OS X v10.5 (Leopard)~10.5.8 (2009年8月5日)
2007年10月26日
●Mac OS X v10.6 (Snow Leopard)~10.6.8 v1.1 (2011年7月25日)
2009年8月28日
●OS X v10.7 (Lion)~10.7.5 (2012年9月19日)
2011年7月20日
●OS X v10.8 (Mountain Lion)~10.8.5 (12F45) (2013年10月3日)
2012年7月25日
●OS X v10.9 (Mavericks)~10.9.5 (13F34) (2014年9月17日)
2013年10月22日
●OS X v10.10 (Yosemite)~10.10.5
2014年10月17日
●OS X v10.11 (El Capitan)~10.11.6
2015年09月31日
●macOS v10.12 (Sierra)~10.12.6
2016年10月21日
●macOS v10.13 (High Sierra)~10.13.6
2017年10月21日
●macOS v10.14 (Mojave)~10.14.6
2018年09月26日
●macOS v10.15 (Catalina)~10.15.7
2019年10月8日
●macOS v11 (Big Sur)~11.7.3
2020年11月13日
●macOS v12 (Monterey)~12.6.3
2021年10月22日
●macOS v13 (Ventura)~13.6.3?
2022年10月24日
●macOS v14 (Sonoma)~14.0
2023年09月27日