QMK/ZMK/KMK薙刀式の状況

昨年6月に下のような記事を書きました。

この変換ロジックを思いついたときには、これはうまくいきそうだという実感があったのですが、実際に実装して使ってみると、入力してもなかなか文字が表示されないというのは、思っていたよりストレスがあって、開発の途中からどうやって入力途中で先行確定していくかを考え始めたのですが、それはもはや最初におもいついたロジックとはずれていっていると感じて、このv15x実装は放り出しました。

正確に変換するより、なるべく早く表示して入力フィードバックを与えた方が、体験としてよいなと、今更考えなおして、次の実装v15yを作り始めました。 dvorakjよりもいいものにはしたいです(変換の確定が遅い、なにより不安定)。とるさんのHachikuが一番、入力体験がいいなと思っていたので、それと似たような挙動をキーボードファームウェアで実現できたらいいなと。 (Hachikuのコードは全く読んでいません汗)

最近のスタイルとしてはKMKでまずちゃんと動くものをつくって、それをQMKとZMKに移植する、というフローにしています。 Pythonで書けるので、コレクション(List、Setなど)があるのは大変楽だし、型がないので同じ変数に文字列やLambda式をつっこんだりと割と好き放題できます。とにかく動くものをつくるには手っ取り早いし、デバッグも早い。 (本当はPRK Firmwareをいれてrubyで書きたいんですが、まだうまくいきません。)

とりあえず動作するものを置いておきます。まだUNICODE入力が必要な編集モードを実装していないし、入力中におかしくなったりするので未完成ですが、おおむね思った通りに動作しています。

データ構造として、スペースや編集モードのDFキーなど、必ず前置で押すキーと、濁点、半濁点のように後置が許されるキーを分けて定義しました。 QMKにもv15yとして移植はしたのですが、あまり工夫をしていない実装でv15、v15xに比べてファームウェアサイズが大きいので、 OLEDとかをオフにしないといけないのが課題です。

kmk_naginata/Raspberry_Pi_Pico_15y at main · eswai/kmk_naginata · GitHub

qmk_firmware/users/naginata_v15y at master · eswai/qmk_firmware · GitHub

今年はv15yの実装を完成させて、ZMKにも移植するのが、新年の抱負ですね。