Files

T

ewdernaandClaude Opus 5.5 85f333cb24 chore: Markdownのインデント幅を4に固定し、リストの継続行をスペース4つに揃える

継続行がスペース2つだと、VS Codeがインデント幅を2と自動判定する。
.vscode/settings.json でMarkdownの自動判定を切って幅4に固定し、
既存の継続行もリストの記号から4つ下げた位置に揃える。
変更したファイルに markdownlint --fix をかけた分(journalのURL囲みと空行)も含む。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VbfgHT848s3JbuFw8MKFF8

2026-10-19 08:16:12 +09:00

3.0 KiB

Raw Blame History

MAPエディタの実機との往復とVIA対応

結論

新規作成するキーボードのワークフローを主眼とし、MAPエディタは実機の読み書きを一組で提供する。最初の通信プロトコルはVIA。対応プロトコルを絞り、段階的に増やす。独自プロトコルの追加や、そのためのQMK・Vial等のフォークは行わない。高度な動作定義、Staticの対応範囲、同期方式はまだ決めていない。

案の比較

案	扱い
既存プロトコルで実機の読み書きを提供し、VIAから始める	採用
MAPエディタをStaticに閉じる	採用しない
Dynamicの対応範囲を読み出しだけに限定する	ユーザーが読み書きの両対応を指定
独自プロトコルのためにファームウェアをフォークする	ユーザーが意図しないと明示

判断の根拠

ユーザーは、既存キーボード全般への対応よりも、新しく作るキーボードのワークフローを重視している。 VIAを話すなら読み書きの両方を提供し、利用者が好むRemapと同じ通信経路から始める方針となった。当初のアシスタントによる「互換性」の説明はファイル変換に寄りすぎており、実機との通信を中心に修正した。 VIA向けのキーボード定義生成と、MAPの割り当ての読み書きは別の責務として整理した。

調査で確認した範囲

公式文書・実装を参照した。実機による読み書きの検証は行っていない。

RemapはWebHIDを使い、QMKのVIAクライアント向け機能へアクセスする。Workbenchにはソース編集・ビルド・書き込みもある。参照: https://github.com/remap-keys/remap#references 参照: https://remap-keys.app/docs/workbench
VIAのキーボード定義には配置とmatrix座標の対応がある。QMKのVIA実装はキー単位の読み書きにlayer・row・colを使う。参照: https://caniusevia.com/docs/specification/ 参照: https://github.com/qmk/qmk_firmware/blob/master/quantum/via.c
Vialではタップダンスやコンボを実機へ保存できるが、枠数等にはビルド時の制約がある。参照: https://get.vial.today/manual/tap-dance.html 参照: https://get.vial.today/manual/combos.html
ZMK Studioは既存behaviorの割り当てを変更できるが、新しいbehavior定義等は対象外。実機に保存した変更とソース側の設定の扱いにも注意が必要。参照: https://zmk.dev/docs/features/studio

未採用の提案との区別

共通の動作モデル、ファームウェア固有表現の保持、Staticを先に実装する順序、差分を選んで反映するUIは、アシスタントの提案段階にとどまる。今回の合意として固定しない。 Vial・ZMK Studioを次にどの順序で実装するかも決めていない。

3.0 KiB Raw Blame History