Added Alt and CapsLock key states to key events.

[loosewheel]

Alt and CapsLock key states added in preparation for key, mouse and touch events to on_receive_fields callback in Minetest engine.

Notes: Could only test Linux X platform.

The following is not directly related to this addition but can affect the events.

All platforms map to key codes in Keycodes.h, which appears to be a reiteration of virtual keys from win 32 SDK.

The Android code maps a lot of keys to KEY_UNKNOWN but some of them may have a relevant key in win 32.

I couldn't see any key event code in ios code. I've never used this platform but does it implement an on screen keyboard?

The frame buffer platform does not appear to be correct. I couldn't see any mouse events. I just added a couple of extra case clauses consistent with what is there, but the key events don't look as though they would operate correctly. The event struct is allocated on the stack at every event but not initialized. Only some fields are set, and the rest contain junk (what ever was on the stack). The Shift and Control fields (which I extended with Alt and CapsLock) are set to true when an event is trapped for these keys, whether pressed or released. And not set for any other keys. The event data from the system doesn't contain a character field, and is never set or cleared.

These events are already consumed by various IGUIElements. If there are any deficits they are already present in the engine.

[sfan5]

I can understand Alt but what would the CapsLock state be useful for?

I couldn't see any key event code in ios code.

The code is unused but not like key events will really be useful on mobile platforms anyway (even if the user can in theory open an on-screen kbd).

The frame buffer platform does not appear to be correct.

It probably doesn't even work and won't work in the future either. No need to make any changes there.

[loosewheel]

I can understand Alt but what would the CapsLock state be useful for?

This is only an added feature, so it can be implemented in mods any number of ways. For simple input the Char field should be reliable, but does't have to be used for that purpose. Because this is a game engine its not likely these events would be used as in coding an application. A mod may require consistent input per key across hardware/languages, or even implement fantasy input. In these cases the Char field isn't useful, and the CapsLock state is essential for determining the context of the key stroke. The number lock state also has some relevance here but I couldn't find docs for it across all platforms (obviously not all keyboards have a number lock key).