ewdernaandClaude Opus 5.5
85f333cb24
継続行がスペース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
3.8 KiB
3.8 KiB
ELC Editor モックの所感(画面仕様の入力)
モックを触った所感と、それを受けた議論の整理。仕様ではない。 画面仕様を一から作るときの入力にし、仕様へ反映したら消す。
方向が合意できたもの
一括配線
- キーの上を順になぞって配線する。ピンの指定は、なぞる前でも後でもできる。
- 通常のマトリクスは、rowだけ・colだけを分けてなぞれるようにする(rowモード / colモード)。
- 編集中は、片方の端子だけ配線した状態を保存できる。ELCの端子を省略可能にし、片側だけのキーは検証で拾う。 ELCの保存形式の変更になるので、本決定は別途行う。
- 倍マトリクスでは、同じrow/colの組が編集中に重なってよい。ダイオードの向きで区別するので衝突にはならない(T-25)。 重なった場合も保存は止めない(T-16)。
ピン提供者
- ボード(Pro Micro互換など、MCUを載せた開発基板)も提供者として扱いたい。多くの利用者はチップではなくボードを使う。
現行の
mcu提供者はチップの品番だけを持つ。
LEDチェーン
- per-key LEDとアンダーグローを別チェーンにできること。仕様上はできる(チェーンに入れるLEDは設計者が選ぶ)。 モックでできないのは下記「モックの実装上の問題」による。
- チェーン内の順番を指定できること。配線しやすい向きがあるため。キーの配線と同じく、なぞって指定する。
要検討
- 倍マトリクスの向きの指定方法(選択範囲だけダイオードの向きを逆にする、など)。
- 二乗マトリクス(同じピンがrowにもcolにも現れ、向きはダイオードだけで区別する)の操作。通常のマトリクスと同じ操作で足りるか。 row/colで表せるかの議論は後で行う。Generatorのプレビューは今のところ「未対応」になる(T-19)。
- directの操作。row/colの指定がなく、片方の端子は電源レールになる。
- mux・シフトレジスタを使う場合の操作。rowかcolの一方を親の提供者の論理ピンにする形になるか。 マトリクスとの階層化はモデル上は表せるが、デジタル側の提供者の記述は未定義。
- ボードを提供者にしたときの形。ボードのピン名とMCUのピンの対応、外に出ていないピンの扱い、分割キーボードでの使い方。
- 対応している提供者を図付きで見せる。ボードのピン配置図と一緒に考える。
- ピン名の候補の一覧が「今使えるピン」と誤解される問題。ダイアログに分けるなど。ボードを提供者にすれば、外に出ていないピンは候補から消える。
- GPIOに直結したLED(インジケータなど)。仕様にないので
backlog/README.mdのELC-P-4とした。
モックの実装上の問題
作り直しで解消する前提で、原因の記録だけ残す。
- 選ばれていないバリアントのキーを配線できない: 出力用の選択(
output.variantSelection)で絞ったキーだけを表示し、 ELC画面に選択を変えるUIがない(IDX・Generatorのタブでしか変えられない)。仕様では全バリアントのキーを配線する。 - per-key LEDが意図しないチェーンに入る: 配線用のキーボード表示のクリック(
clickKey)が、編集中のチェーンにそのキーを追加する。 1つのLEDが複数のチェーンに入っても検査しない。 - 一括配線はキーをクリックで選ぶ方式で、配線の順はクリック順ではなくPHYの表示順になる。