Repository navigation
Insert menu: free the mouse while it's open, and make the menu clickable - #946
Merged
Merged
Conversation
…: hover selects, tabs, value halves, toggles, sliders (click or drag), the wheel; the capture comes back on close
hckrman101
marked this pull request as ready for review
November 9, 2026 02:43
Owner
|
Thanks! This is a draft that hasn't been tried with a real mouse yet. Closing to keep the queue clear; please reopen once it has had that test. |
Collaborator
Author
|
Reopened: this has now had the live test with a real mouse on Linux (hover, clicks, sliders, wheel, and the capture returning on close all work), and it's up to date with main. Windows still needs a try; the Win32 side is described under Not tested. |
AR51AurA
added a commit
to AR51AurA/Hookshot
that referenced
this pull request
Nov 9, 2026
Conflicts with the Insert menu's mouse (NotRexed#946): the host table takes pointer, then mic_count and mic_name, in the same order in host/rx_backend.c, MKWVK_API_VERSION 8; the menu's row changes go through NotRexed#946's set_row, which keeps the Microphone row out of the quality preset as before. Assisted-by: Claude Opus 5.5 (Anthropic) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
24 of 27 tasks
NotRexed
pushed a commit
that referenced
this pull request
Nov 9, 2026
…m update list (#939); screensaver fixture follows #946 #939's precompile pool started building without ub_thread_off(), unlike every other background shader thread, so its builds could race the replay's uniform updates (tests/test_ub_threads.py caught it). The screensaver fixture mocks the mouse handling #946 added to the window procedure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Nov 9, 2026
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.
What and why
While the in-game menu (Insert / F1) is open, the mouse stayed in the game's capture: hidden, relative, and still turning the camera. The menu could only be used with the keyboard or a gamepad.
With this change the mouse is released while the menu is open, and the menu can be used with it. When the menu closes, the capture goes back to what it was before (captured for mouse camera, or free if it was free).
The change
Mouse release (host/display.c on Windows, host/posix/display_sdl.c on Linux)
WM_APP + 8, the same channel the Fullscreen row already uses withWM_APP + 7).hos_mouse_takereports the mouse as not captured, andnn_hid.calready ignores keys and mouse buttons while the menu is open.Clicks (gpu/vk/vk_menu.cpp, new gpu/vk/vk_menu_hit.h)
MkwVkHost.pointer, gives the renderer the free mouse: the cursor position in window pixels and the window's pixel size, the buttons held, the presses since the last read and the wheel notches.MKWVK_API_VERSIONis bumped to 5.vk_menu_hit.hholds the layout constantspaint_menunow draws with and a pure hit-test, so the picture and the hit areas can't drift apart.[Q / LB]/[E / RB]hints get a lighter highlight. A cursor resting over the menu when it opens does not move the keyboard selection.[Q / LB]or[E / RB]goes to the previous or next tab.<side) steps it down. The right half (the>side) steps it up.set_rowfunction that both use.SDL wrapper (host/hos_sdl.c/.h): mouse button up, wheel and enter events, the button and position on button events, the absolute position on motion events (SDL3 and SDL2 layouts), and
SDL_GetWindowSize.Tests
New
tests/test_menu_hit.py(registered intests/run_all.pywith--cxx g++). It compilestests/test_menu_hit.cppand checks the hit-test:It also checks the sources: the menu hit-tests with the shared layout, posts open/close to the window, and both window procedures release the mouse, give it back and don't capture on a click while the menu is open.
python -I -B tests/run_all.py: 106 passed, 0 failed, 6 skipped (Linux).Linux build (SDL3, Wayland): the game and
hookshot_vk.sobuild with this change, and the ABI check passes (no undefinedmkwvksymbols). The game started and presented normally at 60 fps.A live mouse run (a headless compositor output, with clicks injected through the compositor's seat cursor) did not reach the menu. The injected keypress never opened the menu, and a later run was cut short. Since then it has been tried by hand on Linux (SDL3, Wayland) with a real mouse, in the merged build with the Cheats pages: the cursor appears when the menu opens, and hover, clicks, the sliders, the wheel and the capture coming back on close all work.
Not tested
Notes
MkwVkHost(Control bridge: drive a running game over a local socket, with a CLI #926 also bumpsMKWVK_API_VERSIONto 5). Whichever lands second needs a trivial rebase there and anotherMKWVK_API_VERSIONbump.