Windows の theme(pack) の「Sounds」の話

しょーもないことばっかやってる…のはいつものことか。

エロ音声を全裸のまま快適に聴くにはプレイリストが不可欠だというアホなネタから始まり、ただプレイリストを扱うだけじゃなくて CD も簡単に作れちゃおうかというネタに派生し、そしてプレイリストからは外れてしまったけれど Windows のテーマパックビルダなんてのを考えた。

という流れでの「Windows のテーマ」なんだけどさ、知れば知るほどまぁなんというか統一感がなく一貫性がなく、ダサい、とにかくダサい、このデザイン。カーソル、サウンドの仕様はもうね、発狂する、これは。もともとまったく別物としてデザインされたものを無理やり統合した、てのがよくわかる。

アイコンに関しては、先日の simple_windows_themepack_builder.py に詰め込んではみたものの、非常に不自然である。やってはみたものの、なんとも嬉しくない。

一番問題なのが「Sounds」の仕様。いや、「テーマ内の Sounds の仕様」がマズいんではなくて、「Sound Scheme」の仕様がね、ヒドい。いや…正確には、仕様というか「Sound Scheme 構成のためのインターフェイス」の問題。カーソルの方はなぜかドライバインストールのシカケの再利用で inf ファイルに書いてセットアップ出来るのだが、Sound Scheme の方は、公式には「GUI で一個一個チマチマと地道にコツコツせっせとひとつひとつ頑張って頑張って」設定する手段しか用意されてない。

「一個一個チマチマと」しないためにテーマがある、という考え方の「前に」スキーマがある、という考え方なわけよ、発想としては。スキーマを切り替えれば一気に全部切り替わる、てシカケなわけだからね。テーマは、スキーマがそういうものであることを前提として設計されていて、「な、なんとっ、スキーマも指定出来るんだぜっ、すげーかろ」て思想なわけ。だからイラっとするわけよ、そっちのスキーマの構築が簡単に出来ないのだから。はっきりいって「イベント対サウンド」のマッピングだけなのだから、Microsoft のデベロッパがこんなに手間がかかることに疑問を感じてないのが非常に不思議。こんなん設定ファイル一個でサクっと構成出来るべきだよ…。

まぁ一応 theme の設計そのものへの文句としては、この人が言ってることと同じことをワタシも思った。テーマに書いた「Sounds」のスキーマは、そのテーマ専用になってしまう、なんでぢゃ、と。「テーマパック」としてサウンドも込みでお披露目したい、サウンドはテーマに密接に関わる、…という考え方があってもいいし、そういうテーマもそりゃあるだろうさ。たとえば「ドルフィン」なテーマで、ジャングルを想起するようなサウンドが鳴ってたら、かなり気持ち悪かろう。だから themepack のデザインに罪があるわけではないんだよね。

てなわけで、「テーマから、テーマに依存せずに使える Sound Scheme に仕立て上げる手段」が欲しいなぁと:

<script src=”https://gist.github.com/hhsprings/13966b2b27cdd334965b29c0ca65929b.js”></script>

たとえば Microsoft 公式のここの「with custom sounds」のテーマパックをダウンロードして、その themepack を喰わせれば、いつでも使える Sound Scheme になる:

(ちなみに「ベル・カールステッド」なんてのが見えてるがこれはエロ音声のやつ。)
イベントとのマッピングは theme ファイルを読むことで決めるが、互換の形式であればいい。スクリプトがやることは極めて単純かつ乱暴で、「c:/Windows/Media」に音声をブチこみつつ、それを指すレジストリをゴニョってるだけ。なんでこの程度のインポート UI が用意されてないんだか? そしてなんでカーソルの方はバッチ投入出来るんだか…。

なお、このスクリプトで抽出してみても、ファイルが欠落してる場合がある。どうも Windows 7 時代の Sound Scheme を前提にしてるものがあるようで。たとえば少なくともワタシの Windows 10 の「c:/Windows/Media/Sonata」の中身は空っぽだったが、EerieAutumn.themepack がそれに依存していた。こういうのはこことかからお取り寄せれば良い。

で、simple_windows_themepack_builder.py の話に戻るんだけれど、結局 simple_windows_themepack_builder.py で Sounds について扱おうとするとカーソルよりももっと不自然になっちゃうのよね、だから組み込まないことにした。結局 theme ファイル相当のマッピングが必須になるので、もとの simple_windows_themepack_builder.py の発想にちょっと馴染まなくてさ。はっきりいって今回の windows_soundscheme_pcglobal.py とかで作った Sound Scheme だけで満足しておいて、Windows 自身の設定 GUI でそれをマニュアルで指してあげるんで十分かなと。


2021-08-04追記:
「https://gist.github.com/hhsprings/13966b2b27cdd334965b29c0ca65929b.js が指していた「windows_soundscheme_pcglobal.py」」は、simple_windows_themepack_builder.py の別名として管理することにした。

この考え方の変更は上で書いてる「文句」に関係してる。

Windows 7 の「テーマパック」と従前からの「カーソル、サウンド、デスクトップ背景」の関係はまったく綺麗に整理されてなんかいなくて、本来はこれら3つは「ちゃんと独立して綺麗に構成することが出来て、それらを一気に行えるのがテーマパックである」となるべきだったのに、そうなってない。ので、ワタシのスクリプトは、「独立してサウンドスキーマを構成することが出来て、それをテーマパックにも組み込める」という風にしたかった。こうなると、「カーソルの構成、サウンドの構成、デスクトップ背景の構成、そしてテーマパックとしての構成」の4つを書く必要があり、そしてそれらの中身は相当部分が重複してしまうことになり、スクリプトを分けて管理するのが結構鬱陶しくなる。

むろん「まともなプロジェクトにする」ならば、python パッケージにしてしまえばいいのだけれど、正直それをする気は毛頭なく、gist でいい加減に管理し続けるのは維持したい。だってそういういい加減なものだからね、これ。てわけで、ハードリンクでスクリプト名で振る舞いを切り替えるようにした、てこと。

本日時点ではまだ「テーマパック構成」と「サウンドスキーマ構成」部分しかないけれど、「カーソルの構成」部分も同じ要領でやるつもり。(今はカーソルの構成単独の実行は出来ない。)


2021-08-15追記:
まだ少し先の話かもしれんけれど、「テーマ」そのものを廃止するプランの模様。なんで? 詳細がまったく書かれてなくて困る。theme、themepack の仕様がなくなる、という生易しい話ではなく「カスタマイズ許さじ」となるかのようにすら見える書きぶり。わからん、何がしたいんだ…。デザインを一新して別のものを使わせてくれるようになる、というプランなら理解は出来るけれど、「Roaming of Personalization settings (including wallpaper, slideshow, accent colors, and lock screen images) is no longer being developed and might be removed in a future release.」だからね…。

「仕組みが一新される」のであれ、いま時点で解釈できる「カスタマイズ許すまじ」であるのであれ、どちらにせよ、ワタシのアホスクリプトの寿命は、なので、あまり長くはなさそうである。まぁいまの win10 をワタシ自身がいつまで使い続けるかなんだけどね、Microsoft のプランそのものよりも先に。