gui_navigation.rst 3.5 KB

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