This allows removing it from `class_db.h`, significantly reducing the amount of files
that include it transitively.
Also includes some include cleanup in `control.h` and `rich_text_label.h` done while
ensure they don't depend on `callable_mp`.
This will allow decoupling `display_server.h` from a number of headers in the
codebase which only require those enums and not all the DisplayServer API.
- Removes `native_menu.h` dependency from `display_server.h`.
It's now forward-declared in all DisplayServer implementations and should
be included in the .cpp's.
- Removes some unused `rb_set.h` and `rb_map.h` dependencies, which leads to
having to include them explicitly in half the scene and editor codebase...
which shows how much we depend on `display_server.h`.
- Forward-declare `input_event.h`, so now we need only `keyboard.h`.
Fixes#81758
DisplayServerWeb::process_joypads handles buttons 6 and 7 of the
HTML5 Standard Gamepad as a special case by doing:
`input->joy_axis(idx, (JoyAxis)b, s_btns[b]);`
This doesn't work because there is no JoyAxis 6 or 7 in the enum
To fix this we use JoyAxis::TRIGGER_LEFT and TRIGGER_RIGHT for button 6
and 7
However since we are now lying to input->joy_axis we also need to lie in
the mappings for the standard gamepad in godotcontrollersdb.txt,
otherwise input->joy_axis will try to find a mapping to axis 4(LT) and
axis 5(RT) that's not defined.
Therefore we set lefttrigger to +a4 and righttrigger to +a5 in the
mapping, to match what we are actually sending.
A cleaner, and more involved fix to this would be modifying
input->joy_button so that it can handle analog buttons and map them to
axes preserving their value instead of converting to boolean
This adds a new enum `KeyLocation` and associated property
`InputEventKey.location`, which indicates the left/right location of key
events which may come from one of two physical keys, eg. Shift, Ctrl.
It also adds simulation of missing Shift KEYUP events for Windows.
When multiple Shifts are held down at the same time, Windows natively
only sends a KEYUP for the last one to be released.
This applies our existing style guide, and adds a new rule to that style
guide for modular components such as platform ports and modules:
Includes from the platform port or module should be included with relative
paths (relative to the root folder of the modular component, e.g.
`platform/linuxbsd/`), in their own section before Godot's "core" includes.
The `api` and `export` subfolders also need to be handled as self-contained
(and thus use relative paths for their "local" includes) as they are all
compiled for each editor platform, without necessarily having the api/export
matching platform folder in the include path.
E.g. the Linux editor build will compile `platform/android/{api,export}/*.cpp`
and those need to use relative includes for it to work.
