fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: all four measured submenus reset -- the main menu is the only screen that remembers

Browse Source 
LOAD GAME, TUTORIAL and OPTIONS all reset on re-entry, joining EXTRAS. With the
main menu persisting, the rule is four of four submenus resetting and one
exception -- the opposite of what a single screen had suggested.

Fourth attempt, and every control in it is a previous failure: the decision uses
the cursor's own region so no per-screen geometry is assumed (sweep 1 read the main
menu's gutter on screens whose cursors are elsewhere); the back-on-the-menu test is
the narrow ring row (sweep 2 died when a crash dialog defeated whole-frame
comparison); absolute row checks after every press (a constant offset passes a
differential control); and a two-sided self-test that constructs both verdicts,
which had already caught a rule I broke myself.

Screens confirmed by eye and committed as evidence, because an earlier run was
fooled about which screen it was on. LOAD GAME's 21.6 is explained by its list
scrolling rather than moving a ring.

Still not separated: resets-to-named-item vs resets-to-top-item. None of these
three has an opening item that is not its first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-31 01:23:28 +00:00
parent 571d7e87b0
commit 4b8afbe85e
5 changed files with 127 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/re/menu-navigation-semantics.md
View File

@@ -30,6 +30,41 @@ with [`tools/re-capture/menu_focus.py`](../../tools/re-capture/menu_focus.py).
Wrap holds on both screens tested — the 5-item main menu and the 3-item `EXTRAS`
submenu — so it is a menu rule, not a per-screen table.
## ✅ 2026-08-31 — ALL FOUR measured submenus reset. The main menu is the exception.
**measured** — [`data/submenu-focus-all-reset.txt`](data/submenu-focus-all-reset.txt),
`tools/re-capture/submenu_focus_sweep.py`, one boot, fourth attempt.
| screen | verdict | in-cursor: from opened / from where left |
|---|---|---|
| `LOAD GAME` | **RESETS** | 21.6 / 86.3 |
| `TUTORIAL` | **RESETS** | 2.3 / 113.2 |
| `OPTIONS` | **RESETS** | 1.9 / 102.6 |
| `EXTRAS` (2026-08-30) | **RESETS** | 0.8 / 82.8 |
| **main menu** | **PERSISTS** | — |
✅ **So the rule is simple after all, and it is the opposite of what one screen
suggested**: submenus reset; the **main menu alone** remembers. Four of four.
✅ **Screens confirmed by eye**, because an earlier run was fooled about which
screen it was on: [`TUTORIAL`](captures/menu-nav/live-tutorial-submenu.png) — seven
items under `Level 1`/`Level 2` headers plus `BACK` — and
[`LOAD GAME`](captures/menu-nav/live-load-game-slots.png), a **scrolling** slot list
with the selection held at the vertical centre.
📌 `LOAD GAME`'s 21.6 is the only figure not near zero, and the capture explains it:
that list **scrolls** instead of moving a ring, so re-entry restores a scroll
position rather than a cursor sprite. Same verdict, different mechanism.
❔ **Still not separated: "resets to the named item" vs "resets to the top item".**
`sylpheed-port` asked for a submenu whose opening item is not its first. None of
these is one — `TUTORIAL` opens on `BASIC CONTROLS`, `OPTIONS` on `GAME SETTINGS`,
and `LOAD GAME` on slot **01**, which *looks* non-first only because slots 19 and 20
are drawn above it by a wrapping list around a centred selection.
⚠️ Reach: one boot, one round trip per screen, one direction, one entry each.
❔ `NEW GAME` stays deliberately untested.
## ✅ 2026-08-30 — EXTRAS **resets**; the main menu **persists**. They differ.
**measured** — [`data/extras-focus-resets.txt`](data/extras-focus-resets.txt),