気になる問題を二つ解決
気になった問題の一つ目は、昨日書いていた問題になるのだが、真面目に調べてみると、問題の原因はAppleScriptで表示されるパスワードダイアログ自体では無かった事が分かった。
それでは、何が問題だったのか、というと、Appleスクリプトをメニューハンドラーの中で実行していた事だ。
つまり、Appleスクリプトでパスワード入力用ダイアログが表示されると、その入力が終わるまで、スクリプトの実行は終了しないので、その終了を待っているメニュー項目は、そのハンドラーの中で待つ事になる、というのが問題だった訳だ。
これだけ書いても、それの何が問題なんだ？ と、思う人もいる筈だ。
何故なら、メニューと画面キャプチャーとは、本来は何の関係もないので、メニューの実行中に処理が停止していても画面キャプチャーには何の支障もない筈だからなのだが、実際には、巷の多くのOSでは、メニューも画面キャプチャーも、メインスレッドで動作する。
なので、メインスレッドで待ちを行っているメニュー項目があると、メインスレッドは他の用途に使えなくなるので、画面キャプチャーも行えなくなっていた訳だ。
このため、Appleスクリプトを別プロセスで動作させたとしても、それを呼び出しているメニュー項目がメインスレッドで、その終了を待っていたのでは、状況は改善しないので、まず、メニューハンドラーの中で、Appleスクリプトの終了を待つのはヤメにした。
具体的には、Appleスクリプトは別スレッドで実行し、メニュー項目は、そのスレッドを実行した時点で処理を終了させたのだが、それだと、Appleスクリプトの終了後に行わなければならない処理が行えなくなるので、前述のスレッドに、終了時に必要な処理を行わせる格好にした。
上記で、半分くらいのAppleスクリプト絡みの処理は何とかなったのだが、環境設定メニューで、画面解像度を変更する処理については、スクリプトとその他処理があまり独立していないので、上記の様な形態にするのは大変そうだった。
なので、別の解決策を検討してみたのだが、ネットで色々と検索していると、runModalForWindowというメソッドを呼んでおくと、その場で待ちながら、メインスレッドを別用途で使える！ という事が分かった。
このため、Appleスクリプトは別スレッドで動作させつつ、メニュー処理はメインスレッドで普通に動作させ続け、Appleスクリプトの待ちについてだけ、上記のrunModalForWindow、スクリプト終了時にAppleスクリプトの実行スレッドでstopModalメソッドを呼び出す格好にした。
上記の解決策を見つけるのには苦労したのだが、やり方が判ってしまえば、別プロセスでAppleスクリプトを動作させる！ なんて大袈裟な事をする必要がなくなったので、変更したコード量的には少なくて済んだ。
と、言う事で、これでリリースできるかなあ、と、思って、開発環境以外の作者の手持ち環境で動作確認をしてみたのだが、Mac mini Late2014で動作させると、問題が出た。
具体的には、今回追加したリモートデスクトップ機能で操作してみると、「^」キーなんかが正しく入力できなかった。
より詳細に書くと、このマシンには、109キーの日本語キーボードを接続してあって、そのキーボードで普通に日本語も含めて入力できていたのだが、何故か、リモートデスクトップ機能からキー入力すると、キーボードが英語キーボード相当のレイアウトとして扱われた感じだった訳だ。
なので、これはリモートデスクトップ機能のバグ？ と、一瞬、思ったのだが、それはちょっと考えられなかったので、スクリーンキーボード機能を使ってみた所、その出力も、英語キーボードみなしになっていて、「^」キーを入力したつもりが「=」キーが入力された。
更に、Mirror-DTCを使って同じ事をやってみたのだが、やはり、「^」キーは入力出来なかった！
と、言う事で、昔はそんな事は無かったのになあ、という事で、何が問題かを確認してみたのだが、前述の109キーボードを接続しているのが問題だった様だ。
何故なら、メインマシンにしているMac mini M2 Proには、通常は、Apple純正ワイヤレスキーホードを接続していて、その環境では問題はなかったし、キーボードが内蔵されているMacBook Pro 13インチ M1モデルとMacBook Pro 15インチ 2016モデルでも、問題は発生しなかったからだ。
なので、念の為、メインマシンからApple純正キーボードを取り去り、代わりに、上記の109キーボードを接続してみた所、Mac mini Late2014と同じ現象が発生した。
この問題は、macOSのバグなんじゃないの？ という気もした。
何故なら、リモートデスクトップ機能等のキーボードエミュレーション以外では、普通に日本語入力も含めて、正しくキー入力はできているので、macOSが接続されているキーボードのレイアウトを間違っている訳ではなかったからだ。
にも関わらず、エミュレーションの時だけ、英語キーボードのレイアウトだと勘違いするのはバグでしょ？ という気もした訳なのだが、ネットで色々と調査してみた所、正確な情報は全くなかったのだが、キーボードエミュレーション用のイベントのソースに対して、CGEventSourceSetKeyboardTypeというメソッドで、キーボードタイプを設定できるAPIが存在する事は分かった。
いくら調べてみても、このメソッドで指定するキーボードタイプに関する情報は出てこないのだが、ためしに、0を指定してみると、日本語キーボード相当のレイアウトが使われる様になった。
なので、この0という数字がシステム設定に従う、みたいな値であるのなら、問題は解決なのだが、この値の説明を見つけられないので、何とも言えない状況だ。
しかしまあ、普通は、0はデフォルト扱いだったりするので、とりあえず、問題となる現象は発生しなくなっているので、この問題についても、これで解決！ という事にしてしまうかもしれない今日この頃だ。
ちなみに、上記の通りで、既に、気になる問題は無くなったので、リリース準備に入るのだが、まだまだ、毎日暑いので、日中に、真面目に作業をするのは困難だ。
なので、公開は、土曜日の夜か、日曜の夜になりそうな今日この頃だ。