Emulator Issues #11563
open
Qt: Keyboard navigation of UI should be disabled in MappingWindow
Added by 8times9 almost 6 years ago.
Updated over 5 years ago.
Relates to performance:
No
Relates to maintainability:
No
Description
In the mapping window, when attempting to map the keyboard to various controls, many problems occur from the keyboard trying to navigate the MappingWindow's UI. For example, on Windows at least, it's completely impossible to map the spacebar to a control without right clicking on the button and entering the advanced mapping window, because pressing space acts as a left click on the mapping button (simply selecting that control to be mapped). Enter, the arrow keys, and tab are some other keyboard buttons that cause problems.
I don't know if disabling keyboard navigation of the UI is possible, but hopefully so.
*I don’t know if disabling keyboard navigation of the UI is possible in Qt
This is done by installing an event filter. However, that has already been done for mapping with BlockUserInputFilter. The problem is the event filter is removed the moment the button is bound. What happens is:
Select a key to bind -> eventFilter blocks all input -> "I want to bind space" Hit spacebar -> spacebar becomes bound -> eventFilter is removed -> spacebar has been released -> execute shortcut = select focused widget -> Select a key to bind. And thus it appears space never got bound.
How to fix? In MappingButton.cpp you could put a constant eventFilter for keyboard press & release, just like BlockUserInputFilter does it.
- Status changed from New to Accepted
Mapping for space, enter, and mouse clicks were fixed in 5.0-10091 but there's still some weirdness with arrow keys and tab.
If any controls are mapped to the arrow keys or tab, then pressing them to test out the mapping will cause the selection to move around between text boxes, other buttons, and checkboxes.
Example:
Let's say the d-pad is mapped to the arrow keys and enter is set to START (a common mapping scheme) on the GameCube mapping pane. If the user were to finish mapping any button (including d-pad or START) and then were to test the arrow keys, the blue selection box would be moved around to different buttons or dead zone/threshold text boxes. Then if they pressed enter to test START, that mapping button would now be selected for input and they will probably mess up their control scheme by pressing any other buttons. And if the arrow keys move to a dead zone or threshold text box by accident and the user were to press any numbers (admittedly somewhat edge-case but more probable if they're using a 10-key pad as the d-pad or something) then those values would get messed up.
I know that's a very long example, but at least for me it happens a lot more than you'd think.
- Status changed from Accepted to Questionable
Mouse clicks can do things too, but I don't think you want buttons unclickable. :P
Clicking on an empty part of the window before testing keys works around the problem.
It can be annoying for sure but I don't think we should just completely disable keyboard navigation in the entire window.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by