'
f'
'
f'Decision 0 — ring or vertical list
The live question. Both forms carry the SAME map and the same invariant — fixed order, never re-sorted, nothing compacted; only the geometry differs. Left-click selects; right-click opens the offer. What the list buys: a disabled row can state its own reason in the words the product already ships, where an empty slot in a ring is mute; nine sketch primitives fit without an overflow; shortcuts line up in a readable column; long translated names fit; and it is navigable by arrow key and by screen reader, which a radial is not. What it costs: no equidistant flick gesture, and travel to the last row is longer than to the nearest direction. Pairs below — list first, the same state as a ring second.
Decision 1 — ring capacity
The same three selections at eight and at twelve. Eight keeps 45° between neighbours, which is the reliable eyes-free pointing threshold and maps 1:1 to the numpad; twelve buys direct addresses for more verbs at 30° spacing and positions that stop being nameable.
Decision 2 — one map or one per mode
These renders use ONE shared map: sketch verbs occupy the same eight families as model verbs, so dress-up is south-east whether you picked a solid edge or a sketch line. Compare the sketch-mode states below against the model-mode ones — if a verb that exists in both modes ever appears at two addresses, the shared map has failed and the split map is the answer.
The matrix — every selection, every document state
| Selection | Document | Verbs | Slots | 2nd rings | What lands where |
|---|
Overflow — the one place eight slots is not enough
{over_html}
Not in the offer
{esc(", ".join(A["chrome_only"]["items"]))} — these act on the document, not on a selection, so they stay in chrome. Verbs with kernel support but no GUI today, which still hold an address: {esc(", ".join(gui_missing))}.