どうせメニューから抜くならキーカスタマイズの方式を変えようか

まあ再設定してもらうことにはなってしまうけど。
SQLite導入で、機能追加が結構出てきそうな雰囲気だし、長い目で見ればやっておいたほうがいい。
キーカスタマイズが定義ファイルを手で書き換えること自体はそれほど不評ではないが、定義ファイルが機能追加で変わること、それがユーザーフォルダの定義ファイルに反映されないこと、は問題。
現仕様は構想の上では、機能追加なんてあんまりしないだろうということ、キーカスタマイズ以前にメニューカスタマイズができること、そして何よりキー割り当ては俺が決めてるので俺にカスタマイズの必要が無いこと（酷い！）、からこう決まった。
しかし思ったよりアイデアは枯れないもので、いつまで経ってもバージョンアップは続いているし、初期のメニュー定義には無い機能がたくさん増えた。これからも増えるんだろう。
一番最初に思いつく方式としては、カスタマイズの需要がある部分の分離。メニュー定義は「表示される文字列」「対応する命令のタグ」「キー割り当て」「確認メッセージの表示有無」が定義されていて、この内カスタマイズされるのは後半2つ。メニューの構造自体を自由に配置出来ることを可能としていたが、それは需要としては無いようだ。
だから、メニュー定義から「キー割り当て」「確認メッセージの表示有無」を抜き、新たにキー定義ファイルを作る。内容は構造的でなくて構わない。「対応する命令のタグ=キー割り当て」のようなINIファイルみたいなもので良い。
まあ誰でもこう作るわな。なんで俺はそうしなかったんだろうか。つーかOpera風キー割り当てはそんな感じになってるな。単にめんどくさかっただけなのか。
ん。手で追加されたユーザーオリジナルのメニューの問題が残っていた。これはスクリプトやプラグインの機能にキー割り当てするのに使われている。tool.xmlとかを自分で作成してもらって、メニューのルートに「ツール(T)」とか作って表示するか。
仕様的には大体こんな感じで問題ない気がするんだけど、移行時にユーザーがめんどくさいと思う。けどこんなの自動化できないなあ。いや出来なくはないけどめんどくさいよ。めんどくさいことが嫌いだから考えてるのに何でめんどくさくなるのだ。