OGC: virtual keyboard support

[mardy]

The WIi and GameCube port of SDL 2 does not offer a virtual keyboard.

I'm opening this issue to propose a solution and reach at least some vague consensus before rushing to implementing something that might not get accepted.

In bullet points:

• The Wii/GameCube do not offer a virtual keyboard, each game/application needs to implement its own
• SDL has an API to handle virtual keyboards
• SDL has an internal API for backends to implement/invoke a virtual keyboard
• Writing a generic VK is not trivial:
  • How many keymaps/languages do we want to support?
  • Games probably want it to be themable
  • It will inevitably eat up some resources (RAM, disk) just for the code, let alone for fonts, graphics, sounds
• Not all applications need a VK, it would be nice not to waste resources for the VK in their case

In light of the above, I would suggest this solution:

1. We define a public structure which contains the method callbacks that a VK module needs to implement (very similar to the internal SDL API, linked above, but not necessarily identical); let's call it OgcVkFunctions for the time being.
2. We augment the SDL module with an OGC-specific API which allows the application to register its own VK implementation. Something like:

   /* Registers a virtual keyboard implementation, described by the vk_functions structure.
    * Return the previously registered module, if any (this can be used to chain up to the
    * previous implementation) */
   const OgcVkFunctions *OGC_SDL_RegisterVKModule(const OgcVkFunctions *vk_functions);

3. In the SDL OGC video module, we implement the SDL VK internal APIs by simply checking if the application registered a VK backend: if it does, we call the corresponding function. Something like:

   static OgcVkFunctions *ogc_vk_functions = NULL;
   
   /* This is the OGC implementation of StartTextInput */
   void OGC_StartTextInput(_THIS)
   {
       SDL_VideoData *videodata = (SDL_VideoData *)_this->driverdata;
   
       if (!ogc_vk_functions) return;
       ogc_vk_functions->start_text_input(videodata->current_window,
                                          videodata->input_rect);
   }

4. We create a separate project, OGC_SDL_keyboard, where we develop a (simple?) keyboard shipped as a static library. The static library will export a function const OgcVkFunctions *ogc_sdl_get_vk_functions() that returns a pointer to the OgcVkFunctions structure.
5. The application can then enable the virtual keyboard by linking to the OGC_SDL_keyboard library and calling

   OGC_SDL_RegisterVKModule(ogc_sdl_get_vk_functions());

   somewhere in its initialization code (or even later).

This solution has the benefit that applications who don't need a virtual keyboard will basically not have to pay for it, in term of resources. Applications who just need a basic keyboard can have it by just adding a line of code (which can easily be #ifdef'd out when building for other platforms), and applications who need more advanced or customized keyboards can pass their own OgcVkFunctions structure and have full control over the VK keyboard.

[mardy]

I've been quiet on this, because even before starting working on the implemenation, it occurred to me that there are some quite fundamental issues which I hadn't thought about. While the above suggestion would probably work well on the graphics part, the audio and input parts are yet to be solved.

In the above proposal, the VK would work as a plugin of the main application, which would continue iterating its event loop. This means it would also continue to get input events such as from joysticks and mouse, which would either disrupt the VK functionality, or the app's. We need to figure out a way to make it so that while the VK is active, it should get exclusive input access.

The other issue is about sound, should we want the VK to emit sounds when it's operated: if the application has an audio stream open, we cannot just dump our audio data into it (assuming that it's even possible). Since libaesnd (used by our SDL backend) supports up to 32 sound stream, we should probably use another one, and then the problem arises, on whether we should use the libaesnd API directly, or somehow use the SDL API again (we could expose more sound channels as additional devices, and have the VK use the first available one). It would be nicer if we used the SDL API, because then our VK could be made usable in other applications, not specific to the Wii.

I'm still studying how to overcome these issues.