docs(user-guide): say which key confirms, and that SQUARE does not - #654
Merged
Merged
Conversation
A first-night rev4 owner could not confirm a shutdown and kept landing in the help menu instead. The key list in "The Menu System" stopped at scroll and select, so nothing told him that RIGHT is the confirm key on a confirmation screen, or that SQUARE opens the Quick Menu rather than confirming. The Quick Start's alignment steps reinforced the wrong habit by presenting SQUARE as the key that "completes" a step. Expand the canonical key list in user_guide.rst with two bullets: RIGHT confirms and LEFT goes back on a confirmation screen, and SQUARE does not confirm. Mirror both bullets into the duplicate list in quick_start.rst. Link the list from the Shutdown section, and name the confirm key in both shutdown passages. Reframe the alignment steps so SQUARE reads as the screen's own start/save action, matching the START ALIGN and SAVE hints the screen draws. Also correct the shutdown wording: the power button emits its event only after a hold of more than a second, so the confirming press is a press and hold too, not a short press. Verified in code: keypad.KEYMAP/LONG_KEYMAP (joystick centre sends SQUARE, and LNG_SQUARE when held), menu_manager.key_long_square (Quick Menu), text_menu.key_right / key_power (Confirm-Cancel select, power acts as select on the shutdown menu), marking_menus.MarkingMenu (HELP is the UP option), keyboard_pi.run_keyboard (1s long-press and power thresholds), align.key_square and align_daytime.key_square (start, then save). Closes #647 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A new rev4 owner spent a first night unable to confirm a shutdown and kept landing in the
help menu instead. The canonical key list in
user_guide.rst("The Menu System") stoppedat scroll and select, so nothing told him that RIGHT is the confirm key on a
confirmation screen, or that SQUARE opens the Quick Menu rather than confirming. The
Quick Start's alignment steps reinforced the wrong habit by presenting SQUARE as the key
that "completes" a step.
What changed
docs/source/user_guide.rstthe confirm key (on a confirmation screen it selects the highlighted option, LEFT goes
back), and SQUARE does not confirm (press and hold for the Quick Menu, a short press
does whatever the current screen uses it for).
opens the Quick Menu, and that RIGHT is what confirms.
:ref:back touser_guide:the menu system, plus a line sayingSQUARE does not confirm on that screen.
and hold, not a short press (see below), and both passages now name RIGHT as the
alternative.
docs/source/quick_start.rstthe two keep-in-sync comments accurate.
action rather than a generic confirm. Step 3 now says "start the alignment" and step 5
"save the alignment", each naming the hint the screen actually draws (START ALIGN, SAVE),
followed by one line stating that SQUARE is not a general confirm key. The procedures
are unchanged in substance.
No new screenshots. The images in these sections are already at the rev4 352x352 size.
Key behaviours verified in code
LNG_SQUAREpython/PiFinder/keypad.py—KEYMAP/LONG_KEYMAPposition (4,4)ui/menu_manager.pykey_long_square()vskey_square();ui/base.pykey_square()defaults tocycle_display_mode(), which is a no-op when_display_mode_listis[None]ui/menu_structure.pylabelshutdown;ui/text_menu.pykey_right();ui/menu_manager.pykey_left()ui/text_menu.pykey_power()callskey_right()when the menu label isshutdown;ui/base.pykey_power()jumps to the shutdown label otherwiseui/marking_menus.py—MarkingMenu.updefaults toHELP;ui/text_menu.pygives every text menu a marking menuui/align.pykey_square()and itsSTART ALIGN/SAVE / 0 CANCELhints;ui/align_daytime.pykey_square()->_save_alignment()Where the issue and the code disagree
The issue says "a second short press of PWR on the shutdown confirm". There is no
short-press path for the power button at all.
keyboard_pi.run_keyboard()emitsPOWER_BTNonly once the GPIO has read low for more than one second, and latches until release, so
every power-button press is a press and hold of about a second, the confirming one included.
The manual said "Press the power button again", which understates the hold and is a plausible
part of why the customer could not confirm. Both shutdown passages now say "press and hold
the power button again".
Two smaller corrections to the issue's wording, both reflected in the text:
handed to the current screen, and on a menu screen it does nothing visible.
user_guide.rst"Shutdown" already named RIGHT, so that part needed only the cross-reference plus the
press-and-hold fix.
Verification
python -m sphinx -b html -E -n -q source /tmp/sphinx_647prints nothing. No em-dashes orsemicolons in the added lines.
Closes #647
🤖 Generated with Claude Code