When a GUI element is hidden, no rendering or updating is done to it or
its children. This can be useful to define a complex GUI tree structure
that changes under specific conditions, without redefining it.
The older implementation caused some elements to be
update/rendered/deinitialized more than once per call. For example,
considering the following tree of GUI elements:
A
B
C
D
E
The older implementation would update/render/deinitialize C and E more
than once, as shown below:
Update A
Update B
Update C
Update D
Update E
Update C
This was because a GUI element was acting on its siblings, but the
siblings would also act on theirs, causing the extra calls.
OTOH, as an additional improvement, no nested call is now required for
siblings.
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.
