# マルチレイアウト(交換可能なキークラスタ)の扱い

## 結論

- PHYは全バリアントのキーを同時に持つ(superset)。どれか1つに畳んだ状態を正本にしない
- 排他関係は木で表す。VariantGroup / Variant の2ノードを追加する
- ELCは変更なし。supersetをそのまま配線する。排他キー同士は同じ接続先を共有してよい
- IDXの番号空間は1つ。排他キー同士は同じ番号を共有できるので `order` の要素にキーIDの配列を許す
- MAPは変更なし

## PHYでの表現

| 案 | 形 | 判断 |
| --- | --- | --- |
| 木にバリアントノード | VariantGroup > Variant > ノード | 採用 |
| キーにタグ + ファイル単位で選択肢を宣言 | `variant?: {option, choice}` + `layoutOptions[]` | 不採用 |
| 別レイヤーに切り出す | PHYはsupersetだけ持ち、選択箇所は新レイヤー | 不採用 |

タグ案の利点は、reparentでキーを出し入れしても所属が変わらないこと。
木案はそこが弱いが、次の点で勝る。

- 条件付きの選択肢(あるバリアントを選んだときだけ現れる選択肢)が入れ子で自然に出る。
  タグ案では選択肢の依存関係を別に持つ必要がある
- 「どのキーがどの選択肢に属するか」を木の上で直接見られる。タグ案は全ノードを走査しないと分からない
- 空のVariant(「エンコーダーを載せない」)が、子のいないノードとしてそのまま置ける。
  タグ案ではファイル単位の宣言が必須になる(キーのタグから選択肢を復元できないため)

別レイヤー案は、選択箇所が「どのスイッチを実装するか」という物理の話であり、
PHY以外の3レイヤーがすべてPHYのノードIDを参照する構造からも外れるので落とした。

## VariantがTransformを持たない理由

バリアントは同じ場所を占める代替物なので、選択によって配下の絶対配置が動く構造にしたくない。
1つのバリアントの中で回転中心が要る場合は、その中にクラスターを置けば足りる。
VariantGroup側はクラスターと同じくTransformを持つ。

## IDXの番号共有

ELCで同じマトリクス交点に配線された排他キーは、同じキー番号を共有しなければならない。

出力先3つ(QMK `LAYOUT` マクロ / ZMK matrix transform の `map` / KMK `coord_mapping`)は、
どれも「番号の位置 → マトリクス位置」の1対1の対応表である。
同じ交点に別々の番号を与えると、その表に同じ交点が2回現れることになる。
逆に、別々の交点のキーに同じ番号を与えることもできない。

よって `order` の配列要素は「同じ交点に配線された排他キーの集合」と一致する。

### レイアウトごとに別のIDXを持つ案

不採用。キー番号が公開インターフェースであることと相性が悪い。
番号空間が複数あると、キーマップがどの空間のものかを指定しないと解釈できない。
また選択箇所が3つあれば組み合わせの数だけ空間が要る。

QMKの `LAYOUT_60_ansi` のような特定レイアウト向けの並びは、
supersetの並びから選択外のキーを落とした派生情報として出す。
ただし既存のコミュニティレイアウトの引数順と一致するかは未確認(IDXレイヤー.md P-1)。

## 捨てた検討

- キーごとに `variants: string[]` を持たせて複数の選択肢にまたがらせる形。
  そもそも複数選択肢で共通のキーが実在するかを確認できていないので、必要になってから決める
  (PHYレイヤー.md P-15)
- 選択状態(どのバリアントを選んでいるか)をPHYとは別ファイルに持つ案。
  既定のバリアントをVariantGroupに持たせれば足りる。編集中の表示切り替えはエディタの状態