You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update input event flow graphic based on recent changes.
Made some descriptions more precise.
Input Event table:
- Added missing InputEvents Gesture, MIDI and Shortcut
- Removed unused Type Index column
Copy file name to clipboardExpand all lines: tutorials/inputs/inputevent.rst
+56-45Lines changed: 56 additions & 45 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -61,19 +61,19 @@ How does it work?
61
61
62
62
Every input event is originated from the user/player (though it's
63
63
possible to generate an InputEvent and feed them back to the engine,
64
-
which is useful for gestures). The OS object for each platform will read
65
-
events from the device, then feed them to the :ref:`Window <class_Window>`.
64
+
which is useful for gestures). The DisplayServer for each platform will read
65
+
events from the operating system, then feed them to the root:ref:`Window <class_Window>`.
66
66
67
67
The window's :ref:`Viewport <class_Viewport>` does quite a lot of stuff with the
68
68
received input, in order:
69
69
70
-
.. image:: img/input_event_flow.png
70
+
.. image:: img/input_event_flow.webp
71
71
72
72
1. If the Viewport is embedding Windows, the Viewport tries to interpret the event in its
73
73
capability as a Window-Manager (e.g. for resizing or moving Windows).
74
74
2. Next if an embedded Window is focused, the event is sent to that Window and processed in
75
-
the Windows Viewport. If no embedded Window is focused, The Event is sent to the nodes of
76
-
the current viewport in the following order.
75
+
the Windows Viewport and afterwards treated as handled. If no embedded Window is focused,
76
+
the event is sent to the nodes of the current viewport in the following order.
77
77
3. First of all, the standard :ref:`Node._input() <class_Node_method__input>` function
78
78
will be called in any node that overrides it (and hasn't disabled input processing with :ref:`Node.set_process_input() <class_Node_method_set_process_input>`).
79
79
If any function consumes the event, it can call :ref:`Viewport.set_input_as_handled() <class_Viewport_method_set_input_as_handled>`, and the event will
@@ -96,17 +96,17 @@ received input, in order:
96
96
:ref:`InputEventShortcut <class_InputEventShortcut>` and :ref:`InputEventJoypadButton <class_InputEventJoypadButton>`.
97
97
If any function consumes the event, it can call :ref:`Viewport.set_input_as_handled() <class_Viewport_method_set_input_as_handled>`, and the
98
98
event will not spread any more. The shortcut input callback is ideal for treating events that are intended as shortcuts.
99
-
6. If so far no one consumed the event, the :ref:`Node._unhandled_input() <class_Node_method__unhandled_input>` callback
100
-
will be called if overridden (and not disabled with
0 commit comments