Menus redesign (#148 step 5) #159
No reviewers
Labels
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
schaefera/utStudyBIble!159
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/redesign-menus"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
Step 5 of #148: the Modules ⋮ menu (Import, Refresh) and the text fields' edit menu (Cut, Copy, Paste, Select all) were plain Suru.
AppMenuandAppMenuItemreplace them andIconMenuItem: the page's ground, a hairline, 12 px corners, our colours for text and icons, greyed rows in secondary.The e2e hook moves from PageBar to AppMenu, so an edit menu reports its rows too. A new case,
menus, covers the colours and Select all then Cut.Blast radius
Tier: trunk
Trunk paths touched:
tools/e2e/(the new case only; the rest is leaf QML and docs)Testing tier: standard (and styling)
Gate / rollback: no flag; revert this merge.
Budgets: peak PSS 172891 kB normal, 178155 kB slow (budget 185000 kB). The budget is not raised. No start-up work added beyond the menus' existing eager creation.
Proof
cargo make: pass.cargo make app-docker: pass (both on094c175, before the hook-order fix).cargo make i18n: no change. CI run 324 onf6ed2dd: all six jobs green.E2E_CASES="menus import-url menu-page" cargo make shots: all pass on the final tree.#ff0000givesFAIL: the menu is not in our colours ('#ff0000 #ff0000 #22201c #faf8f3'); Cut's handler emptied givesFAIL: no 'utsb: text entry ''' (x1) after 5 s.ute2e): both menus looked at in light and dark with a live theme switch; a tap on an icon acts; a real finger's Select all, hold, Cut empties the field. This found Suru's dimming of disabled rows, now pinned. The greyed colour stays out of e2e, whose style doesn't dim.f6ed2dd: "Works, go for it".Review
Reviewer: claude-review, level high, at
094c175(review 406); answers in review 407. No re-review: the one fix,f6ed2dd, is not in a trunk path.Review-Confidence: 80
Left open, low:
console.infoinAppMenu.onOpenedis not guarded by--e2e. It logs names, positions and colours, no user text, once per menu opened. The auditor counted this against the score.Confidence by part
menuscase: high locally and in one CI run; it is new, so its stability over many runs is not known.🤖 Generated with Claude Code
Review level: high. Blast radius: trunk (tools/e2e/). Testing tier: standard + styling.
Commit:
094c175a34. Range: origin/main...HEAD (base6c46789).Files: docs/10-design.md, qml/controls/AppMenu.qml, qml/controls/AppMenuItem.qml, qml/controls/IconMenuItem.qml (deleted), qml/controls/PageBar.qml, qml/controls/TextEntry.qml, qml/controls/qmldir, qml/pages/ModulesPage.qml, qml/qml.qrc, tools/e2e/cases/menus.sh. Also read for context: tools/e2e/lib.sh, tools/e2e/cases/menu-page.sh, import-url.sh, qml/platform/SystemColours.qml, PopupTheme.qml (+ut/), qml/theme/Theme.qml.
Findings outside the diff lines: none. Every IconMenuItem reference is gone (qmldir, qrc, ModulesPage); the only other PageBar
menu:user is ModulesPage. The e2e_page_menu helper and import-url.sh still match the "utsb: menu x y" lines.Findings (one inline on menus.sh; two more below tied to lines in the diff, see also inline):
field.selectedTextis "" and Cut is disabled. The case then taps a disabled row and waits 5 s for "utsb: text entry ''", failing. Not run here (no Xvfb); the existing shots only reach the first edit menu. If the CI e2e job passes, disregard. Safer: select with xdotool (ctrl+a) after the hold's menu, or hold then re-select, or assert Cut via a Select all followed by key ctrl+x.@ -0,0 +47,4 @@e2e_hold $fielde2e_wait 'utsb: menu editSelectAll ' 1 5e2e_check_colourslow · reads the last 'menu colours' line right after the editSelectAll line, but AppMenu logs the colours line after its loop: a read in between returns the page menu's older line, so this check can pass without looking at the edit menu (and the one at line 38 can fail on an empty line). Wait for the colours count to rise instead.
@ -0,0 +53,4 @@sleep 0.5seen=$(e2e_count 'utsb: menu editCut ')e2e_hold $fieldmedium · the press that starts this hold lands on the field with all text selected (Select all just above). A press without Shift moves the cursor and deselects in a TextInput, so Cut is disabled when the menu opens, the tap on editCut does nothing, and line 58's wait for "text entry ''" times out after 5 s. Re-select after the hold opens (or select by key) so Cut is enabled. Unverified here (no Xvfb); disregard if CI e2e is green.
Answers to review 406 (author).
menus.sh:56, a second hold clears the selection and Cut stays disabled: refuted by running it. The case passes locally (menus: Select all then Cut emptied the field), and on the phone with a real finger: typedabc, held, Select all, held again; the selection stayed, Cut was enabled, and Cut emptied the field (build at094c175plus this fix).menu coloursline: fixed inf6ed2dd. AppMenu logs the colours before the rows, so a case that has seen a row can read them, and the second check reads the edit menu's line.menus,import-urlandmenu-pagepass.icon.colorunder Suru: checked on the phone. The glyph is always a disabled ToolButton, and the phone shows it tinted in our colour in light and dark. The greyed rows show in the secondary colour in both, after pinning opacity against Suru's dimming. It stays out of e2e, because e2e's style doesn't dim, so a check there wouldn't catch the Suru behaviour.console.infoinonOpened: left as is. It logs names, positions and colours, no user text, once per menu opened, matching the page menu's and the reading pane's hooks. TextEntry's hook is guarded because it logs what the reader types.WIP: Menus redesign (#148 step 5)to Menus redesign (#148 step 5)Merge gate at
f6ed2dd. Approved.f6ed2dd. The diff since094c175only moves the colours log ahead of the row logs in AppMenu.onOpened, with nothing else changed.