It is required to redirect keyboard input (both physical or not) when
a GUI line edit is focused. This means other components cannot be
activated on key presses.
Therefore, this new component is meant as a higher-level abstraction
compared to the `keyboard`/`pad`/`mouse` components, which:
- Implements the same APIs provided by `keyboard`, `mouse` and `pad`.
- Returns the same results as the APIs above if no GUI element is
focused, no input otherwise.
Note: replacing calls to `keyboard`/`pad`/`mouse` with `input` will be
implemented in a future commit.
CMake already distributes FindSDL*.cmake files for SDL and SDL_mixer,
which support custom prefixes via environment variables, removing the
need for ad-hoc logic in Win9x builds.
Also, according to FindSDL.cmake, #include <SDL.h> is the preferred way
for portability reasons, instead of #include <SDL/SDL.h>, which is the
option that has been used so far.
Surprisingly, as of today (July 2022) CMake ships with FindSDL*.cmake
files for several SDL libraries such as SDL_mixer or SDL_image, but not
for SDL_gfx, so one was created, based on FindSDL_mixer.cmake.
Reference:
8a3004d5c2/Modules/FindSDL_mixer.cmake
So far, their position inside the container was determined when
initializing the interface. However, if a child were resized
afterwards, the container would not adjust its elements accordingly.
Moreover, the implementation for gui_container relied on hacking the
children's X/Y coordinates, which could only be done once.
Now, two additional members have been added to gui_common so that
specific X/Y offset can be determined by the parent, additionally to the
traditional rules followed by gui_coords. Despite the extra memory
footprint, it now allows containers to set specific X/Y offsets for
their children on every game cycle.
There is no need to allocate memory for these callbacks for each single
GUI element. Instead, a single, statically-allocated instance can be
shared among all GUI elements of a given type.
The older logic would iterate for all parents, where each parent would
again iterate for all of its parents, until no more parents found.
This is however not needed, since only inspecting the closest parent
will already cause the (recursive) algorithm to iterate for all parents.
