初期検討段階のドキュメントと運用ルールを取り込む
ルール策定前に書かれた設計ドキュメント7点を、以降の基準点として そのままの状態で記録する。CLAUDE.md のルール1〜4は未適用。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MdLT5x5ka5y6CaWLeE3EKb
This commit is contained in:
Claude Opus 5
@@ -0,0 +1,167 @@
|
||||
# Beyond KLE: キーボード設計レイヤー構造とツール設計方針
|
||||
|
||||
## 背景
|
||||
|
||||
### KLEの問題点
|
||||
|
||||
- **物理配置と論理構造の混同**: y座標や回転角度で行を判定するため、カラムスタッガードや曲線配列で大量の行が生成される
|
||||
- **データモデルの限界**: 物理配置(PHY)のみを扱い、マトリックス座標やキーマップ情報を保持できない
|
||||
- **VIAのhackyな対応**: ラベルフィールドに"1,5"と入れて`matrix:[1,5]`を表現
|
||||
|
||||
### 設計思想
|
||||
|
||||
- 「Better KLE」ではなく「Beyond KLE」: UIではなくデータモデルとワークフロー全体の再設計
|
||||
- UNIX哲想の適用: 小さな役割のツールがそれぞれしっかり機能する
|
||||
- 統合環境(IDE)の提供: 独立したツール群をオーケストレート
|
||||
|
||||
## レイヤー構造
|
||||
|
||||
### 1. PHYレイヤー (物理配置)
|
||||
|
||||
- **役割**: キーの物理的な位置、サイズ、回転
|
||||
- **対応ツール**: PCBエディタ、KLE
|
||||
- **出力**: 座標とキーサイズの配列
|
||||
|
||||
### 2. ELCレイヤー (電気配線)
|
||||
|
||||
- **役割**: マイコンのpinと各キーの対応
|
||||
- **対応ツール**: 回路図エディタ、ファームウェア
|
||||
- **出力**: ピン配列定義、マトリックス配線情報
|
||||
- **備考**: charlieplexingなど非標準的な実装にも対応
|
||||
|
||||
### 3. IDXレイヤー (キー識別)
|
||||
|
||||
- **役割**: 物理位置と"キー番号"の対応付け
|
||||
- **重要性**: 物理世界と論理世界を繋ぐ最も重要な抽象化層
|
||||
- **出力**: `{x, y, matrix:[row,col], label}[]`
|
||||
- **備考**: 現状のエコシステムで最も欠けている層
|
||||
|
||||
### 4. MAPレイヤー (キーマップ)
|
||||
|
||||
- **役割**: キー番号とキーコードの対応
|
||||
- **対応ツール**: ファームウェア、VIA、Remap
|
||||
- **出力**: レイヤー別キーコード配列
|
||||
|
||||
### 5. IMEレイヤー (入力変換)
|
||||
|
||||
- **役割**: キーコードと実際の入力文字の対応
|
||||
- **対応ツール**: OS
|
||||
- **備考**: MAPレイヤー設計時に考慮が必要
|
||||
|
||||
## ツール設計方針
|
||||
|
||||
### 個別ツール (独立動作可能)
|
||||
|
||||
#### PHY Editor
|
||||
|
||||
- 物理配置の視覚的編集
|
||||
- KLE互換フォーマット対応
|
||||
- 出力: PHY JSON
|
||||
|
||||
#### Matrix Mapper
|
||||
|
||||
- PHY Editorの出力を入力
|
||||
- キーにrow/colを割り当て
|
||||
- 視覚的にマトリックス配線を確認
|
||||
- 出力: IDX JSON
|
||||
|
||||
#### Pin Configurator
|
||||
|
||||
- マトリックス定義を入力
|
||||
- マイコンのピン配置を指定
|
||||
- 配線図を出力
|
||||
- 出力: ELC JSON
|
||||
|
||||
#### Keymap Designer
|
||||
|
||||
- キー識別子リストを入力
|
||||
- レイヤー別キーコード割り当て
|
||||
- VIA/Remapとの互換性
|
||||
- 出力: MAP JSON
|
||||
|
||||
#### Firmware Generator
|
||||
|
||||
- 全レイヤーの情報を統合
|
||||
- QMK/VIA/KMK等へ変換
|
||||
- 出力: ターゲット固有の設定ファイル
|
||||
|
||||
### 統合環境 (IDE)
|
||||
|
||||
- **プロジェクトファイル**: 全レイヤーの状態を一元管理
|
||||
- **リアルタイムプレビュー**: レイヤー間の依存関係を可視化
|
||||
- **バージョン管理統合**: テキストベース定義でgit管理
|
||||
- **ワークフローサポート**: ガイド付きウィザード、テンプレート
|
||||
|
||||
## プロトコル設計
|
||||
|
||||
### レイヤー間インターフェース
|
||||
|
||||
```txt
|
||||
PHY → IDX
|
||||
Input: KLE JSON (or compatible)
|
||||
Output: Augmented layout (coordinates + key IDs)
|
||||
|
||||
IDX → ELC
|
||||
Input: Key ID list
|
||||
Output: Matrix definition + Pin mapping
|
||||
|
||||
IDX → MAP
|
||||
Input: Key ID list
|
||||
Output: Keymap arrays
|
||||
|
||||
All → Firmware
|
||||
Output: QMK keyboard.json / VIA JSON / KMK .py
|
||||
```
|
||||
|
||||
### データフォーマット
|
||||
|
||||
- JSON Schema で各レイヤーの入出力を定義
|
||||
- 後方互換性の維持 (KLE JSONからのインポート)
|
||||
- 拡張可能な設計 (3D配置、非標準マトリックス対応)
|
||||
|
||||
## 実装戦略
|
||||
|
||||
### Phase 1: プロトコル策定
|
||||
|
||||
- JSON Schemaでフォーマット定義
|
||||
- TypeScriptでリファレンス実装
|
||||
- CLIツールとして動作確認
|
||||
|
||||
### Phase 2: 個別ツール開発
|
||||
|
||||
- 各レイヤー用エディタを独立開発
|
||||
- 既存ツールからのインポート機能
|
||||
- 単独利用可能な設計
|
||||
|
||||
### Phase 3: IDE統合
|
||||
|
||||
- Electron/Tauri or Webアプリ
|
||||
- プロジェクト管理機能
|
||||
- ワークフロー支援
|
||||
|
||||
## 既存ツールとの関係
|
||||
|
||||
- **KLE**: PHY Editorの一実装、インポート対応
|
||||
- **VIA/Remap**: MAP Layerクライアントとして連携
|
||||
- **QMK Configurator**: Firmware Generatorのターゲット
|
||||
|
||||
## 配慮事項
|
||||
|
||||
### 学習コスト
|
||||
|
||||
- テンプレートプロジェクト提供 (60%, Split等)
|
||||
- 簡易モード/詳細モードの切り替え
|
||||
- 段階的な機能開示
|
||||
|
||||
### 互換性
|
||||
|
||||
- 既存KLE JSONの完全サポート
|
||||
- 段階的移行パスの提供
|
||||
- レガシーツールとの共存
|
||||
|
||||
## 次のステップ
|
||||
|
||||
1. プロトコル仕様ドラフト作成
|
||||
2. GitHubでRFCリポジトリ立ち上げ
|
||||
3. 小規模コミュニティでフィードバック収集
|
||||
4. リファレンス実装の開発
|
||||
Reference in New Issue
Block a user