Hello!
We would like to use Common UI to handle cardinal navigation on PC for gamepad, mouse and keyboard.
Navigation using gamepad and mouse is functioning, but we’re running into issues when trying to use the keyboard to navigate:
- Selection of a UI element (e.g. focusing on a button in a menu) is being shown as a blue outline, instead of the expected selection visuals
- Only the space bar works as an “accept” action, despite the default navigation actions being set up (e.g. Enter as Accept)
- It is possible for the UI to get stuck in a state where keyboard input does not allow cardinal navigation
It seems that the same issue is present in this Introduction to Common UI video, but unfortunately a solution is not reached.
To clarify, we’re not trying to support simultaneous mouse and keyboard navigation and understand that this would cause design issues, as mentioned in the documentation.
Here are some images showing visuals when navigating with mouse, gamepad and keyboard respectively:
[Image Removed]
[Image Removed]
[Image Removed]
In terms of specification, we’re looking for a solution that:
- Works with Common UI
- Works with Enhanced Input
- Supports cardinal navigation for gamepad, mouse and keyboard (including selection visuals)
- Supports the use of CommonActionWidget for displaying actions, for gamepad, mouse and keyboard
- Removes the blue outline for gamepad and keyboard navigation
What would be the best way to achieve this?
Thank you for your help.
Hi,
This is a bit of a tricky subject because of the considerations mentioned in that docs page you linked, but basically what you’re running into is inconsistency between two separate systems- CommonUI with it’s custom navigation handling and default actions, and Slate “native” navigation (i.e. the out-of-the-box keyboard navigation features). There are a few things you can do to bring these in line.
First, the blue outline is driven by Render Focus Rule in your project settings. The default is to show it when navigating (with Slate native navigation), but you can turn that off if it interferes with other visuals. CommonUI instead moves around an invisible cursor to trigger the hover visual of the button, you may be able to manually move that cursor over the focused widget to replicate similar behavior with keyboard navigation.
Second, the space key is the default accept key for Slate native navigation, but you can customize that by applying your own FNativationConfig (see FSlateApplication::SetNavigationConfig).
Finally, keyboard navigation is going to use our native hittestgrid-based navigation rules, unless you explicitly define navigation rules on each widget. Generally it should navigate to the thing that makes sense (as long as the only focusable widgets are something that should be focusable), though after focusing the viewport you’ll need to do something to manually bring focus back to a widget. Usually when you summon a menu, you might focus the first button- CommonUI already has pretty robust handling for that via DesiredFocusWidget to set focus when activating things, and that focused widget would be the same in both the CommonUI and native Slate domains, so you may just need to dig into where focus is moving when it gets stuck. The console slate debugger can help with that.
Hopefully that can get you pointed in the direction, it’s not super trivial to make keyboard and gamepad navigation behave similarly but a few changes should bring them more in line. With keyboard controls we assume a mouse is also present so there isn’t the same risk of softlocking that would be present with a gamepad player, but manually setting focus or customizing navigation rules can usually help keep things inbounds.
Best,
Cody