# The focus reader was wrong on x11grab frames -- and what that changes.
# MEASURED 2026-08-30.
#
# menu_focus.py's row centres YS = [166,241,315,390,465] are DESIGN-SPACE rows,
# derived from `screenshot` captures. My probes feed it ffmpeg x11grab frames of
# the whole X display, which include Xenia's title bar and menu bar and show the
# game surface SCALED. Same numbers, different coordinate system.
#
# CAUGHT BY GROUND TRUTH, not by a control: the probe announced "on EXTRAS",
# pressed A, and opened OPTIONS. I looked at the frame.
#
# THE OFFSET, measured directly rather than assumed -- brightest gutter cluster
# (x 500:542), excluding the y<50 window-decoration band and the footer:
#
#   reach/1-F1.png  ring y = 225.5     (first menu entry of a fresh boot)
#   reach/2-F2.png  ring y = 384.0     (after 2 delivery-confirmed DOWNs)
#   reach/4-F3.png  ring y = 385.5     (after B -> title -> A -> menu)
#
#   spacing = (384.0 - 225.5) / 2 = 79.25 px per item
#   design spacing is 74.75, so the surface is scaled by 1.060 -- UP, not down
#   capture_y = 49.5 + 1.060 * design_y      (checks: 241->305 vs 304.75 seen,
#                                                     315->383.4 vs 384.0 seen)
#
# ⚠️ MY FIRST CORRECTION WAS ALSO WRONG. I assumed the 1280x675-inside-1280x720
# note meant the surface was scaled DOWN by 0.9375. Applying that gave F2 =
# OPTIONS, i.e. three rows below F1 where only two DOWNs were delivered -- the
# arithmetic refused it. Measuring the spacing settled it in one step.
#
################################################################################
# WHAT THIS CHANGES
#
# ✅ INITIAL FOCUS ON A FRESH BOOT IS **NEW GAME**, not TUTORIAL.
#    F1's ring at y=225.5 is design row 166 = item 0. Two fresh boots, both the
#    FIRST menu entry of the boot, both NEW GAME (this run, and the earlier run
#    whose old-reader value of LOAD GAME is the same frame misread).
#
#    That AGREES with boot_menu.sh's own closing line and with
#    menu-state-in-memory.md's four-downs-to-EXTRAS, which only counts from NEW
#    GAME. menu-navigation-semantics.md's "TUTORIAL, 2/2" is the outlier.
#
# ✅ THE PERSISTENCE FINDING STANDS, and is now confirmed WITHOUT any geometry:
#    F2 ring y = 384.0, F3 = 385.5. 1.5 px apart. The cursor is where it was
#    left. An equality test is immune to a constant offset, which is exactly why
#    that conclusion survived a broken reader.
#
# 🔴 BUT THE ITEM NAMES I PUBLISHED FOR IT WERE WRONG.
#    Reported: F1 TUTORIAL -> F2 EXTRAS -> F3 EXTRAS.
#    Truth:    F1 NEW GAME -> F2 TUTORIAL -> F3 TUTORIAL.
#    Two positions out. The conclusion does not change; the labels do.
#
# 🔴 AND MY CONTROL COULD NOT HAVE CAUGHT IT. "Two DOWNs must move the cursor
#    exactly two items" tests RELATIVE motion, and a constant offset preserves
#    relative motion exactly. A control that only checks differences is blind to
#    every error in the origin. It passed on a reader that was two items out.
#
# ❔ THE EXTRAS QUESTION IS STILL UNANSWERED. The probe navigated to OPTIONS
#    believing it was EXTRAS, so E1/E2/E3 are the OPTIONS screen and a different
#    screen respectively (E3 glyph 1776 is the title's plate band -- A on the
#    wrong screen went somewhere else entirely). Nothing about EXTRAS was
#    measured. sylpheed-port's `initial_focus: ptbtn11` label is still undecided.