GUI: Let Ctrl and Alt hotkeys through when a list has focus - #7858
GUI: Let Ctrl and Alt hotkeys through when a list has focus#7858ObjectInSpace wants to merge 1 commit into
Conversation
ListWidget's quick selection mode claimed every printable key without checking for modifiers, and reported the key as handled. Since Dialog gives the focused widget first refusal on key presses, this meant that no dialog hotkey worked while a list held the focus. In the launcher, where the game list has the focus by default, Ctrl+O and the other shortcuts did nothing at all. Skip quick selection for keys held with Ctrl or Alt, so that they reach the hotkey handling in Dialog::handleKeyDown(). Assisted-by: Claude:claude-opus-5
|
Indiscernible from bot spam. |
|
Is there a problem with this PR? |
4d5445c to
5c1ab22
Compare
@sluicebox It is partly authored by Claude as noted ... but I do think this change is not unreasonable if tested manually for behaviour. |
@ObjectInSpace I think the issue is that we (like a large number of open source projects) are getting deluged by a lot of low quality PRs generated by new contributors with various LLM licenses hence it is necessary to determine if you are actually just a drive by bot or a human being who produces a nice banana bread receipe for us? |
|
@ObjectInSpace One thing to note is that we prefer to avoid merge commits in PRs so I have edited your branch to remove that. These tend to foul up the "Rebase and merge" when we are ready to accept a PR. |
|
@sev- I think this is worth a quick look as it looks to be a fairly self contained change in GUI behaviour associated with keyboard shortcuts and not unreasonable with a little bit of testing. |
|
Thanks, makes sense. I'll remember not to rebase in future. For context, I am a person, looking to improve accessibility of ScummVM. The first thing I'm tackling is making the TTS read when the user tabs around the launcher as well as with the mouse. I haven't submitted that yet because I'm still working on it. On the way though I noticed this, and it seemed like a better way to introduce myself since it is a smaller change. :) I do use claud to assist with the implementation since I lack the coding knowledge, my understanding is that's permitted for this project. I am pretty specific about what I'm tryin to achieve though and I test everything riggorously. I observed that pressing ctrl+o to open the options would get swallowed, either by the edit field (which types an o) or the list of games, which either routs selection to the nearest game with an o in it, or if there aren't any, does nothing. With this patch, it opens the options page as expected. Hope that clarifies things. Happy to make any modifications that are needed if there's anything amiss! |
ListWidget's quick selection mode claims every printable key without checking for modifiers, and reports the key as handled. BecauseDialog::handleKeyDown()gives the focused widget first refusal on key presses, no dialog hotkey works while a list holds the focus.In the launcher the game list has the focus by default, so
Ctrl+Ofor Global Options,Ctrl+Gfor Game Options andCtrl+Sto start a game all do nothing —Ctrl+Ois picked up by quick selection instead and moves the selection to a different game.This skips quick selection for keys held with Ctrl or Alt, so they reach the hotkey handling further down
Dialog::handleKeyDown(). Plain letters still quick-select as before.Tested on Windows (MinGW/SDL2):
Ctrl+Onow opens Global Options with the game list focused, and typing a letter still jumps to the matching entry.