先日、Windows11 22H2 のアップデートがきた。待っていた systemd 対応がきたので、早速更新。 せっかくなので、Windows の回復を利用して、フルリセットに近い形で Windows11 22H2 を入れた。 始める前は Windowsの再インストールは気が重かったのだが、やってみたら簡単だった。以前はもっと大変だったという印象がある。まだまだ ChromeOS ほどではないにしても。 Windows11 22H2 をセットアップしたあと、通常手順で wsl --install してインストールしたところ、インストールされた Ubuntu は systemd に対応していなかった。 ちなみにインストールされたのは Ubuntu 20.04.4 LTS。 上記 microsoft devblogs を読み直してみると、Windows Insiders Build でないと systemd 対応版の WSL はインストールされないらしい。 でもさらによく読んでみたら、github のWSL リリースページから 0.67.6 を入手して手動でインストールすればよいらしい。 果たしてやってみると、systemd対応になった。 Wnn8 をインストールしたらすんなり自動起動できるようになった。 Windowsを再起動して WSL を起動したら、自動で Wnn8 が起動している。 とりあえずは、systemd 対応でうれしいのは（自分にとっては）これだけだけど。 以前に書いたこの Wnn8インストールのエントリーの後半で、 なんやかんや Wnn8 の起動設定をしている部分がいっさい不要になった。
Windows11 22H2 のアップデートは Thinkpad Nano に入れた。 ここしばらく、MX Keys mini のキーボード＋ Surface GO ばかり使っていて、このThinkpad の出番が少なくなっていたのでちょうど良い。 しかし、Thinkpad Nano にしても Surface GO にしても、Windows ラップトップというのは 5,6時間しかバッテリーが持たない。そこが気に入らない。 M1 Macbook Air を併用しているので、バッテリーライフの基準がそれになっている。 Thinkpad も X13s で ARM CPUのモデルが出たので、これならバッテリーが持つのかも知れない。 今回は先ほども書いた通り Thinkpad Nano を初期化した上で、WSL のみを入れる形にした。 だから、これでバッテリーライフが伸びてくれるのではないかと、淡い期待をする。 そもそも Thinkpad Nano の公称バッテリーライフは 最大 約22.9時間 とかだから。それはないだろう。 どう使ったらそうなるのか、と思う。
Thinkpad Nano は当初 Linux のみで運用するつもりだった。実際しばらくはそうしていたのだが、 あまりにバッテリーが持たないので Windows に戻したという経緯がある。 そのときは（１年くらい前）まだ Nano が出てすぐだったから Linux の対応も不十分だったのであろう。 数年たてば、状況も変るかも。
しばらく休んでいた Android アプリの開発を再開した。 今書いているのは small sketch のニューバージョン。 そして、このアプリのようにドキュメントを作り出すアプリで困るのがファイル管理。 Android タブレットは物理キーボードがない場合が多いし、Linux/Mac/Windowsのようなローカルのファイルシステムにドキュメントを保存するという 発想でアプリが書けない（気がする）。 自前のクラウドサービスがあればよいがそんなものが簡単に運用できるわけもなく。 Android には SAF があり、建前上はドキュメント系のクラウドサービスとアプリが連携できるフレームワークがあるのだが、 実質対応しているのが Google Drive だけ、という状態が長く続いている。 そして、Google のサービスというのは突然終了することも結構あるから、SAFだけに依存して梯子をはずされるのも怖い。 そして、手書きアプリ系にはうれしい、digital ink recognition という手書きをテキストに変換できる機能もあるのだが、 強力な機能だけにアプリの価値がそれに依存していて、その機能が終了になると致命的。 その辺の事情を考えると、採用していいものか悩む。 手書きで描いた内容がテキスト化できれば、手書きデータの検索が可能になるわけで、とてもうれしいのだが。
ExtendScript Debugger が 2.0.3 にアップデートしていた。 以前と launch.json の記述方法が変更になった。
以前(v1.x系)の .vscode/lanuch.json:
{
"version": "1.0.0",
"configurations": [
{
"type": "extendscript-debug",
"request": "launch",
"name": "Launch main.jsx",
"program": "${workspaceFolder}/main.jsx",
}
]
}
新しい(v2.x系)の .vscode/launch.json:
{
"version": "1.0.0",
"configurations": [
{
"type": "extendscript-debug",
"request": "launch",
"name": "Launch main.jsx in InDesign 2022",
"script": "${workspaceFolder}/main.jsx",
"hostAppSpecifier": "indesign-17.064",
"engineName": "main"
}
]
}
hostAppSpecifier でスクリプトを実行するアプリを指定できるようになった。 これを指定しなければ、デバッグ実行時にどのアプリでスクリプトを実行するか 選択することになる。
以前はこの指定を jsx ファイル中に //@target InDesign と記述していたが、 そのやり方にとって変わったようです。
ここでは indesign-17.064 と指定していますが、ここまで細かく指定しないとだめなのか。 ざっくり indesign とか indesign-17 くらいの指定にしたどうなるのか？ その辺はまだ試していない。