eswaiさん設計のqmk_firmware薙刀式が動いた。
結構な知識がないと実装は無理
(書き込むのすらご本人にご助力頂く羽目に。感謝)
なので、万人にまだ出来る段階ではないにせよ、
これは論理配列の新しい実装だなあ。
自作キーボードに、
これまでよりも複雑なシフト方式や、
スタンダード配列ではない特殊物理配列上の配列や、
特殊物理配列の漢直まで載せられてしまう可能性があるということか。
記号類とかOSによる差とかはあるものの、
これは「夢のキーボード」へまた近づいたのでは?
日 | 月 | 火 | 水 | 木 | 金 | 土 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
連続シフトの件、今は入力したキーの先頭から最長一致で検索するので、ロールオーバーしたシフトは前のキーの同時押しになります。ロールオーバーの処理は時間もパラメータとして考慮しないとチューニングが難しそうですね。
お世話になります。
慣れの範囲で行けるかなと。今は後置シフトのメリットを探しているところ。
また、DvorakJに比べてシフトの冗長定義をきちんと判定するので
(DvorakJはシフトの絡む同時押しはms単位での同時押し判定になる。
100くらいの初心者で使ってたころは恩恵があったけど、
今は5くらいにしてほとんど使ってない)
そこの感覚が違いを大きく感じます。
冗長定義自体なくてもいいかどうかは議論の余地があります。
あると「まで」とかのシフト離しを意識せずに打てるメリットがあるので。
また、バグらしきもの?
・左シフトを押しながら「だよね」といけるはずだが、
「だよき」と、最後にシフトがかからないことがある。
速度が速すぎるとなる?(再現性不明)
あとこれは自分のDvorakJソースのミスを発見。
・IMEのオンオフを変換無変換で定義すると、編集モードの再変換が使えない
→DvorakJのソースを見ると、英数でHJ: ひらがなカタカナキーでIMEオンにしていたが、カナでの定義は変換キー(使わないのに)になっていた。
ひらがなカタカナキー: IMEオン
無変換キー: IMEオフ
変換キー: 再変換
にMS-IMEで設定したのち、
qmkでIMEオン: INT2、再変換: INT4に定義すれば問題ないでしょう。
DvorakJと比べて、同時押しが入りっぱなしになるバグもないので、
快適に使えています。
あとは自分の移植がうまくいってない理由を把握したい。
qmkのバージョンが古いとかあったりして…
Dvorakj版使ってみて、自分は頻繁にシフト後押ししてることがわかりました。
どこかで「COMBOには不具合がまだある」と聞いたような気がするのは、
バージョンの問題だったのかも…アップデートしてみます。
シフトの後置が可能だと、同時押し的に親指を使えることがわかります。
親指の使い方が若干変わってくるので、
これに慣れるとどうなるか実験中。
手首を浮かした方が打ちやすいかも。