This fixes once and for all the core issue of different Godot `keycode`s
released from the same raw XKB keycode.
The `InputEventKey` `keycode` value _should_ map to the "unmodified"
key, but unfortunately there's an ambiguity with their encoding for
"special" keys ("delete", "insert", etc.), in witch they ignore their
unicode representation. This means that a key that is special when plain
but a character when modified would never be properly picked up, so we
do indeed change its keycode. As a consequence of this exception, some
Godot keys never receive release events and get "stuck".
This patch adds an extra check through an `HashMap` to "unstuck" keys
that changed while having the same keycode.
I also could not resist simplifying a bit the regular key event
generation method but this makes things more consistent and predictable
IMO.
When using runtime data in a TileMapLayer, calling notify_runtime_tile_update
can cause error messages to be printed to the console if the same cell has been
set or erased in the same frame. This could be partially worked around by using
call_deferred on notify_runtime_tile_update, but the problem could re-emerge if
those updates were being made in coroutines.
This commit addresses the issue by adding an additional check to the dirty cell
marking of the TileMapLayer when notify_runtime_tile_update is called. This
check ensures that the cell has not already been added to the dirty cell list,
preventing the condition that causes the error message.
There were two edge cases in the frame waiting logic (aka manual frame
throttling or emulated vsync) which would cause the editor to stall in
one way or another:
1. Waiting right after starting the editor would cause a deadlock
between both threads until something happened in the Wayland event
queue, in turn unblocking the Wayland thread and kickstartin the whole
thing;
2. Starting the editor (and probably other long-loading stuff) without
low consumption mode would suspend the window and never commit its
surfaces, thus never signaling the compositor that we want frame events.
Fixes#97066
`RBSet` were used on `RotatedFileLogger` because it guarantees that
iterating it is done via `operator<`. This is important because
`RotatedFileLogger` depends on this behavior to delete the oldest log file.
On #61194 `HashSet` was added and all `RBSet` uses were replaced by
`HashSet`.
When that happened, the iteration in order is guaranteed to be the insertion
order, wich made that `RotatedFileLogger` delete the newest log file.
As a bonus, I added unit test for `RotatedFileLogger` and `CompositeLogger`.
We should only include the vendored headers for Wayland and libdecor-0 when
we use `so_wrap`, i.e. when we *don't* build against system libraries.
The libdecor-0 pkg-config file includes the `libdecor-0/` prefix already,
so its header should be included without it, and likewise in our so wrappers.
Fixes#102671.
