ewderna/Beyond-KLE
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
継続行がスペース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
This commit is contained in:
ewderna
2026-10-19 08:16:12 +09:00
co-authored by Claude Opus 5.5
parent 5c9f4c75ab
commit 85f333cb24
36 changed files with 280 additions and 258 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/decide/SKILL.md
+3 -3
View File
@@ -28,11 +28,11 @@ argument-hint: [決定の要旨]
- 採用した案・現在の設定を書く。「なぜAなのか」は1〜3行まで。
- 「なぜBではないのか」は書かない。代わりに**制約文**として書く。
- ✗ `B案はKLEパーサーが壊れるので却下した`
- ○ `クラスター情報はKLE JSONに出力しない(KLE互換性の制約)`
- ✗ `B案はKLEパーサーが壊れるので却下した`
- ○ `クラスター情報はKLE JSONに出力しない(KLE互換性の制約)`
- 比較表・検討過程・ベンチマーク結果をここに書かない。
- 他の担当の詳細を外へ移したあとも、この文書だけで担当範囲が分かるか確認する。
境界の理解に必要な一文と参照は残す。参照先の仕様は複製しない。
境界の理解に必要な一文と参照は残す。参照先の仕様は複製しない。
### 2. 非採用一覧に残す案を選ぶ
.agents/skills/doc-lint/SKILL.md
+16 -16
View File
@@ -23,7 +23,7 @@ ERROR があれば終了コード 1。存在しない引数のファイルもERR
検出する項目:
| 種別 | 内容 |
|---|---|
| --- | --- |
| ERROR | 本文の `[推測:P-n]` に対応する `## 未確認事項` の項目がない |
| ERROR | 本文の推測タグに対応する項目に `- 格上げ条件:` の内容がない |
| ERROR | タグのない未確認事項に `- 格上げ条件:` または `- 完了条件:` の内容がない |
@@ -61,28 +61,28 @@ WARNから課題の追加や本文の削除を自動決定しない。
こちらが本体。ファイルを読んで判断する。
- **「なぜBではないのか」が理由として残っていないか。**
却下理由ではなく、現在効いている制約として書かれているか。
- ✗ `階層構造はKLEが非対応なので諦めた`
- ○ `階層クラスターはKLE JSONに出力しない(KLE互換性の制約)`
却下理由ではなく、現在効いている制約として書かれているか。
- ✗ `階層構造はKLEが非対応なので諦めた`
- ○ `階層クラスターはKLE JSONに出力しない(KLE互換性の制約)`
- **本文が前提にする未確認の記述にタグが付いているか。** 検査項目の中で最も重要で、
機械では判定できない。「〜できるはず」「〜と考えられる」「実現可能」で実際に試していない
記述を探し、`[推測:P-n]` が付いているか確認する。
機械では判定できない。「〜できるはず」「〜と考えられる」「実現可能」で実際に試していない
記述を探し、`[推測:P-n]` が付いているか確認する。
- **同じ事実が複数ドキュメントに複製されていないか。** 片方だけ古くなる。
- **他の担当の説明を移した結果、責務の境界まで消えていないか。**
この文書だけで担当範囲が分かるための一文と参照は残し、他の担当の詳細仕様は参照先で管理する。
この文書だけで担当範囲が分かるための一文と参照は残し、他の担当の詳細仕様は参照先で管理する。
- **非採用一覧の各項目は、将来のどんな再提案を防ぐか。**
本文の制約で十分か、実際に検討した別方針として経緯への入口が必要かを判断する。
件数・古さ・重複だけで一律に追加・削除しない。
本文の制約で十分か、実際に検討した別方針として経緯への入口が必要かを判断する。
件数・古さ・重複だけで一律に追加・削除しない。
- **本文の未決記述は、読者に何を伝えるためにあるか。**
現在の対応範囲は本文に残し、問いの詳細は未確認事項へ集約する。
対応項目へのリンク、必要な課題の追加、不要な言及の削除のいずれかを判断する。
リンクが存在しても、その問いが本文の内容に対応するかは目視で確認する。
現在の対応範囲は本文に残し、問いの詳細は未確認事項へ集約する。
対応項目へのリンク、必要な課題の追加、不要な言及の削除のいずれかを判断する。
リンクが存在しても、その問いが本文の内容に対応するかは目視で確認する。
- **保留中の対応範囲が仕様本文にあるか。** 現在の実装が答えに依存する前提をbacklogへ隠していないか。
- **再開条件・完了条件が具体的か。** 仕様書の保留課題リンクは該当区分に向き、解決済みの課題が残っていないか。
- **journal の冒頭20行で、結論と選択肢が分かるか。** 見出しの有無ではなく中身を読む。
- **コミット規約**(必要なら `git log --oneline` を見る)
- 1コミット1決定になっているか
- journal を伴う決定のメッセージに `Journal:` 行があるか
- 1コミット1決定になっているか
- journal を伴う決定のメッセージに `Journal:` 行があるか
## 3. 報告する
@@ -94,8 +94,8 @@ WARNから課題の追加や本文の削除を自動決定しない。
## 注意
- 既存ドキュメントへのルール適用は段階的に進めている。
WARN が大量に出るのは想定内で、再編(`/restructure-doc`)のタイミングで解消する。
再編前のファイルの WARN を個別に直そうとしない。
WARN が大量に出るのは想定内で、再編(`/restructure-doc`)のタイミングで解消する。
再編前のファイルの WARN を個別に直そうとしない。
スクリプトを変更した場合の回帰検査:
.agents/skills/restructure-doc/SKILL.md
+4 -4
View File
@@ -29,7 +29,7 @@ argument-hint: <ファイル名>
各ブロック(見出し単位、または段落単位)を次のどれかに分ける。
| 分類 | 行き先 |
|---|---|
| --- | --- |
| a. 採用した案 / 現在の設定 / 設計に影響する制約 | メインドキュメントに残す |
| b. 裏取りの済んだ事実 | メインドキュメントに残す(文中のどこでもよい) |
| c. 未確認の推測・未解決の問い | メインドキュメント末尾の `## 未確認事項` |
@@ -50,8 +50,8 @@ argument-hint: <ファイル名>
- a を中心に再構成する。b は文中に自然に置く。
- 「なぜBではないのか」の記述が残っていたら、**制約文**に書き換える。
- ✗ `階層構造はKLEが非対応なので諦めた`
- ○ `階層クラスターはKLE JSONに出力しない(KLE互換性の制約)`
- ✗ `階層構造はKLEが非対応なので諦めた`
- ○ `階層クラスターはKLE JSONに出力しない(KLE互換性の制約)`
- 落とした案があれば末尾 `## 検討済み・非採用` に1案1行(理由なし、journalファイル名を参照)。
### 5. 未確認事項を立てる
@@ -92,5 +92,5 @@ Journal: journal/2026-09-16-<元ファイル名>.md
## 注意
- 複数ファイルを一度に触らない。ファイル間で内容が重複していると気づいた場合は、
勝手に統合せず、指摘だけしてそのファイルの再編を終える。
勝手に統合せず、指摘だけしてそのファイルの再編を終える。
- 再編の途中で事実関係の誤りを見つけても、勝手に直さない。指摘する。
.claude/skills/decide/SKILL.md
+3 -3
View File
@@ -28,11 +28,11 @@ argument-hint: [決定の要旨]
- 採用した案・現在の設定を書く。「なぜAなのか」は1〜3行まで。
- 「なぜBではないのか」は書かない。代わりに**制約文**として書く。
- ✗ `B案はKLEパーサーが壊れるので却下した`
- ○ `クラスター情報はKLE JSONに出力しない(KLE互換性の制約)`
- ✗ `B案はKLEパーサーが壊れるので却下した`
- ○ `クラスター情報はKLE JSONに出力しない(KLE互換性の制約)`
- 比較表・検討過程・ベンチマーク結果をここに書かない。
- 他の担当の詳細を外へ移したあとも、この文書だけで担当範囲が分かるか確認する。
境界の理解に必要な一文と参照は残す。参照先の仕様は複製しない。
境界の理解に必要な一文と参照は残す。参照先の仕様は複製しない。
### 2. 非採用一覧に残す案を選ぶ
.claude/skills/doc-lint/SKILL.md
+16 -16
View File
@@ -23,7 +23,7 @@ ERROR があれば終了コード 1。存在しない引数のファイルもERR
検出する項目:
| 種別 | 内容 |
|---|---|
| --- | --- |
| ERROR | 本文の `[推測:P-n]` に対応する `## 未確認事項` の項目がない |
| ERROR | 本文の推測タグに対応する項目に `- 格上げ条件:` の内容がない |
| ERROR | タグのない未確認事項に `- 格上げ条件:` または `- 完了条件:` の内容がない |
@@ -61,28 +61,28 @@ WARNから課題の追加や本文の削除を自動決定しない。
こちらが本体。ファイルを読んで判断する。
- **「なぜBではないのか」が理由として残っていないか。**
却下理由ではなく、現在効いている制約として書かれているか。
- ✗ `階層構造はKLEが非対応なので諦めた`
- ○ `階層クラスターはKLE JSONに出力しない(KLE互換性の制約)`
却下理由ではなく、現在効いている制約として書かれているか。
- ✗ `階層構造はKLEが非対応なので諦めた`
- ○ `階層クラスターはKLE JSONに出力しない(KLE互換性の制約)`
- **本文が前提にする未確認の記述にタグが付いているか。** 検査項目の中で最も重要で、
機械では判定できない。「〜できるはず」「〜と考えられる」「実現可能」で実際に試していない
記述を探し、`[推測:P-n]` が付いているか確認する。
機械では判定できない。「〜できるはず」「〜と考えられる」「実現可能」で実際に試していない
記述を探し、`[推測:P-n]` が付いているか確認する。
- **同じ事実が複数ドキュメントに複製されていないか。** 片方だけ古くなる。
- **他の担当の説明を移した結果、責務の境界まで消えていないか。**
この文書だけで担当範囲が分かるための一文と参照は残し、他の担当の詳細仕様は参照先で管理する。
この文書だけで担当範囲が分かるための一文と参照は残し、他の担当の詳細仕様は参照先で管理する。
- **非採用一覧の各項目は、将来のどんな再提案を防ぐか。**
本文の制約で十分か、実際に検討した別方針として経緯への入口が必要かを判断する。
件数・古さ・重複だけで一律に追加・削除しない。
本文の制約で十分か、実際に検討した別方針として経緯への入口が必要かを判断する。
件数・古さ・重複だけで一律に追加・削除しない。
- **本文の未決記述は、読者に何を伝えるためにあるか。**
現在の対応範囲は本文に残し、問いの詳細は未確認事項へ集約する。
対応項目へのリンク、必要な課題の追加、不要な言及の削除のいずれかを判断する。
リンクが存在しても、その問いが本文の内容に対応するかは目視で確認する。
現在の対応範囲は本文に残し、問いの詳細は未確認事項へ集約する。
対応項目へのリンク、必要な課題の追加、不要な言及の削除のいずれかを判断する。
リンクが存在しても、その問いが本文の内容に対応するかは目視で確認する。
- **保留中の対応範囲が仕様本文にあるか。** 現在の実装が答えに依存する前提をbacklogへ隠していないか。
- **再開条件・完了条件が具体的か。** 仕様書の保留課題リンクは該当区分に向き、解決済みの課題が残っていないか。
- **journal の冒頭20行で、結論と選択肢が分かるか。** 見出しの有無ではなく中身を読む。
- **コミット規約**(必要なら `git log --oneline` を見る)
- 1コミット1決定になっているか
- journal を伴う決定のメッセージに `Journal:` 行があるか
- 1コミット1決定になっているか
- journal を伴う決定のメッセージに `Journal:` 行があるか
## 3. 報告する
@@ -94,8 +94,8 @@ WARNから課題の追加や本文の削除を自動決定しない。
## 注意
- 既存ドキュメントへのルール適用は段階的に進めている。
WARN が大量に出るのは想定内で、再編(`/restructure-doc`)のタイミングで解消する。
再編前のファイルの WARN を個別に直そうとしない。
WARN が大量に出るのは想定内で、再編(`/restructure-doc`)のタイミングで解消する。
再編前のファイルの WARN を個別に直そうとしない。
スクリプトを変更した場合の回帰検査:
.claude/skills/restructure-doc/SKILL.md
+4 -4
View File
@@ -29,7 +29,7 @@ argument-hint: <ファイル名>
各ブロック(見出し単位、または段落単位)を次のどれかに分ける。
| 分類 | 行き先 |
|---|---|
| --- | --- |
| a. 採用した案 / 現在の設定 / 設計に影響する制約 | メインドキュメントに残す |
| b. 裏取りの済んだ事実 | メインドキュメントに残す(文中のどこでもよい) |
| c. 未確認の推測・未解決の問い | メインドキュメント末尾の `## 未確認事項` |
@@ -50,8 +50,8 @@ argument-hint: <ファイル名>
- a を中心に再構成する。b は文中に自然に置く。
- 「なぜBではないのか」の記述が残っていたら、**制約文**に書き換える。
- ✗ `階層構造はKLEが非対応なので諦めた`
- ○ `階層クラスターはKLE JSONに出力しない(KLE互換性の制約)`
- ✗ `階層構造はKLEが非対応なので諦めた`
- ○ `階層クラスターはKLE JSONに出力しない(KLE互換性の制約)`
- 落とした案があれば末尾 `## 検討済み・非採用` に1案1行(理由なし、journalファイル名を参照)。
### 5. 未確認事項を立てる
@@ -92,5 +92,5 @@ Journal: journal/2026-09-16-<元ファイル名>.md
## 注意
- 複数ファイルを一度に触らない。ファイル間で内容が重複していると気づいた場合は、
勝手に統合せず、指摘だけしてそのファイルの再編を終える。
勝手に統合せず、指摘だけしてそのファイルの再編を終える。
- 再編の途中で事実関係の誤りを見つけても、勝手に直さない。指摘する。
.vscode/settings.json
Vendored
+7
View File
@@ -0,0 +1,7 @@
{
"[markdown]": {
"editor.detectIndentation": false,
"editor.tabSize": 4,
"editor.insertSpaces": true
}
}
CLAUDE.md
+24 -24
View File
@@ -9,7 +9,7 @@ PHY(物理配置) / ELC(電気配線) / IDX(キー識別) / MAP(キーマップ)
## ドキュメント地図
| ファイル | 内容 |
|---|---|
| --- | --- |
| `keyboard-design-layers.md` | レイヤー構造とツール分割方針(最上位) |
| `PHYレイヤー.md` | PHY層の仕様 |
| `ELCレイヤー.md` | ELC層の仕様 |
@@ -40,13 +40,13 @@ PHY(物理配置) / ELC(電気配線) / IDX(キー識別) / MAP(キーマップ)
- 複数案から選んだ場合、「なぜAなのか」を1〜3行で書く。「なぜBではないのか」は書かない。
- 却下案の比較表・検討過程・ベンチマーク結果はここに置かない(→ `journal/`)。
- 却下案の再提案を防ぐ情報は、比較ではなく**制約文**として書く。
- ✗ `B案はKLEパーサーが壊れるので却下した`
- ○ `クラスター情報はKLE JSONに出力しない(KLE互換性の制約)`
- ✗ `B案はKLEパーサーが壊れるので却下した`
- ○ `クラスター情報はKLE JSONに出力しない(KLE互換性の制約)`
- 落とした案があれば、末尾に `## 検討済み・非採用` を置き、**1案1行**で残す。理由は書かず、journalファイル名を参照する。
- 例: `- labels[9] へのID埋め込み (journal/2026-09-16-cluster-metadata.md)`
- コミットは `git log --oneline -- journal/2026-09-16-cluster-metadata.md` で引ける(journal削除後も追跡可)
- 載せるのは、実際に検討した別方針のうち再提案されうるものに限る。本文の制約文で足りるなら重複させない。
- 目安5行まで。増えたら、再提案を防ぐ必要性が低いものから落とす。長くなるのは書きすぎのサイン。
- 例: `- labels[9] へのID埋め込み (journal/2026-09-16-cluster-metadata.md)`
- コミットは `git log --oneline -- journal/2026-09-16-cluster-metadata.md` で引ける(journal削除後も追跡可)
- 載せるのは、実際に検討した別方針のうち再提案されうるものに限る。本文の制約文で足りるなら重複させない。
- 目安5行まで。増えたら、再提案を防ぐ必要性が低いものから落とす。長くなるのは書きすぎのサイン。
### 2. 履歴と根拠
@@ -54,13 +54,13 @@ PHY(物理配置) / ELC(電気配線) / IDX(キー識別) / MAP(キーマップ)
- **なぜそう決めたか / 調査 / 案の比較** → `journal/` に置き、その決定と**同じコミット**に含める。
- コミットメッセージ末尾に参照を1行入れる: `Journal: journal/2026-09-16-cluster-metadata.md`
- journal は作業ツリーから削除する前提(人間にとってのノイズになるため)。履歴には残るので、
削除後は `git show <sha>:journal/...` で読む。
削除後は `git show <sha>:journal/...` で読む。
### 3. journal の書き方
- 1ファイル1トピック。`journal/YYYY-MM-DD-<topic>.md`。トピックを詰め込まない。
- 構成は上から順に: **結論** → **案の比較(簡潔な表)** → 検証ログ・根拠・捨てた案。
冒頭20行で結論と選択肢が分かること。
冒頭20行で結論と選択肢が分かること。
- 他のファイルから journal へリンクを張らない。journal 同士も張らない。参照経路はコミットメッセージのみ。
- 結論がメインドキュメントに反映されたら削除してよい。
- 整形は最低限でよい。人間向けの読みやすさは要求しない。
@@ -68,15 +68,15 @@ PHY(物理配置) / ELC(電気配線) / IDX(キー識別) / MAP(キーマップ)
### 4. 事実と推測
- **裏取りの済んだ事実**は、ドキュメント内のどこに書いてもよい。文中に自然に混ぜてよい。
ただし同じ事実を複数ドキュメントに複製しない。必要ならリンクする。
ただし同じ事実を複数ドキュメントに複製しない。必要ならリンクする。
- **現在の仕様・実装が答えに依存する未確認事項**は、仕様書の末尾に残す。2種類ある:
- 本文が前提にしている推測 → 本文に `[推測:P-n]` を付け、末尾の `## 未確認事項` に対応項目を置く
- 実装前に判断が必要な未解決の問い → 本文タグなしで `## 未確認事項` に直接置く
- 本文が前提にしている推測 → 本文に `[推測:P-n]` を付け、末尾の `## 未確認事項` に対応項目を置く
- 実装前に判断が必要な未解決の問い → 本文タグなしで `## 未確認事項` に直接置く
- 本文が未決の問いに触れるときは、「未決」と書いて終わらせず該当項目へリンクする。
同一ファイル内は `[P-3](#p-3-...)`、他ファイルからは `[MAPのP-3](MAPレイヤー.md#p-3-...)` の形とする。
問いの内容は `## 未確認事項` にだけ書き、本文へ写さない(二重管理を避ける)。
同一ファイル内は `[P-3](#p-3-...)`、他ファイルからは `[MAPのP-3](MAPレイヤー.md#p-3-...)` の形とする。
問いの内容は `## 未確認事項` にだけ書き、本文へ写さない(二重管理を避ける)。
- 未確認の推測には、**何を確認できれば事実に格上げできるか**を「格上げ条件」として書く。
設計判断には、**何を決めれば解決するか**を「完了条件」として書く。意思決定を事実確認と混同しない。
設計判断には、**何を決めれば解決するか**を「完了条件」として書く。意思決定を事実確認と混同しない。
- 答えに依存せず進められる課題は `backlog/` に置く(ルール5)。保留中の対応範囲・暫定仕様は仕様書に残す。
- 検証できたらタグを外し、該当項目を削除する。
- 「今回検討して捨てた仮説」は `## 未確認事項` に書かない。journal に残して消す。
@@ -98,20 +98,20 @@ PHY(物理配置) / ELC(電気配線) / IDX(キー識別) / MAP(キーマップ)
- 当面は `backlog/README.md` にまとめる。増えて読みにくくなったらレイヤー別・トピック別に分ける。
- 項目には、関連仕様・未決事項・保留できる理由・再開条件・完了条件を書く。
再開条件は「いつ考え直すか」、完了条件は「何を確認または決定すれば終わるか」を示す。
再開条件は「いつ考え直すか」、完了条件は「何を確認または決定すれば終わるか」を示す。
- 仕様書から移す項目は、元の番号にレイヤー名などを付けて識別する(例: `PHY-P-14`)。
判断に必要な候補や制約は短く残す。長い比較・調査ログは `journal/` に置く。
判断に必要な候補や制約は短く残す。長い比較・調査ログは `journal/` に置く。
- 問いの本文は二重管理しない。仕様書には保留中の対応範囲・暫定仕様を残し、必要に応じてbacklogへリンクする。
- 仕様書から保留課題を分離した場合、末尾の管理セクションを `## 保留課題` → `## 検討済み・非採用` →
`## 未確認事項` の順に置く(存在するものだけ)。`## 保留課題` には下記のリンク箇条書きだけを書く。
項目名の列挙・問いの要約・保留理由・対応範囲は書かない。対応範囲は仕様本文、問いの詳細はbacklogに置く。
`## 未確認事項` の順に置く(存在するものだけ)。`## 保留課題` には下記のリンク箇条書きだけを書く。
項目名の列挙・問いの要約・保留理由・対応範囲は書かない。対応範囲は仕様本文、問いの詳細はbacklogに置く。
- リンクは `- [<区分>の保留課題](backlog/README.md#<区分の見出し>)` の形とする。
分割後は該当するbacklogファイルへ向ける。複数区分を参照する場合は1リンク1行とし、参照先の見出しまで指定する。
該当課題がなくなったらリンクを削除し、空になった `## 保留課題` はセクションごと削除する。
分割後は該当するbacklogファイルへ向ける。複数区分を参照する場合は1リンク1行とし、参照先の見出しまで指定する。
該当課題がなくなったらリンクを削除し、空になった `## 保留課題` はセクションごと削除する。
- 現在の仕様が依存する未確認の前提は、backlogへ移して隠さない。仕様書の `## 未確認事項` に残す。
- backlogへの移動は仮説の採用や実装の許可を意味しない。実装は採用済みの仕様・対応範囲に従う。
- 解決したら必要な結論を仕様書へ反映し、項目と不要になった参照を削除する。取り下げた項目も削除し、完了一覧は蓄積しない。
調査・判断の経緯はルール2・3に従って履歴に残す。
調査・判断の経緯はルール2・3に従って履歴に残す。
- 未解決の課題は作業ツリーに残す。結論反映後に削除できるjournalとは寿命が異なる。
仕様書側の書式:
@@ -128,8 +128,8 @@ PHY(物理配置) / ELC(電気配線) / IDX(キー識別) / MAP(キーマップ)
- 調査タスクの結果は、結論だけをメインドキュメントに書き、調査過程は `journal/` に落とす。
- 既存ドキュメントの記述と食い違う事実を見つけたら、勝手に上書きせず指摘する。
- Markdownをコミットする前に、変更したファイルへ `npx markdownlint-cli2 --fix <files>` をかける。
エディタが保存時に同じ修正を入れるため、かけずにコミットするとコミット直後に差分が出る。
規則は `.markdownlint.jsonc`。変更していないファイルの指摘は直さない。
エディタが保存時に同じ修正を入れるため、かけずにコミットするとコミット直後に差分が出る。
規則は `.markdownlint.jsonc`。変更していないファイルの指摘は直さない。
## 未確認事項
HSTレイヤー.md
+8 -8
View File
@@ -20,7 +20,7 @@ HSTのデータは、ホスト環境ごとのプロファイルの集まりと
プロファイルは、OSとホスト配列の組で識別する。必要な場合だけ、入力方式やその設定を加える。
- ホスト配列は、OSがキーコードを解釈するための配列の設定である。キーキャップの刻印やOSの表示言語とは独立に決まる
(日本語のWindowsで英語配列を設定する、など)。
(日本語のWindowsで英語配列を設定する、など)。
- Linux(XKB)では、配列(layout)・変種(variant)・オプション(options)の組になる。
- `win-jp` のような短い名前は、人が選ぶためのプリセット名として付ける。
- 各OSの識別子(WindowsのKLID、XKBの名前、macOSの入力ソースID)と対応付けられるようにする。
@@ -43,7 +43,7 @@ IMEが今ONか、のような実行時の状態は識別に含めない(次節
```
- ホスト状態: CapsLock、かなロック、IMEのON/OFFなど、同じキーコードの結果を変える状態。
HSTは状態の種類を引数として記述するだけで、実行時の状態を観測しない。
HSTは状態の種類を引数として記述するだけで、実行時の状態を観測しない。
- OS固有のキーの意味: `LANG1`/`LANG2`(Macのかな/英数)、変換/無変換、Cmd/Ctrlの役割など。
- 成立の前提: 動作に必要なOS側の設定(Unicode入力の方式など)。HSTは設定を変更する機能を持たない。
- 対応可否: 対応済み・未対応・不明の3値とする。カタログに載っていない動作を「使えない」と扱わない。
@@ -55,9 +55,9 @@ HSTは逆引き(文字から、それを入力するキー操作を求めるこ
- 順方向の表から導けるので、両方を持つと二重管理になる。
- 逆引きの候補には、ファームウェアの機能に依存するものがある。
例えば、US刻印のキーキャップをJIS配列のホストで使う場合、Shiftの有無で文字の組が合わないキーには、
Shift時に別のキーコードを送る機能(QMKのKey Override)が必要になる。
これはホストの知識ではないため、HSTに持たせない。
例えば、US刻印のキーキャップをJIS配列のホストで使う場合、Shiftの有無で文字の組が合わないキーには、
Shift時に別のキーコードを送る機能(QMKのKey Override)が必要になる。
これはホストの知識ではないため、HSTに持たせない。
使う側の担当は次のとおり。
@@ -67,7 +67,7 @@ HSTは逆引き(文字から、それを入力するキー操作を求めるこ
## MAPとの境界
- MAPは具体的なキーコードを保存する。逆引きは編集時の入力補助であり、選んだ候補のキーコードをMAPへ書く一方向の変換とする。
実機に残るのはキーコードだけなので、この形なら実機との往復を単純に保てる。
実機に残るのはキーコードだけなので、この形なら実機との往復を単純に保てる。
- HSTは割り当てを所有・変更しない。PHYのキーIDも参照しない。
## 対象外
@@ -88,10 +88,10 @@ HSTは逆引き(文字から、それを入力するキー操作を求めるこ
- 位置づけ: 本文「使う側の責務」が前提にしている。HSTにファームウェアの知識を持たせない線引きは、これが成り立つことに依存する。
- 格上げ条件: US刻印のキーキャップをJIS配列のホストで使う構成で、Shiftの有無で文字の組が合わないキーについて、
HSTの順方向の表と、Generatorのビルド設定(有効な機能)だけから、MAPエディタがKey Overrideを含む候補を作れることを試作で確認する。
HSTの順方向の表と、Generatorのビルド設定(有効な機能)だけから、MAPエディタがKey Overrideを含む候補を作れることを試作で確認する。
### P-2 対象ホストを複数持つか
- 位置づけ: 未解決の問い。Win/Mac両用のキーボードでは、表示と検証を複数のホストに対して行う必要がある。
OSの切り替えをMAPのレイヤーで表す既存の慣習と、どう対応付けるかも関わる。
OSの切り替えをMAPのレイヤーで表す既存の慣習と、どう対応付けるかも関わる。
- 完了条件: プロジェクトが参照するプロファイルの数と、MAPのレイヤーとの対応付けの有無をユーザーが決める。
IDXレイヤー.md
+1 -1
View File
@@ -36,7 +36,7 @@ PHYの座標・ツリー順をキー番号に使わない。
ELCのマトリクス位置をキー番号に使わない。
- マトリクスの並びとキー番号の並びは一致しない。分割キーボードでは、マトリクスは片方の半身の行を
並べてからもう片方の行を並べるが、キー番号は視覚的な行ごとに左右を交互に取るのが通例である
並べてからもう片方の行を並べるが、キー番号は視覚的な行ごとに左右を交互に取るのが通例である
- マトリクスには欠番がある。キー番号は実在するキーに対して連続だが、マトリクスは疎である
- 基板リビジョンでピンを差し替えたときに、キー番号が動いてはならない
MAPレイヤー.md
+1 -1
View File
@@ -111,7 +111,7 @@ VIAプロトコル0x000Dのコマンドのうち、MAPエディタが扱うも
- エンコーダの割り当て([MAP-P-4](backlog/README.md#map-p-4-onoff以外の入力への割り当て))
- layout option([P-3](#p-3-プロジェクトと実機の対応状態管理))
- 当面対応しない: キーマップ・EEPROMのリセット、ブートローダへの移行、デバイスの識別表示、
マトリクス状態の読み出し(キーテスター)、custom channel(照明・オーディオ・キーボード独自メニュー)
マトリクス状態の読み出し(キーテスター)、custom channel(照明・オーディオ・キーボード独自メニュー)
実機のファームウェアでどの機能が有効かは、VIAでは読み出せない。
新規キーボードではFirmware Generatorのビルド設定を正とする。既存キーボードでは、利用者が同じ形式で申告した内容を信用する。
PHYレイヤー.md
+4 -4
View File
@@ -153,7 +153,7 @@ PHYは全バリアントのキーを同時に持つ。基板上のフットプ
- Variantの中に別のVariantGroupを置ける。あるバリアントを選んだときだけ現れる選択肢を表す
- 選択箇所が複数ある場合はVariantGroupを複数置く。同じ親の下に並べてよい
- 選択が互いに独立なら、VariantGroupを分けて選択肢の数を減らしてよい。
ANSI/ISOとBackspaceの分割のように、独立な2つの選択が1つの選択肢リストに畳まれている基板がある
ANSI/ISOとBackspaceの分割のように、独立な2つの選択が1つの選択肢リストに畳まれている基板がある
VariantGroupはクラスターと同じ変換を持つ。Variantは変換を持たない。
バリアントは同じ場所を占める代替物であり、選択によって配下の絶対配置が動く構造を作らないため。
@@ -198,7 +198,7 @@ Transform は回転と平行移動だけを持つ剛体変換であり、合成
- 組み替えの対象は同一の親を持つノードに限る。複数の親にまたがる選択は組み替えできない
- クラスター化したときの初期値は、原点を選択の境界矩形の左上、基準角度を0とする。
ただし選択したノード全部が同じ回転角度を持つ場合はその角度を基準角度に採り、境界矩形もその角度の座標系で取る
ただし選択したノード全部が同じ回転角度を持つ場合はその角度を基準角度に採り、境界矩形もその角度の座標系で取る
- 組み替えで生じた非グリッド値はそのまま保持する。クラスターを解除して親に戻ったノードも同じ
当面、reframeは通常の移動・回転と別の明示的な操作とし、原点の指定は数値入力で行う。
@@ -336,14 +336,14 @@ const kleData = (ConfigObject | KeyLabel)[][]
- 回転角度は正規化せずそのまま出力する。KLEのデータは任意の角度を受け付け、15度刻みはKLEのUI上の操作単位にすぎない
- rx, ry はPHYに持たないので、出力時に選ぶ。同じ絶対角度を持つキーには共通の値を与える
(クラスターの原点が使える)。KLEが1行にまとめるのは r, rx, ry が一致し y が等しいキーだけという制約による
(クラスターの原点が使える)。KLEが1行にまとめるのは r, rx, ry が一致し y が等しいキーだけという制約による
- 書き出す x, y は丸める。行のまとまりは y の厳密一致で決まるので、絶対座標への変換で入った誤差が残ると行が割れる
- ユニットサイズ(mm)、ビジュアルオフセット、クラスター構造、部品ノード、per-key LEDはKLE JSONに出力されない
- バリアント構造はKLE JSONに出力しない。VariantGroupごとにバリアントを1つ選び、その配下だけを畳んで出力する
- 部品グループ・スイッチの向きはKLE JSONに出力しない。sm, sb, st には取り込み時に保持した値をそのまま書き戻す
- r, rx, ry は行の先頭にのみ置く。KLE本家はそれ以外の位置に置かれたものを読まない
- p, sm, sb, st は空文字に戻す指定がKLE側で無視される。値を持つキーと持たないキーが混在する配置は、
KLEで開いた時点で後続のキーに前の値が残る
KLEで開いた時点で後続のキーに前の値が残る
- KLEの `p` はキーキャップのプロファイル名(SA、DCSなど)であり、PHYのプロファイルとは対応させない
### KLE JSONの取り込み
backlog/README.md
+22 -22
View File
@@ -13,14 +13,14 @@
- 保留できる理由: 新規PHYとしての読み込みは、既存ノードとの照合なしで実装できる。
- 再開条件: 既存PHYへのKLE JSONの照合・更新に着手するとき。
- 完了条件: 照合規則と曖昧な候補の扱いを決め、KLE本家でキーの移動・追加・削除をしたJSONを取り込み、
意図したIDに対応づき、他レイヤーの参照を誤って付け替えないことを確認する。
意図したIDに対応づき、他レイヤーの参照を誤って付け替えないことを確認する。
### PHY-P-6 キーキャップの見た目情報を持つ層
- 関連仕様: [PHYレイヤー](../PHYレイヤー.md)「KLE JSONの取り込み」、[JSON Schema](../phase1-json-schema.md)の `kleCompatibility`
- 未決事項: キーキャップの見た目編集をBeyond KLEの範囲に含めるか、正式にはどの層で情報を持つか。
対象はキー単位の c, t, p, a, f系, l, n と、退避する sm, sb, st、ファイル単位の
switchMount, switchBrand, switchType, backcolor, radii, background, css。
対象はキー単位の c, t, p, a, f系, l, n と、退避する sm, sb, st、ファイル単位の
switchMount, switchBrand, switchType, backcolor, radii, background, css。
- 保留できる理由: 現行Schemaの `kleCompatibility` で、正式な所属層や編集機能を決めずに保持・書き戻しができる。
- 再開条件: 見た目の編集機能、または退避先から正式な所属層への移行を検討するとき。
- 完了条件: 扱う範囲と所属層をユーザーが決め、既存の退避情報を失わない保持・移行方法を定める。
@@ -71,7 +71,7 @@
- 関連仕様: [ELCレイヤー](../ELCレイヤー.md)「ピンとピン提供者」
- 未決事項: 選択ピンを共有して共通ピンを分ける構成と、enableで切り替える構成の実配線・制御方法。
どちらが一般的かは未確認。前者は複数providerの `select` に同じ `PinRef` を書く形で表現できる。
どちらが一般的かは未確認。前者は複数providerの `select` に同じ `PinRef` を書く形で表現できる。
- 保留できる理由: providerごとの参照を保存する形は維持でき、複数muxの走査出力を検証済みの構成に限定できる。
- 再開条件: 複数muxを使う構成のファームウェア出力に対応するとき。
- 完了条件: 実在のキーボードの配線でピン共有とenableの使い方を確認し、現行モデルでの表現と必要な制御を確かめる。
@@ -80,17 +80,17 @@
- 関連仕様: [ELCレイヤー](../ELCレイヤー.md)「配線トポロジを区分として持たない」
- 未決事項: 各方式で出力器が決められる走査方法と、ユーザーの追加指定が必要になる範囲。
接点マトリクスではダイオードの向き、directでは電源レールの参照から役割を判断できる範囲を確認する。
接点マトリクスではダイオードの向き、directでは電源レールの参照から役割を判断できる範囲を確認する。
- 保留できる理由: 走査方向の決定・追加指定の責任は出力器側と決まり、ELCの配線保存はそのまま進められる。
- 再開条件: 各方式のファームウェア出力に着手するとき。
- 完了条件: 対象方式の配線と整合する走査方法を確認し、必要な出力設定と対応範囲を定める。
全方式で走査手順が一意に決まることの証明は求めない。
全方式で走査手順が一意に決まることの証明は求めない。
### ELC-P-4 GPIOに直結したLEDの表し方
- 関連仕様: [ELCレイヤー](../ELCレイヤー.md)「LEDの識別番号」
- 未決事項: インジケータなど、チェーンに入らずマイコンのピンで直接点灯するLEDをELCにどう持つか。
LEDの部品ノードとピンの対応だけで足りるか、極性(ピン側がアノードかカソードか)も要るかを含む。
LEDの部品ノードとピンの対応だけで足りるか、極性(ピン側がアノードかカソードか)も要るかを含む。
- 保留できる理由: チェーン方式(WS2812系)のLEDとキーの配線は、直結LEDと独立に扱える。
- 再開条件: インジケータLEDの出力に対応するとき、またはLED配線の編集画面の仕様を作るとき。
- 完了条件: 実在の基板で直結LEDの配線を確認し、ELCでの表し方と、ファームウェア出力に必要な情報を定める。
@@ -101,12 +101,12 @@
- 関連仕様: [IDXレイヤー](../IDXレイヤー.md)「レイアウトバリアント」
- 未決事項: 採用済みの方式で既存コミュニティレイアウトの要求順を再現できる範囲の実測。
同じPHYキーIDを使う共通キー同士の要求順がレイアウト間で逆転する場合は、単一の `order` からの取捨では表せないが、その実例の有無は未確認。
同じPHYキーIDを使う共通キー同士の要求順がレイアウト間で逆転する場合は、単一の `order` からの取捨では表せないが、その実例の有無は未確認。
- 保留できる理由: 全バリアントのキーを別々の要素として並べ、選択後に番号を詰める仕様は決定済み。
既存レイアウト全般との互換性を前提にせず実装できる。
既存レイアウト全般との互換性を前提にせず実装できる。
- 再開条件: 既存コミュニティレイアウトとの互換出力を検証するとき。
- 完了条件: 実データのキーを共通キーとバリアント別のPHYキーに対応づけ、全体の `order` から各レイアウトの要求順を取捨で再現できるか確認する。
再現できないものが残る場合は、対応範囲と扱いを決める。
再現できないものが残る場合は、対応範囲と扱いを決める。
## MAP
@@ -114,9 +114,9 @@
- 関連仕様: [MAPレイヤー](../MAPレイヤー.md)「MAPデータと他レイヤーの関係」、[PHYレイヤー](../PHYレイヤー.md)「部品ノード」
- 未決事項: ロータリーエンコーダの回転のように、ON/OFFのキーではない入力へ割り当てる方法。
MAPはPHYのキーIDを参照するが、エンコーダはPHYで部品ノードとして置かれる。
参照先の種類、入力ごとの割り当て先(回転方向など)、VIAでの読み書きの対象にするかが未定。
アナログ値の解釈の所属は[全体方針のP-1](../keyboard-design-layers.md#p-1-アナログ値の解釈をどの層が持つか)で扱い、この項目とは分ける。
MAPはPHYのキーIDを参照するが、エンコーダはPHYで部品ノードとして置かれる。
参照先の種類、入力ごとの割り当て先(回転方向など)、VIAでの読み書きの対象にするかが未定。
アナログ値の解釈の所属は[全体方針のP-1](../keyboard-design-layers.md#p-1-アナログ値の解釈をどの層が持つか)で扱い、この項目とは分ける。
- 保留できる理由: キーへの割り当てと実機との読み書きは、キー以外の入力を扱わなくても実装できる。
- 再開条件: エンコーダ等を載せたキーボードの割り当てをMAPで扱うとき。
- 完了条件: 対象とする入力の種類と、MAPからの参照方法・保存形式をユーザーが決め、VIAで読み書きする場合は必要なコマンドを確認する。
@@ -125,7 +125,7 @@
- 関連仕様: [MAPレイヤー](../MAPレイヤー.md)「持たないもの」、[HSTレイヤー](../HSTレイヤー.md)
- 未決事項: MAPエディタがキーコードをどのOS配列の文字で表示するか。HSTのどのプロファイルを使うか。
少なくともUS/JISの切り替えは欲しい。利用者が増えれば他言語への対応も求められる。
少なくともUS/JISの切り替えは欲しい。利用者が増えれば他言語への対応も求められる。
- 保留できる理由: キーコードの割り当てと実機との読み書きは、表示に使うOS配列と独立して実装できる。
- 再開条件: MAPエディタの表示を実装するとき、またはHSTの[P-2](../HSTレイヤー.md#p-2-対象ホストを複数持つか)を決めるとき。
- 完了条件: 表示に使うHSTプロファイルの指定方法と置き場所をユーザーが決める。
@@ -134,18 +134,18 @@
- 関連仕様: [MAPレイヤー](../MAPレイヤー.md)「DynamicとStatic」
- 未決事項: 当面非対応としたdevelopブランチの機能とCommunity Modules(VIAモジュール以外)を、DynamicとStaticの対象に含めるか。
含める場合、developブランチのコミットの指定方法と、UIでの対応バージョンの示し方。
含める場合、developブランチのコミットの指定方法と、UIでの対応バージョンの示し方。
- 保留できる理由: QMK本家masterの公式機能だけで、Dynamicの読み書きとStaticの生成を実装できる。
- 再開条件: masterの機能だけでは足りない動作や設定が必要になったとき。
または、VIAのモジュール移行([qmk_firmware#26315](https://github.com/qmk/qmk_firmware/pull/26315))がdevelopに入ったとき。
VIAモジュールへの対応はmasterに入る前に済ませる([MAPレイヤー「DynamicとStatic」](../MAPレイヤー.md#dynamicとstatic))。
または、VIAのモジュール移行([qmk_firmware#26315](https://github.com/qmk/qmk_firmware/pull/26315))がdevelopに入ったとき。
VIAモジュールへの対応はmasterに入る前に済ませる([MAPレイヤー「DynamicとStatic」](../MAPレイヤー.md#dynamicとstatic))。
- 完了条件: 対象に含める範囲と、対応バージョンの管理方法をユーザーが決める。
### MAP-P-7 再ビルド時に実機の調整を失わないワークフロー
- 関連仕様: [MAPレイヤー](../MAPレイヤー.md)「DynamicとStatic」、[MAPのP-3](../MAPレイヤー.md#p-3-プロジェクトと実機の対応状態管理)
- 未決事項: QMK本家のVIAは、実機に保存したVIAのデータ(キーマップ・マクロ・layout option)を、ビルド日時をもとにした値で検証し、一致しなければ初期化する(`quantum/via.c` の `via_eeprom_is_valid()`。実機では未検証)。
再ビルドしたファームウェアを書き込む前に、実機の調整をプロジェクトへ読み出す手順を、ワークフローでどう保証するか。警告、読み出しの強制、Firmware Generatorとの連携などが候補。
再ビルドしたファームウェアを書き込む前に、実機の調整をプロジェクトへ読み出す手順を、ワークフローでどう保証するか。警告、読み出しの強制、Firmware Generatorとの連携などが候補。
- 保留できる理由: 実機からの読み出しとStaticの初期キーマップへの反映はすでに仕様にある。手作業の手順で運用できる。
- 再開条件: Firmware Generatorでの書き込みや、プロジェクトと実機の状態管理(P-3)を設計するとき。
- 完了条件: 再ビルドの前に実機の調整を取り込めるワークフローをユーザーが決め、書き込み後にVIAのデータが初期化されることを実機で確認する。
@@ -162,12 +162,12 @@
- 関連仕様: [MAPレイヤー](../MAPレイヤー.md)「MAPデータと他レイヤーの関係」「DynamicとStatic」、[全体方針のFirmware Generator](../keyboard-design-layers.md#firmware-generator)
- 未決事項: QMKのkeymap.jsonでは、タップダンス・コンボ・キーオーバーライドや、キーごとの設定(`get_tapping_term` 等のコールバック)を表現できない。
JSONを正本にしたままこれらをCとして生成する方法と、ユーザーが用意したC/hで一部を上書きする方法。
QMKのコールバックは1つの関数として定義するため、生成したCとユーザーのCが同じ関数を定義するとビルドできない。候補:
JSONを正本にしたままこれらをCとして生成する方法と、ユーザーが用意したC/hで一部を上書きする方法。
QMKのコールバックは1つの関数として定義するため、生成したCとユーザーのCが同じ関数を定義するとビルドできない。候補:
- 生成した関数の先頭でユーザー用のフックを呼び、フックが処理しなかった場合はJSONの値を使う(有力)
- ユーザーが引き受ける関数をJSONまたはhのプロトタイプで宣言し、Generatorはその関数を出力しない
`ACTION_TAP_DANCE_FN*` やリーダーキーのように、本質的にCで書く動作をJSONから参照する方法も含む。
MAPの「キーマップ固有のコードには原則として対応しない」との関係も整理する。
`ACTION_TAP_DANCE_FN*` やリーダーキーのように、本質的にCで書く動作をJSONから参照する方法も含む。
MAPの「キーマップ固有のコードには原則として対応しない」との関係も整理する。
- 保留できる理由: レイヤー別の割り当てとVIAでの読み書きは、keymap.jsonで表現できる範囲だけで実装できる。
- 再開条件: Firmware Generatorでタップダンス・コンボ・キーごとの設定等を出力するとき、またはP-1で動作定義とキーごとの設定の保存形式を決めるとき。
- 完了条件: 生成するCの構成と、ユーザーのC/hを組み込む方法をユーザーが決め、両方を含む構成でQMKのビルドが通ることを確認する。
journal/2026-09-18-editor-base.md
+21 -16
View File
@@ -7,14 +7,14 @@
- ijprest/keyboard-layout-editor の改造は不可。全権利留保で、作者はフォークを避けたいと明記している
- 改造の現実的な候補は adamws/kle-ng (MIT, Vue3+TS, 2026-09時点で活発)。法的には可
- ただし KLE も kle-ng も内部データはフラットな Key[] (絶対座標 + rotation_x/y)。
PHY座標モデル(相対座標の木)を採った以上、改造しても編集操作の中核は書き直しになる
PHY座標モデル(相対座標の木)を採った以上、改造しても編集操作の中核は書き直しになる
- 自作寄り。KLE JSON の読み書きはライブラリで賄える(kle-serial / kle-serial2, いずれもMIT)
- 技術選定(言語・UIフレームワーク・描画・ライブラリ)は別途やり直す。Vue案はNuxtに慣れているからというだけ(ユーザー談)
## 案の比較
| 案 | ライセンス | 流用できるもの | 書き直しになるもの |
|---|---|---|---|
| --- | --- | --- | --- |
| ijprest KLE 改造 | 全権利留保。個別許諾要 | 描画, プロパティUI | データモデル, 編集操作。AngularJS 1.2.28/bower の保守 |
| kle-ng 改造 | MIT | 描画(ISO形状含む), プロパティUI, undo, plate/PCB生成 | keyboard.ts ストア(62KB)と、それを直接書き換える移動・回転・履歴 |
| 自作 | - | kle-serial(読), kle-serial2(読み書き) | 全部。ただし木モデルに合わせて最初から書ける |
@@ -22,14 +22,15 @@
## 検証ログ
### ijprest/keyboard-layout-editor
- LICENSE.md (ローカル HEAD d2945e5 / 本家 master 2026-09-18 取得、同文)
- "Copyright(C) 2013-2018 by Ian Prest. All rights reserved."
- "But it's not permissively licensed!"
- "In the near-term I would like to avoid forks of the website, since I feel it would cause confusion
- "Copyright(C) 2013-2018 by Ian Prest. All rights reserved."
- "But it's not permissively licensed!"
- "In the near-term I would like to avoid forks of the website, since I feel it would cause confusion
in the community to have several similar-but-different general-purpose layout editors available."
- 別用途(メーカーのカスタマイズ用エディタ等)なら無償で特別ライセンスを出す、とある。
Beyond KLE は汎用レイアウトエディタそのものなので、この例外には当てはまりにくい
- "I claim no ownership over the input (your keyboard layouts) or output" → ビュワーとして使う・JSONを扱うのは問題なし
- 別用途(メーカーのカスタマイズ用エディタ等)なら無償で特別ライセンスを出す、とある。
Beyond KLE は汎用レイアウトエディタそのものなので、この例外には当てはまりにくい
- "I claim no ownership over the input (your keyboard layouts) or output" → ビュワーとして使う・JSONを扱うのは問題なし
- 本家最終コミット 580b916 2024-09-15 "Update to https"。その前は 2019-07-04。実質停止
- 規模(HEAD): kb.js 1810 / kb.html 1410 / kb.css 453 / serial.js 374 / render.js 275 行
- 依存: angular 1.2.28, jquery 2.0.2, bootstrap 3.3.5, bower
@@ -37,36 +38,40 @@
- ローカルクローン(Documents/Dev/keyboard-layout-editor)の未コミット差分はPNG解像度調整と円形プロファイル追加のみ(ユーザー談)。本件と無関係
### kle-serial (ijprest)
- MIT, Copyright (c) 2013-2019 Ian Prest。npm @ijprest/kle-serial 0.15.1 (2019-06-30)
- README: "This library currently only handles deserialization; the serialization code still needs to be ported."
### kle-serial2 (adamws, ijprest/kle-serial のフォーク)
- MIT。2025-08-22作成、最終push 2026-02-14、star 1
- serialize あり。書き出しプロパティ: r rx ry x y c t ta g p sm sb st _r _rs a f fa w h w2 h2 x2 y2 l n d
- serialize あり。書き出しプロパティ: r rx ry x y c t ta g p sm sb st _r_rs a f fa w h w2 h2 x2 y2 l n d
- 出自の懸念: 元READMEは serialize を「KLE本体から移植予定」としていた。kle-serial2 の serialize 冒頭
(current, cluster={r,rx,ry}, align=4, rows/row)は KLE serial.js:166- と構造が似る。
ただしKLEフォーマット自体がこの構造を要求するので、流用の証拠にはならない。未確認
→ 気になるなら書き出しは自前で書く(畳み込み後の絶対座標 → KLE行形式。rx/ry選択は PHY P-1 と一体)
(current, cluster={r,rx,ry}, align=4, rows/row)は KLE serial.js:166- と構造が似る。
ただしKLEフォーマット自体がこの構造を要求するので、流用の証拠にはならない。未確認
→ 気になるなら書き出しは自前で書く(畳み込み後の絶対座標 → KLE行形式。rx/ry選択は PHY P-1 と一体)
### adamws/kle-ng
- MIT, Copyright (c) 2025 adamws。Vue 3 + Pinia + TS + Vite, bootstrap 5, three.js, ergogen, makerjs
- 最終コミット 9eb350f 2026-09-03 (0.48.0)。star 267
- 規模: TypeScript 2.97MB + Vue 0.99MB (GitHub languages API, テスト込み)
- src/stores/keyboard.ts: `const keys: Ref<Key[]> = ref([])`。フラット、絶対座標 + rotation_x/y。階層・グループなし
- 移動: key.x = D.add(originalPos.x, snappedDeltaX) と直接書き換え
- 回転: key.rotation_angle を直接書き換え、lock-rotations時は rotation_x/y も更新
- undo: keys 全体の JSON スナップショット、50件
- 移動: key.x = D.add(originalPos.x, snappedDeltaX) と直接書き換え
- 回転: key.rotation_angle を直接書き換え、lock-rotations時は rotation_x/y も更新
- undo: keys 全体の JSON スナップショット、50件
- matrix-drawing.ts (28KB), pcbGenerator.ts, plateGenerator.ts あり。IDX/ELC の参考になりうる(未読)
- ijprest のコードから派生したかは README に記載なし。未確認
### その他
- ymkn/keyboard-layout-studio: MIT, Vue3, SVG, KLE import, QMK keyboard.json / Vial 出力, matrix割り当て。star 4, 21 commits。回転・グループの記載なし
- ローカル Documents/Dev/kbd-editor: Nuxt3 + Pinia, 2025-07, 約2,500行 (deserializer.ts, Key.vue, KeyPropEditor.vue 等)。ユーザーが以前自作を試みたもの。うまくいかなかった記憶あり(ユーザー談)。中身の確認は保留
## 規模見積もり(PHY Editor MVP, 1人・フルタイム換算の粗い目安)
| 項目 | 自作 | kle-ng改造 |
|---|---|---|
| --- | --- | --- |
| KLE読込 | 1-2日 (kle-serial) | 既存 |
| KLE書出 + 畳み込み | 2-4日 | 畳み込みだけ新規 |
| 木モデル・変換合成・逆変換 | 3-5日 | 3-5日 + 既存ストアへの差し込み |
journal/2026-09-18-kle-roundtrip.md
+5 -5
View File
@@ -10,7 +10,7 @@
## 案の比較
| 案 | 出典 | 問題 |
|---|---|---|
| --- | --- | --- |
| labelにIDを埋め込み、別ファイルのクラスターJSONと紐づけ | PHYレイヤー.md(旧) | VIAのlabelハックと同じ道。IDが長くなりラベルが見づらい |
| `_beyondkle` メタデータ + labels[8] のハイブリッド | kle-compatibility.md | 同上。独自プロパティはKLEが保存時に落とす可能性 |
| ゴーストキーにクラスター情報を格納 | kle-compatibility-analysis.md | 下記。所属情報が残らず、結局labelハックに戻る |
@@ -28,12 +28,12 @@ PHY座標モデルの決定(相対座標の木が正本)により、KLE JSONは
### ゴーストキー案の穴
- キーの所属は `key.clusterId` という独自プロパティで持たせる設計だった(kle-compatibility-analysis.md の createCluster)。
KLEのシリアライザは既知のプロパティしか書き出さないはずで(未確認)、保存時に所属が消える。
残すには各キーのlabelにIDを入れることになり、labelハックに戻る
KLEのシリアライザは既知のプロパティしか書き出さないはずで(未確認)、保存時に所属が消える。
残すには各キーのlabelにIDを入れることになり、labelハックに戻る
- 矩形に含まれるかで所属を判定する方法は、入れ子や回転があると曖昧になる
- ゴーストキー自体も labels[0]="CLUSTER_META"、labels[4]=JSON という形で、汚す対象がダミーキーに変わっただけ
- KLE JSONを読む他ツール(QMK変換、KiCad配置プラグインなど)がゴーストキーを実在するキーとして扱う懸念(未確認)。
KLE JSONを出力する目的は互換性なので、偽のキーを混ぜるのは本末転倒
KLE JSONを出力する目的は互換性なので、偽のキーを混ぜるのは本末転倒
### KLEを改造するか自作するかとは独立
@@ -45,4 +45,4 @@ KLEを改造する場合でも、内部データと保存形式は自分で決
- 照合基準の詳細(許容誤差、ラベルの扱い、複数候補の解決)。PHYレイヤー.md の未確認事項 P-2
- KLEが保存時にキー順を並べ替えるか(未確認)。配列順を照合に使えるかに関わる
- kle-compatibility.md / kle-compatibility-analysis.md の埋め込み案の記述は今回の決定と食い違うが、
既存ドキュメントの再編は別タスクのため触っていない
既存ドキュメントの再編は別タスクのため触っていない
journal/2026-09-19-kle-key-attributes.md
+3 -3
View File
@@ -11,7 +11,7 @@
## 案の比較
| 項目 | 案 | 採否 |
|---|---|---|
| --- | --- | --- |
| d, g | PHYでキーとして持つ / 取り込み時に捨てる | 持つ |
| 見た目属性 | 捨てる / 解釈せず保持して書き出し時に戻す | 保持。KLEをビュワーに使うとき色などが戻る方が実用的 |
| ラベル | 捨てる / 参考情報として持つ | 持つ。照合に必要 |
@@ -19,8 +19,8 @@
## ユーザーから得た事実・所感
- l(ステップキー)にはスイッチ位置がずれるものがある(Stepped Caps Lockが典型)。ただし l なら必ずずれるわけではない(昔のXFERなど)
→ 「キャップの位置・サイズからスイッチ座標を特定する」という本文と食い違う。P-5として分離
→ 「キャップの位置・サイズからスイッチ座標を特定する」という本文と食い違う。P-5として分離
- l, n はキーキャップの見た目属性であり、PHYとは別の層が要りそう。キーキャップは設計時に決める必要が薄く、
カスタムキーボードの文脈に属する。Beyond KLEの範囲かは結論なし
カスタムキーボードの文脈に属する。Beyond KLEの範囲かは結論なし
- 一部のキーだけ違うスイッチを使うキーボードもあるので、スイッチ種別はキーごとの上書きが要るかもしれない。PCB用なのでPHYに要るか
- ラベルのうちどれがMAPに適用できるかは判断できない見込み。自動で適用してユーザーが落とす案もある
journal/2026-09-19-switch-offset.md
+2 -2
View File
@@ -7,7 +7,7 @@
## 案の比較
| 案 | 採否 |
|---|---|
| --- | --- |
| キャップ形状(l 等)からスイッチ位置を導出 | 不可。l でもずれないキーがある(昔のXFER) |
| キーごとにオフセットを持つ | 採用 |
| PHY以外の層(キーキャップ層など)で持つ | 不採用 |
@@ -17,5 +17,5 @@
- Stepped Caps Lockなど、スイッチがキャップ中心からずれるキーがある(ユーザー提供の事実)
- ずれるかどうかはキャップ形状から決まらないので、キーごとに持つしかない
- スイッチ位置はPCB・プレートの配置を決める物理情報であり、PHYの責務。キーキャップの見た目情報が別層に移っても(P-6)、
キャップ外形とスイッチの相対位置は配置そのものなのでPHYに残る
キャップ外形とスイッチの相対位置は配置そのものなのでPHYに残る
- ローカル座標系にしたのは、キーの回転に追従させるため
journal/2026-09-20-cluster-manual-grouping.md
+2 -2
View File
@@ -14,7 +14,7 @@ PHYレイヤー.md の既存記述が2箇所でこれを前提にしていた。
## 案の比較
| 案 | 過去のKLE資産 | 誤り |
|---|---|---|
| --- | --- | --- |
| 自動推定 | 一発で階層が付く場合がある | 推定を外したときユーザーが直せない(直す手段=手動操作がないため) |
| 手動の組み替え | 選択してまとめる手数がかかる | ユーザーの意図がそのまま入るので誤りがない |
| 両方 | 同上 | 手動操作があれば推定の価値は初期値の提案に落ちる。初期値は小さく済む(下記) |
@@ -43,7 +43,7 @@ Size / switchOffset / orientation はローカル値で親の変換を受けな
- スナップは手作業の入力時のみ。計算結果には適用しない
- グリッドは操作開始時の値を基準とする相対グリッド。ローカル原点基準の絶対グリッドにしない
(非グリッド値を持つキーを後から掴んだとき、絶対配置が勝手に動くのを防ぐ)
(非グリッド値を持つキーを後から掴んだとき、絶対配置が勝手に動くのを防ぐ)
## 浮動小数の累積(実装時の注意、本文には書かない)
journal/2026-09-20-led-node.md
+5 -5
View File
@@ -13,7 +13,7 @@
### per-key LEDの表現
| 案 | 位置 | 採否 |
|---|---|---|
| --- | --- | --- |
| キーのboolean | 持たない | ○ |
| キーに追随する自動生成ノード | ノードが座標を持つ | × 座標に自由度がない |
| ユーザーが1個ずつ置く | 持つ | × キー数ぶんの手作業 |
@@ -21,7 +21,7 @@
### 独立して置く部品
| 案 | 対象 | 採否 |
|---|---|---|
| --- | --- | --- |
| 部品ノード(汎用) | LED / OLED / エンコーダ / ネジ穴 / MCU など | ○ |
| LEDノード専用 | LEDのみ | × 次の部品で同じ議論をやり直す |
@@ -57,9 +57,9 @@ partGroup(中身を解釈しないラベル)をそのまま流用できるので
## 捨てた案・送った先
- ファイル単位の「per-key LEDがある」フラグ: キーごとのbooleanから導出できるので存在フラグとしては不要。
既定値を与える設定としては意味があるが、ファイル単位設定の置き場は他にも要求があり別トピックへ。
今回はキーごとのbooleanのみ決め、省略時は false とする
既定値を与える設定としては意味があるが、ファイル単位設定の置き場は他にも要求があり別トピックへ。
今回はキーごとのbooleanのみ決め、省略時は false とする
- レイアウトによって条件付きでLEDの有無が変わる構成: ANSI/ISO Enter のようなキー自体の排他と同じ問題で、
LED固有ではない。マルチレイアウト(未導入の概念)側へ送る
LED固有ではない。マルチレイアウト(未導入の概念)側へ送る
- 部品の表裏をPHYが持つ: PCB設計ツールが決める情報。ただし描画の描き分けとの絡みが残るので P-12
- チェーン順序をPHYが持つ: 電気的な接続なのでELC。ただし接点マトリクスと同じ層でよいかに確信がなく P-11
journal/2026-09-20-switch-terminal.md
+5 -5
View File
@@ -8,7 +8,7 @@ PHYは端子配置(terminal) / ソケット方式(socket) / スイッチの向
## 案の比較
| 論点 | 案 | 採否 |
|---|---|---|
| --- | --- | --- |
| ブランド | KLEの sb 相当をPHYで持つ | 不採用 |
| ブランド | 持たない | 採用 |
| 種別の定義 | (a) スイッチ側の足の配置。MX-3pin と MX-5pin は別タイプ | 採用 |
@@ -24,13 +24,13 @@ PHYは端子配置(terminal) / ソケット方式(socket) / スイッチの向
- ブランドは同じボードに対して利用者が選ぶもので、穴もパッドも配線対象も変えない。ボード設計の情報ではない
- KLEの st は `MX1A-11Nx` のようなベンダー品番で、ブランド・種別・バリエーションが混ざった文字列。ここから穴形状を機械的に導けないため、
Beyond KLEの端子配置との対応づけは成立しない。名前も意味もKLEと別物なので、同名を避けて terminal とした
Beyond KLEの端子配置との対応づけは成立しない。名前も意味もKLEと別物なので、同名を避けて terminal とした
- 端子配置は電気的インターフェース(2端子接点 / アナログ / 光学)も決める。PHYが持てばELCが別途スイッチ情報を持つ必要がない。
これがPHYに置く根拠になった
これがPHYに置く根拠になった
- 向きは90度と270度で別物(LED穴・ボス穴の位置が変わる)なので4方向。キーの回転とは別の値で、キーのローカル座標系に対して持つ
- 階層化を採らなかったのは、欲しいのが分類ラベルであって継承ではないため。低背かどうかも定義表の列で表せる
- 未知の種別を特別扱いしなかったのは、KiCadのフットプリント名がライブラリ依存で、既知の種別でも出力時のマッピングが要るため。
未知は「マッピングが未登録」なだけになる
未知は「マッピングが未登録」なだけになる
## (b)案を捨てた経緯
@@ -43,4 +43,4 @@ LED穴も (b) と同じ形の論点だが、LED専用ノードを立てる可能
## 捨てた仮説
- 「マウント方式」をKLEの sm と同じ軸だと考えていた。KLEの sm は cherry / alps のような軸規格で、
プレートマウント/PCBマウントでもホットスワップ/直付けでもない。ユーザーの意図はソケット有無だったため socket に落ち着いた
プレートマウント/PCBマウントでもホットスワップ/直付けでもない。ユーザーの意図はソケット有無だったため socket に落ち着いた
journal/2026-09-21-idx-necessity.md
+9 -8
View File
@@ -66,10 +66,11 @@ ZMKの matrix transform `map`:
引数の数え間違いでキーが1つずれるのが定番のバグであることも、この層が手書きである傍証になる。
出典:
- https://docs.qmk.fm/reference_configurator_support
- https://docs.qmk.fm/reference_info_json
- https://zmk.dev/docs/config/layout
- https://github.com/KMKfw/kmk_firmware/blob/main/docs/en/porting_to_kmk.md
- <https://docs.qmk.fm/reference_configurator_support>
- <https://docs.qmk.fm/reference_info_json>
- <https://zmk.dev/docs/config/layout>
- <https://github.com/KMKfw/kmk_firmware/blob/main/docs/en/porting_to_kmk.md>
## 根拠: マトリクス順 ≠ キー番号順 の実物
@@ -96,7 +97,7 @@ QMKの分割も同じ構造。
> Since the matrix scanning procedure operates on entire rows, it first populates the left half's rows,
> then the right half's. Thus, the matrix as QMK views it has double the rows instead of double the columns.
出典: https://docs.qmk.fm/features/split_keyboard
出典: <https://docs.qmk.fm/features/split_keyboard>
## 保存形式を `order: string[]` にした理由
@@ -109,7 +110,7 @@ ELCの `LEDChain.order` で既に「並びの位置が番号」の形を採っ
## 捨てた仮説
- 「IDXはdecal/ghostの区別を持つべきではないか」。decalはPHYが `decal` フラグを持っているので
そこから分かる。ghostは何を意味するかがKLE由来で曖昧なので、IDXの側で規定しない。
`order` に挙げたキーだけが番号を持つ、で足りる
そこから分かる。ghostは何を意味するかがKLE由来で曖昧なので、IDXの側で規定しない。
`order` に挙げたキーだけが番号を持つ、で足りる
- 「VIAとの往復でキー番号が要るのでは」。VIAのプロトコルはrow/col指定なので、キー番号は出てこない。
ただし裏取りしていないので、ドキュメントには書かなかった
ただし裏取りしていないので、ドキュメントには書かなかった
journal/2026-09-21-kle-corpus.md
+4 -4
View File
@@ -5,12 +5,12 @@
公開されているKLE JSON 1505件(キー111,619個)を集め、PHYへ変換して書き戻す往復を通した。
- 幾何(位置・サイズ・回転・2つ目の矩形・decal・ghost)は全件で無損失。PHYのデータモデルで表せないKLEの
幾何情報は無かった
幾何情報は無かった
- 置き場がないのは見た目の属性だけ(c, t, p, a, f, f2, fa, n, l と sm, sb, st、ファイル単位の
backcolor, radii, background, css)。検証では退避用のフィールドに逃がした。PHY P-6 の対象そのもの
backcolor, radii, background, css)。検証では退避用のフィールドに逃がした。PHY P-6 の対象そのもの
- KLE本家のデシリアライザが読めないJSONが実在する(1505件中1件)
- `l`(stepped)が付いたキーが16個あった。KLEはstepped Caps Lockに「段差がある」ことしか持たず、
スイッチ位置のオフセットは持たない。PHYの `switchOffset` は取り込みでは決まらない
スイッチ位置のオフセットは持たない。PHYの `switchOffset` は取り込みでは決まらない
## コーパス
@@ -39,7 +39,7 @@ KLE本家のリポジトリ (ijprest/keyboard-layout-editor) から `serial.js`
- 1504/1504 で配置が一致(1件は手順1で本家が例外を投げるため対象外)
- 直列化結果そのものが本家の出力と完全一致: 1408件。小数4桁に丸めると一致(誤差のみ): 20件。
残り76件は行の切り方が違うだけで、読み直した配置は一致する
残り76件は行の切り方が違うだけで、読み直した配置は一致する
出現頻度(キー単位、111,619個中):
journal/2026-09-21-multi-layout.md
+5 -5
View File
@@ -20,10 +20,10 @@
木案はそこが弱いが、次の点で勝る。
- 条件付きの選択肢(あるバリアントを選んだときだけ現れる選択肢)が入れ子で自然に出る。
タグ案では選択肢の依存関係を別に持つ必要がある
タグ案では選択肢の依存関係を別に持つ必要がある
- 「どのキーがどの選択肢に属するか」を木の上で直接見られる。タグ案は全ノードを走査しないと分からない
- 空のVariant(「エンコーダーを載せない」)が、子のいないノードとしてそのまま置ける。
タグ案ではファイル単位の宣言が必須になる(キーのタグから選択肢を復元できないため)
タグ案ではファイル単位の宣言が必須になる(キーのタグから選択肢を復元できないため)
別レイヤー案は、選択箇所が「どのスイッチを実装するか」という物理の話であり、
PHY以外の3レイヤーがすべてPHYのノードIDを参照する構造からも外れるので落とした。
@@ -58,7 +58,7 @@ supersetの並びから選択外のキーを落とした派生情報として出
## 捨てた検討
- キーごとに `variants: string[]` を持たせて複数の選択肢にまたがらせる形。
そもそも複数選択肢で共通のキーが実在するかを確認できていないので、必要になってから決める
(PHYレイヤー.md P-15)
そもそも複数選択肢で共通のキーが実在するかを確認できていないので、必要になってから決める
(PHYレイヤー.md P-15)
- 選択状態(どのバリアントを選んでいるか)をPHYとは別ファイルに持つ案。
既定のバリアントをVariantGroupに持たせれば足りる。編集中の表示切り替えはエディタの状態
既定のバリアントをVariantGroupに持たせれば足りる。編集中の表示切り替えはエディタの状態
journal/2026-09-21-variant-shared-key.md
+1 -1
View File
@@ -57,7 +57,7 @@ VariantGroupを「ANSI/ISO」と「Backspace分割の有無」に分ければ、
- 入れ子のVariantGroupで表す: 出現集合が交差するので不可能
- 独立したVariantGroupに分けて、成立しない組み合わせを禁止する仕組みを足す:
複製を許せば要らない。禁止の表現を足すほうが重い
複製を許せば要らない。禁止の表現を足すほうが重い
- 同じ位置のキーに違う番号が振られたら警告する: 排他キーは位置もサイズも違ってよいので基準にならない
## この調査の限界
journal/2026-09-22-map-via-workflow.md
+7 -7
View File
@@ -28,16 +28,16 @@ VIA向けのキーボード定義生成と、MAPの割り当ての読み書き
公式文書・実装を参照した。実機による読み書きの検証は行っていない。
- RemapはWebHIDを使い、QMKのVIAクライアント向け機能へアクセスする。Workbenchにはソース編集・ビルド・書き込みもある。
参照: https://github.com/remap-keys/remap#references
参照: https://remap-keys.app/docs/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
参照: <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
参照: <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
参照: <https://zmk.dev/docs/features/studio>
## 未採用の提案との区別
journal/2026-09-23-qmk-dynamic-scope.md
+29 -22
View File
@@ -3,13 +3,14 @@
## 結論
当面の対象ファームウェアはQMK。
- Dynamic: QMK本家のVIAプロトコルが公開する項目のみ
- Static: QMK本家の公式機能のうちVIAで変更できないものは、Firmware Generatorで生成する対象
- 非公式機能(Vial等のフォーク、XAP等のmaster以外のブランチ)は当面非対応
- developブランチ・Community Modulesは当面非対応(将来広げたい→backlog MAP-P-6)。キーボード・キーマップ固有コードは原則非対応
- 対応QMKは特定コミットに固定し、更新タイミングはユーザーが個別に判断する
- UIにはVIAプロトコルとキーコード体系のバージョンを表示し、実機とはこの2つで照合。不一致の実機は非対応
(当初はUIにコミットを出す案だったが、実機から取れるのがこの2つだけなのでユーザーがバージョン表記に変更)
(当初はUIにコミットを出す案だったが、実機から取れるのがこの2つだけなのでユーザーがバージョン表記に変更)
- Staticで定義する動作(タップダンス等)はキーから名前で参照し、出力時に番号へ変換する
- VIA管理外のEEPROM設定は読み出せない旨を制約として明記
@@ -29,23 +30,25 @@
実機での検証はしていない。
### A. QMK本家 VIA
参照: https://raw.githubusercontent.com/qmk/qmk_firmware/master/quantum/via.h
参照: <https://raw.githubusercontent.com/qmk/qmk_firmware/master/quantum/via.h>
VIA_PROTOCOL_VERSION = 0x000D
command:
- 0x01 get_protocol_version
- 0x02/0x03 get/set_keyboard_value
- 0x01 uptime(get), 0x02 layout_options(get/set), 0x03 switch_matrix_state(get),
0x04 firmware_version(get), 0x05 device_indication(set), 0x06 keycodes_version(get)
- 0x01 uptime(get), 0x02 layout_options(get/set), 0x03 switch_matrix_state(get),
0x04 firmware_version(get), 0x05 device_indication(set), 0x06 keycodes_version(get)
- 0x04/0x05 dynamic_keymap_get/set_keycode (layer,row,col)
- 0x06 dynamic_keymap_reset
- 0x07/0x08/0x09 custom_set/get_value, custom_save
- channel 0 custom(キーボード独自メニュー)
- 1 backlight: brightness, effect
- 2 rgblight: brightness, effect, effect_speed, color
- 3 rgb_matrix: brightness, effect, effect_speed, color
- 4 audio: enable, clicky_enable
- 5 led_matrix: brightness, effect, effect_speed
- channel 0 custom(キーボード独自メニュー)
- 1 backlight: brightness, effect
- 2 rgblight: brightness, effect, effect_speed, color
- 3 rgb_matrix: brightness, effect, effect_speed, color
- 4 audio: enable, clicky_enable
- 5 led_matrix: brightness, effect, effect_speed
- 0x0A eeprom_reset
- 0x0B bootloader_jump
- 0x0C..0x10 dynamic_keymap_macro_get_count / get_buffer_size / get_buffer / set_buffer / reset
@@ -57,8 +60,9 @@ MAPに関係するもの: キーコード、レイヤー数、エンコーダ、
照明・オーディオはMAPの所有データ外(MAPレイヤー.md「持たないもの」)。
### B. Vial(フォーク、今回非対応)
参照: https://raw.githubusercontent.com/vial-kb/vial-qmk/vial/quantum/vial.h
参照: https://raw.githubusercontent.com/vial-kb/vial-qmk/vial/quantum/qmk_settings.c
参照: <https://raw.githubusercontent.com/vial-kb/vial-qmk/vial/quantum/vial.h>
参照: <https://raw.githubusercontent.com/vial-kb/vial-qmk/vial/quantum/qmk_settings.c>
VIAL_PROTOCOL_VERSION = 6
- keyboard_id、圧縮キーボード定義JSONの取得(get_size/get_def)
@@ -66,24 +70,27 @@ VIAL_PROTOCOL_VERSION = 6
- dynamic entry: tap dance, combo, key override, alt repeat key
- 拡張マクロ(EXT_TAP/DOWN/UP)
- QMK Settings (QSID):
1 grave_esc_override, 2 combo_term, 3 auto_shift, 4 auto_shift_timeout,
5 osk_tap_toggle, 6 osk_timeout, 7 tapping_term, 9-17 mousekey各種(MK_3_SPEED以外),
18 tap_code_delay, 19 tap_hold_caps_delay, 20 tapping_toggle,
21 magic_settings(Ctrl/Caps, Alt/GUI, Ctrl/GUI, Grave/Esc, BSpc/BSlash入替, GUI無効, NKRO),
22 permissive_hold, 23 hold_on_other_key_press, 24 retro_tapping,
25 quick_tap_term, 26 chordal_hold, 27 flow_tap_term
1 grave_esc_override, 2 combo_term, 3 auto_shift, 4 auto_shift_timeout,
5 osk_tap_toggle, 6 osk_timeout, 7 tapping_term, 9-17 mousekey各種(MK_3_SPEED以外),
18 tap_code_delay, 19 tap_hold_caps_delay, 20 tapping_toggle,
21 magic_settings(Ctrl/Caps, Alt/GUI, Ctrl/GUI, Grave/Esc, BSpc/BSlash入替, GUI無効, NKRO),
22 permissive_hold, 23 hold_on_other_key_press, 24 retro_tapping,
25 quick_tap_term, 26 chordal_hold, 27 flow_tap_term
- VialRGB(RGB Matrixエフェクト列挙・設定)。ソース未確認
### C. プロトコル外で実機上だけ変わるもの(Dynamicの定義外)
当初「すべてEEPROMに保存される」と書いたが誤り。確認結果:
- 保存されない(再起動で消える): ダイナミックマクロ(docs/features/dynamic_macros.md
"lost when the keyboard is unplugged or otherwise rebooted")、DT_UP/DT_DOWN(docs/tap_hold.md "*not* persistent")
"lost when the keyboard is unplugged or otherwise rebooted")、DT_UP/DT_DOWN(docs/tap_hold.md "*not* persistent")
- EEPROMに保存される(quantum/eeconfig.h): keymap config(Magic)、default layer、unicode mode、audio、backlight、
rgblight/rgb_matrix/led_matrix、haptic、steno mode、handedness、connection、kb/user固有データ
rgblight/rgb_matrix/led_matrix、haptic、steno mode、handedness、connection、kb/user固有データ
- QMK本家via.cにはこれらを読み出すコマンドがない。照明・オーディオはcustom channel 1〜5で読めるがMAPの所有外。
custom channel 0はweakの via_custom_value_command_kb() へ流れる(キーボード固有コード、原則非対応)。
custom channel 0はweakの via_custom_value_command_kb() へ流れる(キーボード固有コード、原則非対応)。
- 参考: via_eeprom_is_valid() はビルド日時由来のmagicで検証し、不一致ならVIAのデータ(キーマップ・マクロ・layout options)を
初期化する。再ビルドして書き込むとDynamicの変更は消える前提になる。
初期化する。再ビルドして書き込むとDynamicの変更は消える前提になる。
### XAP
QMK公式の次世代プロトコルとして開発されていたが、masterには入っていない認識。未確認。
journal/2026-09-24-generator-c-override.md
+5 -5
View File
@@ -18,12 +18,12 @@ JSONを第一級にしてCを自動生成し、ユーザーのC/hで一部を上
## 根拠(QMK 0.34.4)
- keymap.jsonで書けるもの: keyboard, keymap, layout, layers, encoders, dip_switches, macros, keycodes(名前宣言), config, modules,
host_language 等(data/schemas/keymap.jsonschema)。タップダンス・コンボ・キーオーバーライド・キーごとの設定はない。
host_language 等(data/schemas/keymap.jsonschema)。タップダンス・コンボ・キーオーバーライド・キーごとの設定はない。
- キーごとの設定は `*_PER_KEY` を定義した上での `get_tapping_term(keycode, record)` 等のコールバック。keyrecordを受けるので
キーコード単位でも位置単位でも書ける。
キーコード単位でも位置単位でも書ける。
- keymap.jsonとkeymap.cを並べると、json2cで生成したkeymap.cがユーザーのkeymap.cを取り込む
(builddefs/build_keyboard.mk:148-157、OTHER_KEYMAP_C)。QMK自体がJSON + ユーザーCの共存に対応している。
(builddefs/build_keyboard.mk:148-157、OTHER_KEYMAP_C)。QMK自体がJSON + ユーザーCの共存に対応している。
- 取り込みは同一翻訳単位なので、生成側weak + ユーザー側strongは再定義エラーになる。QMK本体のweak既定実装もあるため、
別ファイルにしても生成側をweakにする方式は選ばれる定義が不定。
別ファイルにしても生成側をweakにする方式は選ばれる定義が不定。
- プロトタイプの再宣言はCでは合法(同一シグネチャなら何度でも)。QMKが宣言済みの関数をユーザーのhに書いてもよい。
シグネチャ違いはコンパイルエラーになるので検出にも使える。
シグネチャ違いはコンパイルエラーになるので検出にも使える。
journal/2026-09-24-hst-layer-scope.md
+5 -5
View File
@@ -13,7 +13,7 @@
## 案の比較
| 論点 | 当初の提案(人との議論) | Claude | Codex | 採用 |
|---|---|---|---|---|
| --- | --- | --- | --- | --- |
| 名前 | SYS | HOST/HST | SYS → 最終的にHOST/HSTに同意 | HST |
| 識別子 | WIN-JAP (OS×言語) | OS×配列の構造 | OS×配列×入力方式+プロファイル名 | OS×配列(+入力方式) |
| 範囲 | OS・言語ごとのキーの振る舞い・表示 | ホストの解釈の記述 | 意図を環境ごとの出力に変換、まで候補 → 最終的に「対応関係を提供、変更はしない」 | 記述のみ |
@@ -24,12 +24,12 @@
- SYSは、HIDのSystem Control用途ページ(電源・スリープ)や「システム設定全般」と紛らわしい。hostはHIDでキーボードの接続相手を指す用語で、QMKも「host keyboard layout」と呼ぶ。
- 言語は軸として誤り: 日本語Windowsで英語配列を使える。MacではUS/JISが入力ソースとキーボード種別で決まる。XKBはlayout/variant/optionsの3要素。
「英語」にもUS・UKがある。`JAP` はISOコードでもない(ja/jpn)。
「英語」にもUS・UKがある。`JAP` はISOコードでもない(ja/jpn)。
- 逆引きをプロファイルに持たせない理由: (1) 順方向の表から導けるので二重管理になる。
(2) 候補がファームウェアの機能に依存する。例: US刻印+JISホストでShiftの組が合わないキーにはKey Overrideが要る。HSTにQMKの知識が混ざる。
(2) 候補がファームウェアの機能に依存する。例: US刻印+JISホストでShiftの組が合わないキーにはKey Overrideが要る。HSTにQMKの知識が混ざる。
- Codexの指摘で採用したもの: 表示の切り替えと送信内容の変更を混ぜない。知らない動作を「使えない」と扱わない(対応可否を3値にする)。OS設定への依存は記述する。
- MAPの正本をキーコードにする理由の修正: Claudeは当初「VIAでは実機にキーコードしか残らず、意図を復元できないので、キーコードでなければならない」とした。
Codexが、意図をプロジェクト側に残す設計も可能で、難しくなるのは実機で変更された値の取り込みだけだと反論し、これが正しい。
採用する理由は「実機との往復を単純に保てるから」とする。
Codexが、意図をプロジェクト側に残す設計も可能で、難しくなるのは実機で変更された値の取り込みだけだと反論し、これが正しい。
採用する理由は「実機との往復を単純に保てるから」とする。
- 「コピー」のような操作の辞書は、アプリやユーザー設定まで相手が広がるので対象外。
- 未採用のアイデア: キートップの刻印生成にHSTを使う(PHYのラベルへ流す)。検討していないので仕様には書かない。
journal/2026-09-24-qmk-feature-inventory.md
+10 -8
View File
@@ -3,9 +3,9 @@
## 結論
- 対象: QMK `0.34.4`(tag, commit `08c662f286ddfd12a985f57b584b02eca5af0ae6`, 2026-09-05)。masterの最新リリース。
ユーザーが最初の対応環境として0.34.4を採用(2026-09-24)。
- キーコード体系 `QMK_KEYCODES_VERSION` = `0.0.9`(quantum/keycodes.h)
- `VIA_PROTOCOL_VERSION` = `0x000D`(quantum/via.h。9/23時点の調査と同じ)
ユーザーが最初の対応環境として0.34.4を採用(2026-09-24)。
- キーコード体系 `QMK_KEYCODES_VERSION` = `0.0.9`(quantum/keycodes.h)
- `VIA_PROTOCOL_VERSION` = `0x000D`(quantum/via.h。9/23時点の調査と同じ)
- MAPから見たQMKの機能は次の6種類に分かれる(下の表)。スキーマ・編集機能への落とし込みは未着手。
- 既存ドキュメントに影響しうる事実が2つある:
1. **VIAのモジュール化**(20260830 ChangeLog「VIA Feature Migration」#26315)。VIA統合の保守をVIAチームへ移し、
@@ -15,8 +15,8 @@
2. **VIAのマトリクス状態取得の無効化**(20250831 ChangeLog #25414)。`id_switch_matrix_state` は既定で全0を返す。
`VIA_INSECURE` 定義時、または `SECURE_ENABLE` でアンロック中のみ実値。Remap等のキーテスターは既定では動かない。
- QMKのキーごとの設定(tapping term等)はデータテーブルではなく、keycode/keyrecordを受けるCのコールバック関数で表現される。
keymap.json(data-driven)で書けるのはレイヤー・エンコーダ・DIPスイッチ・マクロ・カスタムキーコード・config・modules まで。
タップダンス・コンボ・キーオーバーライド・キーごとの設定はCでしか書けない。
keymap.json(data-driven)で書けるのはレイヤー・エンコーダ・DIPスイッチ・マクロ・カスタムキーコード・config・modules まで。
タップダンス・コンボ・キーオーバーライド・キーごとの設定はCでしか書けない。
## 分類の概要
@@ -53,7 +53,7 @@ data/constants/keycodes/*.hjson を 0.0.1〜0.0.9 の順にマージして得た
| 0x7400–0x743F | QK_JOYSTICK | ボタン0–31 |
| 0x7440–0x747F | QK_PROGRAMMABLE_BUTTON | 1–32 |
| 0x7480–0x74BF | QK_AUDIO | Audio/Clicky/Music 15件 |
| 0x74C0–0x751F | QK_STENO | 0.0.9で拡張・改名(STN_* → QK_STENO_* / ST_*、旧名はエイリアス) |
| 0x74C0–0x751F | QK_STENO | 0.0.9で拡張・改名(STN_*→ QK_STENO_* / ST_*、旧名はエイリアス) |
| 0x7700–0x777F | QK_MACRO | QK_MACRO_0–31(名前付き)。VIA/keymap.jsonのマクロ |
| 0x7780–0x77BF | QK_CONNECTION | 出力先切替(USB/2.4GHz/BT)、BTプロファイル1–5等15件 |
| 0x77C0–0x77FF | QK_COMMUNITY_MODULE | Community Modules用 |
@@ -69,6 +69,7 @@ Key Lock、One Shot on/off/toggle、Key Override on/off/toggle、Secure 4、Dyna
Autocorrect 3、Tri Layer Lower/Upper、Repeat/Alt Repeat、Layer Lock。
補足:
- 20250831で旧RGB・マウスの非推奨キーコードを削除(#25444)。
- VIAはキーマップを16bit値で読み書きするため、上のどの値もキーへ書ける。ファームウェアで無効な機能の値は何もしない。
@@ -116,7 +117,7 @@ Autocorrect 3、Tri Layer Lower/Upper、Repeat/Alt Repeat、Layer Lock。
| その他 | TAP_CODE_DELAY、TAP_HOLD_CAPS_DELAY、DEBOUNCE | — |
- キーごとのコールバックは keycode と keyrecord(押された位置・レイヤーを含む)を受ける。
つまり「キーコード単位」「物理位置単位」のどちらでも書ける(docs/tap_hold.md「Why do we include the key record」)。
つまり「キーコード単位」「物理位置単位」のどちらでも書ける(docs/tap_hold.md「Why do we include the key record」)。
- Chordal Holdの手の割り当ては物理位置(マトリクス)単位のデータ。
## E. キー以外の入力への割り当て
@@ -147,6 +148,7 @@ QMK本家VIAにはこれらを読み出すコマンドがない(9/23調査の再
## VIA 0x000D の読み書き範囲(0.34.4で再確認)
9/23の journal(qmk-dynamic-scope)と同じコマンド構成。差分・補足:
- `id_switch_matrix_state` は既定で0を返す(上記)。
- `id_eeprom_reset` は `VIA_EEPROM_ALLOW_RESET` 定義時のみ有効。
- エンコーダは `ENCODER_MAP_ENABLE` 時のみ。
@@ -158,5 +160,5 @@ QMK本家VIAにはこれらを読み出すコマンドがない(9/23調査の再
- 機能一覧: docs/_sidebar.json、builddefs/generic_features.mk の GENERIC_FEATURES。
- キーコード: data/constants/keycodes/keycodes_*.hjson をバージョン順にマージ。
- 変更点: docs/ChangeLog/20250223〜20260830。
- VIA移行PR: https://github.com/qmk/qmk_firmware/pull/26315(develop向けDraft。VIA_EEPROM_MAGIC_ADDR 以外は後方互換を維持する方針と記載)
- VIA移行PR: <https://github.com/qmk/qmk_firmware/pull/26315(develop向けDraft。VIA_EEPROM_MAGIC_ADDR> 以外は後方互換を維持する方針と記載)
- 実機での検証はしていない。
journal/2026-09-24-via-module-migration.md
+9 -9
View File
@@ -4,8 +4,8 @@
- QMKはVIA統合をCommunity Modules形式へ移し、旧実装を将来削除すると告知(20260830 ChangeLog「VIA Feature Migration」#26315)。
- 方針「QMKとVIAの両方に追従する」は変えない(ユーザー判断)。
→ Community Modulesは当面非対応のままだが、VIAモジュールだけは例外として、移行がmasterに入る前に対応する。
最悪、Community Modulesへの対応はVIAだけでもよい(ユーザー発言)。
→ Community Modulesは当面非対応のままだが、VIAモジュールだけは例外として、移行がmasterに入る前に対応する。
最悪、Community Modulesへの対応はVIAだけでもよい(ユーザー発言)。
- キーテスター(switch_matrix_state)が既定で動かない件は気にしない(ユーザー判断)。
## 案の比較
@@ -19,14 +19,14 @@
## 根拠(2026-09-24時点)
- docs/ChangeLog/20260830.md(QMK 0.34.4):
"upkeep of the VIA integration will transition to the VIA team" /
"in a future release, the old VIA feature-based implementation is expected to be removed."
- PR https://github.com/qmk/qmk_firmware/pull/26315 : develop向けDraft。追加ファイルは
modules/qmk/via/{qmk_module.json, via.c, via.h, post_config.h, post_rules.mk}。
qmk_module.json にバージョン欄なし。VIA_EEPROM_MAGIC_ADDR 以外は後方互換を維持すると記載。
"upkeep of the VIA integration will transition to the VIA team" /
"in a future release, the old VIA feature-based implementation is expected to be removed."
- PR <https://github.com/qmk/qmk_firmware/pull/26315> : develop向けDraft。追加ファイルは
modules/qmk/via/{qmk_module.json, via.c, via.h, post_config.h, post_rules.mk}。
qmk_module.json にバージョン欄なし。VIA_EEPROM_MAGIC_ADDR 以外は後方互換を維持すると記載。
- 0.34.4時点のVIAは従来どおり quantum/via.c、VIA_PROTOCOL_VERSION 0x000D。
- 同梱モジュールの有効化は keymap.json の `"modules": ["qmk/via"]` の形(data/schemas/keymap.jsonschema の modules、
builddefs/build_keyboard.mk の generate-community-modules-*)。対応コストは小さい見込み。
builddefs/build_keyboard.mk の generate-community-modules-*)。対応コストは小さい見込み。
- 保守がVIAチームへ移るため、将来QMKリポジトリ外へ出る可能性はあるが未確認。
## 追記: 対応環境の指定方法
@@ -42,5 +42,5 @@ QMK同梱モジュールはQMKのコミットで決まる。実機との照合
- きっかけ: ユーザーが「QMKに加えてVIAのバージョンも明記したほうがよいか」と相談。
- #26315の案ではVIAは modules/qmk/via(QMK同梱)で、qmk_module.json にバージョン欄がない。
この案のままならQMKのコミットだけで決まるが、保守移管後に外へ出る可能性に備える。
この案のままならQMKのコミットだけで決まるが、保守移管後に外へ出る可能性に備える。
- モジュールのバージョンは実機から取得できないため、照合には使わない。
journal/2026-09-24-via-read-write-scope.md
+2 -2
View File
@@ -6,7 +6,7 @@
- 別課題: エンコーダ(MAP-P-4)、layout option(P-3)
- 当面非対応: リセット系・ブートローダ移行、デバイスの識別表示、キーテスター、custom channel
- 有効な機能: 新規キーボードはGeneratorのビルド設定を正とする。既存キーボードは利用者の申告を信用する(ユーザー案)。
申告はGeneratorの設定と同じ形式にし、新規と既存を1つのモデルで扱う。
申告はGeneratorの設定と同じ形式にし、新規と既存を1つのモデルで扱う。
- 容量(レイヤー数・マクロ個数・容量)は実機から読んで照合する。
- P-2は判断が済んだので、実機で未検証という推測(P-2)に置き換えた。
@@ -28,6 +28,6 @@
## 機能・容量の確認
- VIAから読めるのは容量(レイヤー数、マクロ個数、マクロバッファサイズ)とバージョンだけ。
どの機能を有効にしてビルドしたか(タップダンス、コンボ等)は読めない。キーボード固有のVIA定義JSONにも含まれない。
どの機能を有効にしてビルドしたか(タップダンス、コンボ等)は読めない。キーボード固有のVIA定義JSONにも含まれない。
- 無効な機能のキーコードを書いてもエラーにならず、実機で何もしないだけ。申告の誤りは壊れる方向には働かない。
- 既存キーボードは初期対応の前提ではない(MAPレイヤー.md「概要」)が、申告方式ならモデルを増やさずに扱える。
keyboard-making-workflow.md
+22 -22
View File
@@ -11,9 +11,9 @@
- **ツール**: KLE (Keyboard Layout Editor)
- **作業内容**:
- キーの物理配置を決定
- キーサイズ・間隔・角度を調整
- 視覚的な配置確認
- キーの物理配置を決定
- キーサイズ・間隔・角度を調整
- 視覚的な配置確認
- **出力**: KLE JSON ファイル
- **Beyond KLE対応**: **PHYレイヤー**
@@ -21,9 +21,9 @@
- **ツール**: 手動計算、KiCad等の回路図エディタ
- **作業内容**:
- キーマトリックスの行列構成を決定
- マイコンピンとの対応付け
- ダイオード配置の検討
- キーマトリックスの行列構成を決定
- マイコンピンとの対応付け
- ダイオード配置の検討
- **出力**: 回路図、ピン配置表
- **現在の課題**: KLEからマトリックス情報への変換が手動
- **Beyond KLE対応**: **ELCレイヤー**。行列構成という工程は持たず、キーの端子とピンの対応として書く
@@ -34,9 +34,9 @@
- **ツール**: KiCad、Eagle、Fusion360等
- **作業内容**:
- KLE JSONから座標を抽出（手動またはスクリプト）
- スイッチフットプリントの配置
- マイコン・コネクタ等の部品配置
- KLE JSONから座標を抽出（手動またはスクリプト）
- スイッチフットプリントの配置
- マイコン・コネクタ等の部品配置
- **現在の課題**: KLEとPCBツール間の座標変換
- **Beyond KLE対応**: **PHYレイヤー** → PCBツール連携。渡すのは配置であって、フットプリントの選択はPCBツール側に残る
@@ -44,8 +44,8 @@
- **ツール**: PCB CADソフト
- **作業内容**:
- マトリックス配線の実装
- 電源・信号線のルーティング
- マトリックス配線の実装
- 電源・信号線のルーティング
- **Beyond KLE対応**: **ELCレイヤー**情報の活用
### 3. ファームウェア設定段階
@@ -54,24 +54,24 @@
- **ツール**: QMK、KMK、VIA等
- **作業内容**:
- マトリックス定義（ROW/COL）
- ピン配置設定
- 物理レイアウト定義
- キーマップ配列の並び順を決める（QMKなら `LAYOUT` マクロの引数順、ZMKなら matrix transform の
`map`、KMKなら `coord_mapping`）
- マトリックス定義（ROW/COL）
- ピン配置設定
- 物理レイアウト定義
- キーマップ配列の並び順を決める（QMKなら `LAYOUT` マクロの引数順、ZMKなら matrix transform の
`map`、KMKなら `coord_mapping`）
- **現在の課題**: KLEとファームウェア設定の手動変換。並び順は手書きで、引数の数え間違いがそのまま
キーのずれになる
キーのずれになる
- **Beyond KLE対応**: **PHY** + **IDX** + **ELC** → ファームウェア自動生成。
ROW/COLはELCの配線から出力時に割り当てる。並び順は**IDXレイヤー**が全バリアントにわたって正本として持ち、
出力時に選択したバリアントで使うキーだけを残して、キー番号を0から連続する番号に詰める
ROW/COLはELCの配線から出力時に割り当てる。並び順は**IDXレイヤー**が全バリアントにわたって正本として持ち、
出力時に選択したバリアントで使うキーだけを残して、キー番号を0から連続する番号に詰める
#### b) キーマップ設定
- **ツール**: QMK Configurator、VIA、Remap等
- **作業内容**:
- 各キーへのキーコード割り当て
- レイヤー設計
- マクロ・特殊機能の設定
- 各キーへのキーコード割り当て
- レイヤー設計
- マクロ・特殊機能の設定
- **Beyond KLE対応**: **MAPレイヤー**。キーの参照にはPHYのキーIDを使い、配列への並べ替えは出力時にバリアント選択後のIDXの順で行う
### 4. 製造・組み立て段階
provisional/README.md
+1 -1
View File
@@ -3,7 +3,7 @@
モックの仮実装のために、仕様上の未決事項を仮に1つへ固定したもの。**仕様ではない。**
- メインドキュメント(リポジトリ直下の `*.md`)・backlog・journal の運用ルールの対象外。
メインドキュメントやbacklogからこのフォルダへリンクしない。
メインドキュメントやbacklogからこのフォルダへリンクしない。
- 仮決定は本決定を意味しない。推測の検証済み扱いにもしない(`[推測:P-n]` のタグと未確認事項はそのまま残る)。
- 本決定にする場合は、通常どおり `/decide` でメインドキュメントとjournalに記録し、ここの該当項目を消す。
- モックを終えたら、このフォルダごと削除する。経緯は履歴で追える。
provisional/elc-editor-feedback.md
+8 -8
View File
@@ -10,29 +10,29 @@
- キーの上を順になぞって配線する。ピンの指定は、なぞる前でも後でもできる。
- 通常のマトリクスは、rowだけ・colだけを分けてなぞれるようにする(rowモード / colモード)。
- 編集中は、片方の端子だけ配線した状態を保存できる。ELCの端子を省略可能にし、片側だけのキーは検証で拾う。
ELCの保存形式の変更になるので、本決定は別途行う。
ELCの保存形式の変更になるので、本決定は別途行う。
- 倍マトリクスでは、同じrow/colの組が編集中に重なってよい。ダイオードの向きで区別するので衝突にはならない(T-25)。
重なった場合も保存は止めない(T-16)。
重なった場合も保存は止めない(T-16)。
### ピン提供者
- ボード(Pro Micro互換など、MCUを載せた開発基板)も提供者として扱いたい。多くの利用者はチップではなくボードを使う。
現行の `mcu` 提供者はチップの品番だけを持つ。
現行の `mcu` 提供者はチップの品番だけを持つ。
### LEDチェーン
- per-key LEDとアンダーグローを別チェーンにできること。仕様上はできる(チェーンに入れるLEDは設計者が選ぶ)。
モックでできないのは下記「モックの実装上の問題」による。
モックでできないのは下記「モックの実装上の問題」による。
- チェーン内の順番を指定できること。配線しやすい向きがあるため。キーの配線と同じく、なぞって指定する。
## 要検討
- 倍マトリクスの向きの指定方法(選択範囲だけダイオードの向きを逆にする、など)。
- 二乗マトリクス(同じピンがrowにもcolにも現れ、向きはダイオードだけで区別する)の操作。通常のマトリクスと同じ操作で足りるか。
row/colで表せるかの議論は後で行う。Generatorのプレビューは今のところ「未対応」になる(T-19)。
row/colで表せるかの議論は後で行う。Generatorのプレビューは今のところ「未対応」になる(T-19)。
- directの操作。row/colの指定がなく、片方の端子は電源レールになる。
- mux・シフトレジスタを使う場合の操作。rowかcolの一方を親の提供者の論理ピンにする形になるか。
マトリクスとの階層化はモデル上は表せるが、デジタル側の提供者の記述は未定義。
マトリクスとの階層化はモデル上は表せるが、デジタル側の提供者の記述は未定義。
- ボードを提供者にしたときの形。ボードのピン名とMCUのピンの対応、外に出ていないピンの扱い、分割キーボードでの使い方。
- 対応している提供者を図付きで見せる。ボードのピン配置図と一緒に考える。
- ピン名の候補の一覧が「今使えるピン」と誤解される問題。ダイアログに分けるなど。ボードを提供者にすれば、外に出ていないピンは候補から消える。
@@ -43,7 +43,7 @@
作り直しで解消する前提で、原因の記録だけ残す。
- 選ばれていないバリアントのキーを配線できない: 出力用の選択(`output.variantSelection`)で絞ったキーだけを表示し、
ELC画面に選択を変えるUIがない(IDX・Generatorのタブでしか変えられない)。仕様では全バリアントのキーを配線する。
ELC画面に選択を変えるUIがない(IDX・Generatorのタブでしか変えられない)。仕様では全バリアントのキーを配線する。
- per-key LEDが意図しないチェーンに入る: 配線用のキーボード表示のクリック(`clickKey`)が、編集中のチェーンにそのキーを追加する。
1つのLEDが複数のチェーンに入っても検査しない。
1つのLEDが複数のチェーンに入っても検査しない。
- 一括配線はキーをクリックで選ぶ方式で、配線の順はクリック順ではなくPHYの表示順になる。
provisional/map-editor-feedback.md
+2 -2
View File
@@ -59,9 +59,9 @@ Remapの現状は末尾の「参考: Remapのキーマップ編集」にまと
- レイヤー系(`TO/TG/MO/OSL/TT/DF`、`LM()`)は、レイヤー数の分だけ展開した候補を並べる。
- 一覧にあるもの(BASIC・LAYER以外の主なもの):
- FUNCTIONS: Combo On/Off、Auto Shift、VIA User Key、Programmable Button、
User、Leader、Dynamic Macro、Macro 0〜15
User、Leader、Dynamic Macro、Macro 0〜15
- SPECIAL: One Shot、Key Override、Tapping Term、Auto Correct、Repeat Key、
Key Lock、Caps Word、Steno、Unicode Mode
Key Lock、Caps Word、Steno、Unicode Mode
- Tap Dance(`TD()`)は一覧にも検索にも見つからなかった。
- 変更済みの表示: キーとレイヤー番号に点が付く。上部に「元 > 新」の差分とキャンセルが出る。書き込みボタンで変更をまとめて実機へ反映する。
- そのほか: キーマップの保存・共有(Mine / Shared / History)、PDFのキーマップ表、Layout Option、Test Matrix、マクロエディタ、ライティング設定。
provisional/phy-editor-feedback.md
+5 -5
View File
@@ -18,7 +18,7 @@
- 追加したキーが既存のキーに重なる(モックでは、最後に選んだキーの右隣、同じ親の中に置く)。
- 案: IDXで出た行の判定規則を流用し、選択中のキーの行の右端に追加する。
- ロウスタッガードでもカラムスタッガードでも同じ規則を使う。カラムスタッガードでは、追加したキーが
想定の縦ずれと違う位置に出ることがあるが、利用者が直せばよい。
想定の縦ずれと違う位置に出ることがあるが、利用者が直せばよい。
### クラスターの表示
@@ -37,10 +37,10 @@
### バリアント
- 切り替えのポップオーバーで、どちらを表示していても Option A に印が付いている
(モックでは、印は既定のバリアントを示す。初版「バリアントの切り替え」のとおり)。
(モックでは、印は既定のバリアントを示す。初版「バリアントの切り替え」のとおり)。
- 既定の印のままでよい。既定の印だと分かる見た目にする(「既定」と書くなど)。
- バッジの外にバリアント名がはみ出しているように見える(モックでは、バッジの枠は26px四方で、
その中に表示中のバリアント名を書いている。名前が長いと枠からはみ出す)。
その中に表示中のバリアント名を書いている。名前が長いと枠からはみ出す)。
- 案: 名前を書かずバッジだけにする、またはバッジの中に名前を収める。
- クラスター内のキーを選んでバリアントグループを作ると、クラスターの外に作られる。クラスターの中に作るほうがよい。
@@ -56,9 +56,9 @@
- 色違いの十字で示す。
- スタビライザー位置はキーの幅から推定して表示だけする(データは変えない)。
- スイッチ位置のオフセット(`switchOffset`)はPHYのデータにあるが、モックのプロパティ欄では入力できない。
スタビライザー位置はPHYのデータに無い。
スタビライザー位置はPHYのデータに無い。
- スイッチの中心がずれるキーが何種類かあるので、プロパティ欄に `switchOffset` の入力欄を置く。
ボタンやキー操作で変える手段は要らない。
ボタンやキー操作で変える手段は要らない。
### 後回し