Repository navigation
feat(menu): Esc opens the Insert menu by default (Menu shortcut "Insert, F1 or Esc") - #2197
Conversation
…rt, F1 or Esc") On PC, Esc is the key that opens a game's menu, and players expect it: after NotRexed#1998 added Esc as an opt-in Menu shortcut choice, a player asked in #dev-work why Esc closes the Insert menu but does not open it. The opt-in choice is now the default, for existing players too. - gpu/vk/vk_menu.h: menu_shortcut defaults to 2, "Insert, F1 or Esc". - gpu/vk/vk_menu.cpp: options_version 5. The menu writes every row, so a file from before has menu_shortcut=0, the old default, whether it was chosen or not; menu_init moves that 0 to 2, as for Game speed (2) and Descriptor reuse (4). Insert and F1 still open the menu after the move, so nothing is taken away. F1 only (1) can only have been chosen and stays; 2 stays. A file saved from now on keeps any choice, Insert or F1 included. - Esc still lets a captured mouse go first, and the menu it opens gives the capture back when it closes (NotRexed#1998, NotRexed#2035; unchanged). No control can be bound to Esc, so nothing in play changes. - readme.md: the menu's keys, the move of older options, and the Menu shortcut row's values and default in the options table. - tests/test_menu_keys.py: compiles menu_tick's Esc block with the real Options and the row's names. Out of the box the shortcut is "Insert, F1 or Esc" and Esc opens a closed menu without the same press going back a page. It also compiles menu_init's reading of the options file and loads files through it: before options_version 5, 0 loads as 2, 1 and 2 stay; at the version save() writes now, every choice stays. Replaces the text check that pinned the old default. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
# Conflicts: # gpu/vk/vk_menu.h
|
Merged main in to clear the conflict with #2181 (no force-push). The FPS counter rows from #2181 are kept as they are, and the Menu shortcut default is 2 again on top. On Esc and keyboard play: agreed. Once the game takes keyboard and mouse input, Esc should open the game's own menu. Then the default can move again with the next (Still open: #2110 also writes |
Windows CI's clang uses the MSVC CRT, which marks fopen deprecated; with -Werror the fixture's options-file stub and the cut-out load did not build. The same define the other source-reading tests and the game's own Windows build pass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
# Conflicts: # readme.md
Joey-Magnus
left a comment
There was a problem hiding this comment.
This looks good. The migration is the right shape: only a pre-version-5 menu_shortcut=0 moves to 2 (gpu/vk/vk_menu.cpp:2956), F1 only is left alone, and save() writes options_version=5 (gpu/vk/vk_menu.cpp:1374), so a player who picks Insert or F1 again keeps it. I checked the places where a new default for Esc could leak into play:
- The keyboard is polled only while our window has the focus (
mineinmenu_tick), so Esc pressed in another app doesn't open the menu. - The right mouse button and the gamepad's back button only count as Esc while the menu is open (
press[5]from the pointer is read only underopen_now, andpad_backlikewise), so a right click or B in game doesn't open it. esc_opensclearspress[5], so the press that opens the menu doesn't also go back a page.
The rewritten tests/test_menu_keys.py is stronger than the text check it replaces: it compiles the real Esc block and menu_init's reader against real files. I ran it at the PR's head, together with test_menu_env_on, test_menu_restart, test_menu_restart_slots and test_display_pointer: all pass. The branch merges cleanly onto current main (still at options_version=4). The two red CI jobs are unrelated: test_native_astc_texture_count.py on Windows, fixed on main by #2397, and a Launchpad PPA timeout in appimage. A re-run or a merge of main should clear them.
One thing to keep in mind rather than change:
- minor #2110 is still open and also claims
options_version5. Whichever merges second has to renumber both itssave()line and itsversion < Ncheck (and its test's expected version), or the second migration will never run for files the first one already rewrote. You've already said you'll take 6 if this one lands second; just flagging it so the maintainer merging the second one checks it.
# Conflicts: # gpu/vk/vk_menu.h vk_menu.h: menu_shortcut stays 2 beside main's new compact_menu_key (NotRexed#2378). tests/test_menu_keys.py: the fixture stubs tune_mode and tune_down, which menu_tick's Esc block now sets (NotRexed#2378), and has_vram_budget and has_memory_budget, which menu_init's options loader now reads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… and doc fixes A self-review of the PR's diff found that the test checked only versions 2 to 4: a later bump of save()'s version without menu_init's threshold would still pass. It now loads every version below the one save() writes. - tests/test_menu_keys.py: every older options_version, and Esc with the compact menu key held opens the compact bar, as Insert and F1 do (NotRexed#2378). - readme.md: Esc goes back or closes with every Menu shortcut; the choices cell uses semicolons, as one name has a comma. - docs/development.md: save() writes options_version=5. - vk_menu.cpp: the Esc comment names RX_VK_MENU_SCRIPT's ESC and the compact bar. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Merged main: the |
NotRexed#2197 (Esc opens the menu by default) took options_version 5 on main, so the Aspect ratio's move of an older file's 16:9 is now version 6: save() writes 6, menu_init and host/hos_wide_size.h hos_aspect_on move ultrawide=0 from files before 6, and both moves are kept in menu_init. tests/test_menu_keys.py (from NotRexed#2197) expected every version below the one save() writes to move Insert or F1 to Insert, F1 or Esc, which would move a version 5 file's chosen Insert or F1 again. It now reads the move's version from menu_init and checks that files from it up to save()'s version keep their choice; its host stub gains aspect_ratio, which menu_init's Aspect ratio move asks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Joey-Magnus
left a comment
There was a problem hiding this comment.
The conflict is one line (vk_menu.h, main's new compact_menu_key). After resolving it, the rewritten tests/test_menu_keys.py doesn't compile against main, because menu_tick/menu_init now use tune_mode, tune_down, has_memory_budget and has_vram_budget, which the fixture doesn't stub. The red checks are main's old ASTC failure and a PPA timeout.
options_version=5 is also used by #2119 and #2110. Suggested order: this one, then #2177, then #2119 rebased, with later ones renumbering their save() line, version < N check and tests.
…2119, NotRexed#2197, NotRexed#2481, NotRexed#2496) NotRexed#2177 landed (squashed), so this takes main's sections as they shipped and keeps this PR's change on top: the Screen, HDR and Overlays rows on the Display tab. Main's newer rows go with them, word for word: NotRexed#2119's Aspect ratio and Ultrawide menus text and NotRexed#2481's HDR tone mapper (last in Display's HDR). Every one of main's 88 rows keeps main's definition; the only changes are the moved rows' tab and the Overlays heading. draw_options keeps main's Save my pipeline list line (NotRexed#2447) with the restart line on Display too. The readme takes main's Menu shortcut text (NotRexed#2197) with six tabs, NotRexed#2177's VRAM budget line, and main's HDR tone mapper and Field of view lines. test_menu_sections.py pins Aspect ratio by name and HDR tone mapper in Display's HDR; test_scene_tonemap_pass.py (NotRexed#2481) finds the tone mapper row on Display. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
NotRexed#2197, NotRexed#2481, NotRexed#2496) into feat/menu-game-tab Takes NotRexed#2178 as merged with main (cf90c14f) and keeps this PR's change on top: the Game tab first, where the menu opens. Main's new Gameplay row, Field of view, goes with the Game rows at the table's top, word for word, after Game speed. Every one of main's 88 rows keeps main's definition; the only changes are the moved rows' tab (Display) and the Overlays heading. The readme takes main's Menu shortcut text (NotRexed#2197) with this PR's tab sentence, and Field of view among Game's rows. The tab enum, the strip's titles and the control bridge's names follow the same Game-first order. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Port of upstream NotRexed#2197. The Menu shortcut row now starts on "Insert, F1 or Esc" (options_version 5). An older file's 0 was the old default written whether chosen or not, so menu_init moves it to 2; Insert and F1 still work and Esc is added. 1 (F1 only) and 2 stay. F1 always opens the menu.
On PC, Esc is the key that opens a game's menu, and players expect it: after #1998 added Esc as an opt-in Menu shortcut
choice, null asked in #dev-work why Esc closes the Insert menu but doesn't open it. This makes that choice the default,
for existing players too.
What changed
gpu/vk/vk_menu.h:menu_shortcutdefaults to 2, Insert, F1 or Esc. On a closed menu Esc opens it; while it isopen Esc still goes back a page or closes it. F1 always works, and the row still offers Insert or F1 and F1 only.
options_version5). null is an existing player, and so is nearly everyone who wouldnotice this. The menu writes every row on save, so the old default,
menu_shortcut=0(Insert or F1), is in everyoptions file whether the player chose it or not. A default that only new installs get wouldn't reach them. Like Game
speed (version 2) and Descriptor reuse (version 4),
menu_initnow moves an older file's 0 to 2. Only 0 moves:save()writesoptions_version=5, so a player who picks Insert or F1 from now on keeps it.lands second takes 6; it's a one-line renumber plus its test, and I'll do it here if this one is second.
closes (
esc_had_capture, feat(menu): Esc can open the Insert menu (Menu shortcut "Insert, F1 or Esc") #1998 and fix(menu): keep the mouse free after Escape then F1 #2035, unchanged here). No game control can be bound to Esc (bindable_keys,host/nn_hid.cdefaults), and a gamepad's back button counts as Esc only while the menu is open.readme.md: the menu keys paragraph (with the move of older options), and the Menu shortcut row's values and defaultin the options table.
tests/test_menu_keys.py:menu_tick's Esc block with the realOptionsfromvk_menu.hand the row's names(
tx_menu_shortcut). Out of the box the shortcut is "Insert, F1 or Esc", and Esc opens a closed menu without the samepress going back a page. With Insert or F1 or F1 only, Esc leaves it closed. Both polled and queued presses.
menu_init's reading ofhookshot_options.iniand loads real files through it. From beforeversion 5 (versions 2 to 4, or no
options_versionline): 0 loads as 2, 1 and 2 stay, no line gets 2. At theversion
save()writes now, read fromsave()itself: 0, 1 and 2 all stay.int menu_shortcut = 0;).Testing
tests/test_menu_keys.pypasses, and each part fails without its change:loaded_as(0, old) == 2fails;save()left writingoptions_version=4:loaded_as(mode, 4) == modefails (a choice made after the change wouldbe moved again).
test_menu_env_on,test_audio_output_menu,test_framegen_preset,test_rumble_menu,test_vsync_row,test_audio_volume,test_menu_size,test_stick_dead_zone,test_menu_hit,test_menu_restart,test_menu_restart_slots,test_gpu_choice,test_display_pointer,test_screensaver.tests/run_all.pyon Windows (llvm-mingw), on maine19d969with this change: 341 passed, 2 failed, 30 skipped.The two failures fail the same way on untouched main on this PC:
test_precompile_compute_guard(this toolchain has nowindows.hfor its fixture) andtest_recorder_sync(its exit case; itsvk_menu.cppsource checks pass).Not tested: in game (no build of this branch was run; the Esc behaviour itself is #1998's, which was played),
Linux.
Screenshots: nothing new on screen. The row and its values are #1998's; it now starts on "Insert, F1 or Esc".
🤖 Generated with Claude Code