Hi,
I would like to start a discussion about a possible extension to the SDL
API to better support mobile applications or alternative non-PC platforms.
Right now the iOS port has some private functions which however don’t
make much sense and is missing some important other ones.
Keyboard--------
bool SDL_SupportsVirtualKeyboard(void)
Does this platform support virtual keyboards?
void SDL_SetVirtualKeyboard(SDL_VirtualKeyboardType type)
Shows or hides a virtual keyboard on platforms that support one.
The following keyboard types are supported:
SDL_NO_VKEYBOARD
SDL_TEXT_VKEYBOARD
SDL_PASSWORD_VKEYBOARD
SDL_NUMBER_VKEYBOARD
SDL_EMAIL_VKEYBOARD
SDL_URL_VKEYBOARD
Unsupported keyboard types shall map to a text keyboard. The
special NO_VKEYBOARD type hides the keyboard.
SDL_VirtualKeyboardType SDL_GetVirtualKeyboard(void)
Returns the current virtual keyboard.
SDL_VirtualKeyboardPrompt *SDL_BeginVirtualKeyboardPrompt(
const char *title, const char *text,
SDL_VirtualKeyboardType type)
Prompts the user for a text and returns it as newly allocated
memory. If the virtual keyboard is set to a password
keyboard, the platform’s password input shall be used. The keyboard
type must not be SDL_NO_VKEYBOARD and no validation is performed.
On iOS this would look like a typical notification/input dialog
on top of the application. This has the advantage that the user
can use copy/paste within this dialog and can use the platform's
text selection tools. Especially for small games this would be
easier to use than handling keyboard input for oneself. This might
even work on platforms like the xbox 360 if someone wants to port
it there, where the keyboard comes with it's own input field.
SDL_EndVirtualKeyboardPrompt(SDL_VirtualKeyboardPrompt *)
Frees the memory for the prompt and closes it if the platform
allows closing of the prompt from the loop behind.
struct SDL_VirtualKeyboardPrompt {
char text; / the text entered if entered, NULL
otherwise. Memory valid until prompt
is ended. /
int closed; / 1 if the input was closed, 0 else /
int canceled; / 1 if the user canceled the input */
};
For the virtual keyboard the mainloop will need another event:
SDL_VKEYBOARD_DISMISSED. The event structure:
struct SDL_VirtualKeyboardEvent {
Uint32 type;
Uint32 windowID;
VirtualKeyboardPrompt prompt; / if a prompt was associated
with this keyboard /
int canceled; / if the user canceled the
keyboard instead of hitting
accept on keyboards that
support this */
};
Memory Management / Multitasking
On mobile platforms with multitasking SDL will have to be extended to
support proper resuming and responding to low memory warnings:
SDL_AddLowMemoryCallback(…)
Adds a function to the list of functions that are called when the
operating system notifies the application that memory is running
short. This is especially helpful on iOS where this can be used
to clean up unused caches.
On platforms without such functionality this just does nothing.
SDL_AddApplicationHoldCallback(…)
Registers a function that is called if the operating system forces
the application into the background. These functions should stop
execution after a few cycles otherwise a mobile platform might
kill away the app. This is the perfect place to save the state
to disk in case it is killed.
On desktop platforms this would just do nothing at all.
SDL_AddApplicationResumeCallback(…)
Registers a function that is called when the application resumes
execution from the background on a mobile device. This is less
useful than the hold one, but might still be nice to have.
For all these functions we should also have functions that allow a user
to iterate over the list of functions currently registered and to remove
them. If this API is too complex, we should just have one function
registered there. The lists would just be helpful if multiple separate
components want to respond to these events.
What’s your opinion on that? Right now SDL is in desperate need to at
least some of these as right now SDL is pretty much broken on iOS in
regard to multitasking and it would be nice to have an API that just
falls back nicely for desktop environments or platforms without these
things. Also a prompt based keyboard system would be much nicer for the
common use case than just showing and hiding it.
Regards,
Armin