DocsBehavior
Keyboard and gamepad focus
Every button can take keyboard and gamepad focus in both runtimes. With nothing set, arrows and the d-pad move to the nearest button in that direction. Set neighbours when the layout needs something else.
"focus": {
"down": "<button id>", "up": "<button id>", "left": "…", "right": "…",
"next": "…", "prev": "…",
"initial": true,
"ring": { "color": "$ember", "width": 1, "offset": 0 }
}
- Arrows, d-pad, left stick go to
up,down,left,right, else to the nearest button by position. - Tab and Shift Tab follow
nextandprev, else the natural order. - initial focuses that button when the screen opens. An overlay’s initial button wins; closing the overlay returns focus to the button that opened it.
- ring draws an outline while a button has keyboard or gamepad focus, not after a mouse click. The hover look applies on focus too.
- A neighbour that’s disabled or hidden is skipped.
In the editor, the compass in the inspector picks neighbours from the buttons on the screen, and document checks flag a neighbour that doesn’t exist, isn’t a button or sits on another screen.
Runtimes
- Web: keys work on the focused button. Gamepads are read with the Gamepad API: d-pad or left stick move (held directions repeat), A presses, B closes the top overlay. Pass
gamepad: falseto turn it off. - Godot: neighbours become
focus_neighbor_*,focus_nextandfocus_previous; unset directions use Godot’s own search.ui_acceptpresses andui_cancel(Escape, gamepad B) closes the top overlay. Callui.focus_first_button()to start navigation.
Try it on the home page: click the menu and use the arrow keys.
Updated View as Markdown