Wii U: Add support for swkbd.

[dkosmari]

Description

This adds support for the built-in software keyboard API.

By default, the application will get a working swkbd when calling SDL_StartTextInput(), with reasonable defaults.

Platform-specific functions were added to SDL_system.h:

• SDL_WiiUSetSWKBDEnabled(): allow the application to disable the swkbd. This can be called before initializing the video driver, which changes SDL's behavior (it will call SDL_StartTextInput() during driver initialization, so the application ALWAYS receives text input events from the USB keyboard.) It can be called at any point later too, to disable or re-enable the swkbd. Disabling it will free up all memory allocated by the swkbd backend.

• SDL_WiiUSetSWKBDCreateArg() and SDL_WiiUSetSWKBDAppearArg() allow the application to directly control the CreateArg and AppearArg arguments to customize the swkbd. When either is set to NULL, SDL will use its own internal CreateArg and AppearArg objects, providing the customization functions below.

• SDL_WiiUSetSWKBDLocale(): allows the application to override the swkbd region/language. By default, the system region/language (from the system settings) will be used. The argument is a unix-style locale string ("en", "en_US", "ja", "en_GB", "ja_JP" etc).

Customization functions:

• SDL_WiiUSetSWKBDHighlightInitialText()
• SDL_WiiUSetSWKBDHintText()
• SDL_WiiUSetSWKBDInitialText()
• SDL_WiiUSetSWKBDKeyboardMode()
• SDL_WiiUSetSWKBDOKLabel()
• SDL_WiiUSetSWKBDPasswordMode()
• SDL_WiiUSetSWKBDShowCopyPasteButtons()
• SDL_WiiUSetSWKBDShowWordSuggestions()

These set the various fields of the internal AppearArg object. They're reset to their default values (documented in SDL_system.h) after the swkbd is shown.

I'm open to suggestions, about changing this behavior, so all customization persists between keyboard appearances.

Manual input:

• SDL_WiiUSetSWKBDVPAD()
• SDL_WiiUSetSWKBDKPAD()

This is necessary when the application is not using the SDL joystick/gamecontroller subsystem, and calling VPADRead() or KPADRead() directly.

New events

There are optional SDL_SYSWMEVENT messages generated by the swkbd when it closes. The event.syswm.msg->wiiu.event field will be one of:

• SDL_WIIU_SYSWM_SWKBD_OK_START_EVENT: sent when the "OK" button is pressed, before any text input event.
• SDL_WIIU_SYSWM_SWKBD_OK_FINISH_EVENT: sent after all text input events (corresponding to the swkbd's text) are sent.
• SDL_WIIU_SYSWM_SWKBD_CANCEL_EVENT: sent when the "Cancel" button is pressed.

To receive any SDL_SYSWMEVENT the application needs to call:

SDL_EventState(SDL_SYSWMEVENT, SDL_ENABLE);

Justification: we cannot distinguish whether the text input event is coming from a hardware keyboard or the software keyboard. In a typical UI, hwkbd input will be inserted/deleted/replaced using a "current cursor position." But the swkbd has its own input form, with its own cursor and text selection handling; it produces the final string the UI text input widget should contain.

That means a text input event should either:

• hwkbd: insert the new text input event at the UI cursor position.
• swkbd: clear the text in the UI, and start appending all text input events.

I do not know how to distinguish between both cases, on the application/UI code, other than making wild assumptions about the timing of the events. This more of a SDL design limitation, because the drag/drop events do have a begin/complete delimiters, to help combining multiple related events.

Limitations

This makes SDL depend on libstdc++, since the nn::swkbd is a C++-only API. This dependency can be dropped when WUT gets a C API for nn::swkbd.
It no longer depends on libstdc++, as of 64ad1d7.

[dkosmari]

Here's a sample program using this PR: https://github.com/dkosmari/devkitpro-autoconf/tree/main/examples/wiiu/sdl2-swkbd

Here's an imgui fork using this PR: https://github.com/dkosmari/imgui

• The relevant code is in backends/imgui_impl_sdl2.cpp

[dkosmari]

Now it no longer depends on libstdc++.