色々な方の努力により、
薙刀式は現在色んなところで使えるようになっている。
3キー同時のロジックプログラミングは難しいと思うけど、
それが逆に「やったろ」という気持ちを刺激するのだろうか。
単純に薙刀式ユーザーかつプログラミング出来る人も、
さまざまなバージョンをつくられている。
とりあえず現在確認しているリスト。
【Windows】
DvorakJ……オリジナル。
キー配列を変更したり、キーバインドを変えたりするための、
民間開発エミュレータを使用して、
その上で薙刀式が動くようにしてある。
AutoHotkey……キー配列変更専用言語によるもの。
DvorakJ本体もAutoHotKeyで書かれている。
「Hachiku」は汎用から薙刀式のみに特化したアプリ。
専用なので、DvorakJ版より高速なのが特徴。
「ゆきね」は編集モードや打鍵ロジックに変更を加えて、
より薙刀式を使いやすくしている模様（開発中）。←New!
「紅皿」……もともとは「やまぶき」という配列変更エミュレータがあった。
開発がされていないため、それを引き継ぐプロジェクト。
親指シフト、飛鳥、新下駄、月など、様々な名作が、
ワンボタンで使える。薙刀式はそこに同梱。
「漢直WS」……TUT-codeなどの漢直を使えるためのアプリなのだが、
カナ配列にも対応、その中に薙刀式も同梱されている。
漢直と組み合わせて薙刀式が使える？！←New!
【Mac】
「Benkei」………Lacailleを改造してつくったらしい。
Macで使うにはこれがスタンダード。
【ブラウザ】
Web試打用……ブラウザのキー入力イベントを取得して、
色々な仮名配列に変換する。
OSフリーなのがいいよね。
例文、次に打つべきキーが表示される、
「かな配列テスター」に薙刀式が同梱。
【自作キーボード】
QMK版薙刀式……QMK_firmwareで動く。
好きな自作キーボード、好きなOSで使える、
夢のような版。どの自作キーボードにも移植できるぞ！
ただし自力でc++が読めて自力でコンパイルレベルが必要。
QMK_quantizer版……ふつうのUSBキーボードを、
QMK対応に変える基板。
この中のファームに薙刀式を入れた版。←New!
【かえうち】
未対応。3キー同時に対応していないため。
無理矢理作った昔の版はかえうちの掲示板にアップされていますが、
やっぱ使いにくかった。
それぞれのワードでググれば出てきます。
これでGoogle日本語入力のオープンソース版mozcに対応したら、
ほぼなんでも使えるはず……っ
当たり前なんだけど、
論理配列って論理構造のことだから、
どんな形式にも実装できるはずなんだよね。
あとはエンジニアがいるかいないか、
やりたい人がいるかいないかだけだと思われる。
あとはもともとの論理配列が優秀かそうじゃないかだ。
実装の苦労は、
多少ともAutoHotKeyやQMKをかじった身には、
よくわかる。
ただ、実装を難しくするためにそうしたわけではなく、
ユーザー側の使い勝手をよくするために、
そのような論理（複雑なシフト機構）を組んだのだ。
難しい配列を使ってドヤ顔したいわけではなく、
僕は「人間がやること」を極力減らしたい。
その分機械が苦労しろ、と考えているので、
それゆえ実装者の苦労は偲ばれる。
僕ら文系？は便利なそれを使って、
おもしろい文章、いい文章、
役に立つ文章を、たくさん書けばいいのだ。
もちろん、
つまらない文章、わるい文章、
役立たずな文章を書いてもいいぞ。
道具に善悪があるのではなく、
書く人にあるわけだから、
道具である武器は、なにをやってもよい。
刃物は人も殺せるし料理も作れる。
ただそれらの目的遂行の効率を上げることが、
道具の目的である。
文章をすらすら書くこと。
それこそが、薙刀式が生まれた理由だ。
2022年06月26日
この記事へのトラックバック
＞多少ともAutoHotKeyやQMKをかじった身には、
＞よくわかる。
githubのチェックインの記録とかでみると、
紅皿を薙刀式に対応したときのチェックイン頻度は、紅皿を最初に親指シフト対応したときのチェックイン頻度の約２倍でした。
コード記載量も、体感として親指シフトの約２倍が薙刀式とおもいます。
チェックイン頻度というのは紅皿をダウンロードした頻度ということですかね。単に見ただけなのかしら。
それだけ関心があるということでしょうか。
あるいは、親指シフトを使ってる人は、やまぶきRやら従来のものから替えずに、特に試さなかったのかも？
ちなみにコード量だけでいうと、
DvorakJでは薙刀式は親指シフトの30倍ほどあります。
紅皿のコードが優秀で、複雑な配列の記述にも向いてる、
ということですかね。
だとすると、僕はやまぶきRを使ってこなかったので、
やまぶきを使ってない人で紅皿を初めて使う人用に、
自分なりの配列ファイルのつくりかたを、
どこかでまとめておくといいかもです。
紅皿で自分用の配列を作る人が出てもいいし、
DvorakJで薙刀式的な配列をアレンジして作るより、
紅皿でやった方が早そうなので。
或る程度「切りのいい」ところで、そのソースコード変更を保存するときに行う動作で
す。
作業量を測るときの参考となります。
つまり、NICOLA配列のためのコーディング量の約２倍が
薙刀式のコーディング量です。
紅皿の動作仕様書の状態遷移表でいうと
https://qiita.com/kenichiro_ayaki/items/9a39a5c7622c23e3ce3b
NICOLAは、S1〜S6の状態と、６通りのキー打鍵状態の組み合わせを遷移するので、３６通りの状態遷移が発生します。
薙刀式は、S1〜S8の状態と、６通りのキー打鍵状態の組み合わせを遷移するので、４８通りの状態遷移が発生します。状態遷移でいうと、２倍の工数にはならないのですね。
なるほど、詳しい解説ありがとうございます。
実装のやり方によっては工数が減らせるだろうなあ、
ということまでは理解できます。
たとえばAutoHotKeyの単純なやり方だと薙刀式の実装は相当面倒になるな、
と気づいたので僕は見送りました。
これから変えないと決めればその実装だけやればいいんでしょうが、
自由に配列を作れますという立場だとどう基盤を組んでおくかが大事になってくるんでしょうねえ。
紅皿から見ると薙刀式は（そごまで）複雑じゃないんだなあ。
Nキー同時まで拡張すると、
今度は4キー5キー同時の配列など出てくるのかしら…
あるいは、同時や前置や通常などを組み合わせた多段シフトとか…
初期化
文字キーオン
親指オン
文字キーオフ
親指オフ
タイムアウト
の６つのイベントのうち、文字キーオフ・親指オフのイベントを扱わずに４つのイベントで遷移させているのですね。そのためか、DvorakJでは、やまぶきではできなかった「３キー同時打鍵判定」までもができてしまっているのです。
この点は、すごい「見切り」だとおもいます。
DvorakJは3キー同時が判定できるのは、
文字領域だけで親指部は除外なんですよね…
ここまで実装されてたら、
薙刀式の打ち方はまた変わってたかもなあ、
などとたまにおもいます。