Files
Beyond-KLE/implementation-plan.md
T
ewdernaandClaude Opus 5.5 af6ce99364 plan: Cr0wn60のVIA定義をcharlieplexingの検証用サンプルに加える
- samples/via/cr0wn60.json を追加し、テストケースにcharlieplexingを加える
- ピンの割り当てとマスクの参照先としてファームウェアのコミット68d9249を記録する
- CLAUDE.mdのドキュメント地図にsamples/を載せる

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017W6AsoJYTiN3bnxvSMS87f
2026-09-24 23:00:26 +09:00

5.8 KiB

Beyond KLE: 実装計画

PHY Editor の土台

PHY Editor は自作する。既存のレイアウトエディタのコードを土台にしない。 PHYの正本は相対座標の木だが、既存エディタ(KLE, kle-ng)の移動・回転・undoはフラットな絶対座標の配列を直接書き換える作りで、改造しても中核は書き直しになるため。

  • ijprest/keyboard-layout-editor のコードは取り込まない。全権利留保で、作者はフォークを避けたい意向を明記している。ソースを読んで挙動を確かめるのは可
  • adamws/kle-ng は MIT ライセンスで、参考実装として読める
  • 過去の自作エディタ(Documents/Dev/kbd-editor)のコードも取り込まない。KLE本体を参考に書かれた部分が多く、どこが由来か切り分けられないため。プロファイルの定義項目など、概念を参考にするのは可

検証用サンプル

テストケース

入力はKLE JSONとし、取り込みを通してPHYへ変換する。

ケース サンプル 主に確かめること
60% Cr0wn60 行スタッガード、幅の違うキー、左右対称配列の中央の隙間
分割 crkbd、jisplit89 左右の分離、カラムスタッガードと回転した親指キー(crkbd)、キー数の多いJIS配列の分割(jisplit89)
分割 + バリアント Kyria、Iris Rev.7 回転したクラスター内のバリアント(Kyria)、部品(エンコーダ)を含む3択のバリアント(Iris Rev.7)
マクロパッド 4x4 最小構成
charlieplexing Cr0wn60(VIA定義) 行と列が同じピンを共有する配線を、ELCの接続先で表せるか

リポジトリに置くサンプルは samples/ にある。

  • kle/cr0wn60.json: EwdErna/Cr0wn60 の keyboard-layout.json(919cc9e、MIT)
  • via/cr0wn60.json: 同リポジトリの cr0wn60-via.json。ラベルにマトリクス位置を持つ
  • kle/macropad-4x4.json: このリポジトリで作成

Cr0wn60はcharlieplexingで、行と列に同じ9本のピンを割り当て、使わない位置をマスクしている。 ピンの割り当ては、ファームウェア EwdErna/qmk_firmware の dev/ewderna_22 ブランチ(68d9249)の keyboards/ewderna/cr0wn/cr0wn60/ にある (info.json の matrix_pins、cr0wn60.c の matrix_mask)。

その他はコピーせず、the-via/keyboards(GPL-3.0)から、コミット 9e3e9f4 の次のファイルの layouts.keymap を取得して使う。

  • crkbd: src/crkbd/crkbd.json
  • jisplit89: src/jisplit89/jisplit89.json
  • Kyria: src/splitkb/kyria.json
  • Iris Rev.7: src/keebio/iris/iris-rev7.json

VIAの定義に含まれるKLE JSONは、ラベルにキー名ではなくマトリクス位置(行,列)を持つ。 バリアントは、ラベルの別の欄に 選択肢の番号,候補の番号 の形で示す。 キー名のラベルによる照合の検証には使えない。ELCの接続先とバリアントの検証に使う。

データ例

60% ANSI PHY Layer (抜粋)

{
  "version": "1.0.0",
  "metadata": {
    "name": "60% ANSI",
    "description": "Standard 60% layout"
  },
  "profiles": [
    {
      "id": "standard",
      "name": "Cherry MX",
      "unitSize": { "x": 19.05, "y": 19.05 }
    }
  ],
  "root": [
    {
      "type": "key",
      "id": "k00",
      "profile": "standard",
      "transform": { "x": 0, "y": 0, "rotation": 0 },
      "size": { "w": 1, "h": 1 },
      "labels": ["Esc"]
    },
    {
      "type": "key",
      "id": "k60",
      "profile": "standard",
      "transform": { "x": 5, "y": 4, "rotation": 0 },
      "size": { "w": 6.25, "h": 1 },
      "labels": ["Space"]
    }
  ]
}

検討済み・非採用

  • ijprest/keyboard-layout-editor の改造 (journal/2026-09-18-editor-base.md)
  • adamws/kle-ng の改造 (journal/2026-09-18-editor-base.md)
  • 過去の自作 kbd-editor を土台にする (journal/2026-09-19-kbd-editor-review.md)

未確認事項

P-1 kle-serial2 の serialize がKLE本体のコードに由来しないか

  • 位置づけ: 未解決の問い。KLE JSONの書き出しに kle-serial2 (MIT) を使うかの判断に関わる
  • 現状の認識: 本家 kle-serial は書き出しを「KLE本体から移植予定」としていた。kle-serial2 の serialize は KLE の serial.js と構造が似るが、KLEフォーマットがその構造を要求するため由来の証拠にはならない
  • 格上げ条件: kle-serial2 の作者に出自を確認する。確認できない場合は書き出しを自前で書くかをユーザーが決める

P-2 技術選定

  • 位置づけ: 未解決の問い。言語、UIフレームワーク、描画方式、状態管理、テスト、KLE JSONの読み書きに使うライブラリ
  • 現状の認識: 旧計画はReact系の構成を挙げていたが、選定の根拠はない。Vueの案もNuxtに慣れているというだけ
  • 現状の認識: エディタはSSRもルーティングもほぼ使わないので、Nuxtは不要。素のVue/Reactを想定している(未決)
  • 現状の認識: 描画はSVGが有力。<g> の入れ子変換がPHYの Translate · Rotate と同じ定義で、クリック判定と画面→ローカル座標の逆変換(getScreenCTM)をブラウザに任せられる。文字の折り返しは自前になる。試作はしていない
  • 格上げ条件: ユーザーが選ぶ。描画方式は、回転したクラスター内のキーのドラッグを試作して確かめる

P-3 リポジトリ構成

  • 位置づけ: 未解決の問い。モノレポにするか、パッケージをどう分割するか
  • 格上げ条件: P-2 の決定後に、ユーザーと分割単位を決める