gui_navigation.rst 3.4 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
  1. .. _doc_gui_navigation:
  2. Keyboard/Controller Navigation and Focus
  3. ========================================
  4. It is a common requirement for a user interface to have full keyboard
  5. and controller support for navigation and interaction. There are two main
  6. reasons why this is beneficial for projects: improved accessibility (not everyone
  7. can use mouse or touch controls for interactions), and getting your project
  8. ready for :ref:`consoles <doc_consoles>` (or just for people who prefer
  9. to game with a controller on PC).
  10. Navigating between UI elements with keyboard or controller is done by
  11. changing which node is actively selected. This is also called changing UI focus.
  12. Every :ref:`Control <class_Control>` node in Godot is capable of having focus.
  13. By default, some control nodes have the ability to automatically grab focus
  14. reacting to built-in UI actions such as ``ui_up``, ``ui_down``, ``ui_focus_next``, etc.
  15. These actions can be seen in the project settings in the input map and can be modified.
  16. .. warning::
  17. Because these actions are used for focus they should not be used for any
  18. gameplay code.
  19. Node settings
  20. -------------
  21. In addition to the built-in logic, you can define what is known as focus neighbors
  22. for each individual control node. This allows to finely tune the path the UI focus
  23. takes across the user interface of your project. The settings for individual
  24. nodes can be found in the Inspector dock, under the "Focus" category of the
  25. "Control" section.
  26. .. image:: img/focus_settings.png
  27. Neighbor options are used to define nodes for 4-directional navigation, such
  28. as using arrow keys or a D-pad on a controller. For example, the bottom neighbor
  29. will be used when navigating down with the down arrow or by pushing down on
  30. the D-pad. The "Next" and "Previous" options are used with the focus shift button,
  31. such as :kbd:`Tab` on desktop operating systems.
  32. .. note::
  33. A node can lose focus if it becomes hidden.
  34. The mode setting defines how a node can be focused. **All** means a node can
  35. be focused by clicking on it with the mouse, or selecting it with a keyboard
  36. or controller. **Click** means it can only be focused on by clicking on it.
  37. Finally, **None** means it can't be focused at all. Different control nodes have
  38. different default settings for this based on how they are typically used, for
  39. example, :ref:`Label <class_Label>` nodes are set to "None" by default,
  40. while :ref:`buttons <class_Button>` are set to "All".
  41. Make sure to properly configure your scenes for focus and navigation. If a node has
  42. no focus neighbor configured, the engine will try to guess the next control automatically.
  43. This may result in unintended behavior, especially in a complex user interface that doesn't
  44. have well-defined vertical or horizontal navigation flow.
  45. Necessary code
  46. --------------
  47. For keyboard and controller navigation to work correctly, any node must be focused on
  48. using code when the scene starts. Without doing this, pressing buttons or keys won't
  49. do anything. Here is a basic example of setting initial focus with code:
  50. .. tabs::
  51. .. code-tab:: gdscript GDScript
  52. func _ready():
  53. $StartButton.grab_focus()
  54. .. code-tab:: csharp
  55. public override void _Ready()
  56. {
  57. GetNode<Button>("StartButton").GrabFocus();
  58. }
  59. Now when the scene starts the "Start Button" node will be focused, and the keyboard
  60. or a controller can be used to navigate between it and other UI elements.