Should SDL start with text input enabled?

[slouken]

I've gone back and forth on this.

Users expect their keyboards to input text into applications, but starting with text input enabled means that IMEs can potentially be showing and users get unexpected behavior like #9268

We have the opportunity with SDL 3.0 to document and change the default behavior so applications have to explicitly say when they want text input.

Do people think this is a good idea? @libsdl-org/a-team?

[slouken]

@cgutman, thoughts?

[cgutman]

I lean toward disabled by default.

• It avoids surprises like Holding down keyboard keys on MacOS brings up special character menu #9268 on platforms where the IME decides to jump in an inopportune times
• When using SDL_SetTextInputRect(), the docs advise to set the text input rectangle before calling SDL_StartTextInput(), so having it enabled by default without a defined text input rectangle seems odd.
• It allows for a nice clean state machine for input in applications - you call SDL_SetTextInputRect() and SDL_StartTextInput() when you want the user to type something, the on-screen keyboard pops up, you receive the text input events, then you SDL_StopTextInput() when you're finished. No need to worry about whether SDL already enabled text input behind your back.
• It's apparently so unintuitive even our own text input tutorial calls SDL_StartTextInput() as the first thing it does.

[flibitijibibo]

I'm also on Team Disabled By Default - had I not just assumed that StartTextInput was always required it would have given us a lot of long-term portability problems on mobile and console; better to make the behavior consistent so games don't have to port from SDL to SDL when moving away from PC.

[AntTheAlchemist]

I vote for disabled across all platforms. I've always had issue with the current behaviour which I didn't expect and seems more like a bug #4491. I always SDL_StopTextInput(); at the start of all my apps and games.

[slouken]

Okay, here's my proposal for SDL 3.0:

• Text input events are always enabled and are not related to IME input state or on-screen keyboard
• We add SDL_HasKeyboard() and SDL_HasMouse() (this could be a precursor to multi-mouse/keyboard, but for now will be used for the next steps)
• SDL_StartTextInput() will take a window and a rect as a parameter to enable input for a particular window. By default this will show the on-screen keyboard if that's available and there are no keyboards attached. SDL_HINT_ENABLE_SCREEN_KEYBOARD can be set to "1", "0", or "auto", to force or use the default behavior here.
• SDL_StopTextInput() will take a window as a parameter and will undo screen keyboard changes, respecting the hint as above.
• SDL_VideoInit() will no longer start text input
• sdl2-compat will start text input using the same logic and hint setting that SDL2 currently does.

Thoughts? @icculus sanity check?

[slouken]

Assuming people like this proposal, I'm adding it for the SDL 3.0 prerelease, as it's a pretty dramatic behavior change. Feel free to pick it up if you'd like to work on this.

[slime73]

• Text input events are always enabled and are not related to IME input state or on-screen keyboard

If I'm understanding that approach correctly, is it in conflict with #9268 ? I haven't looked too closely at the specifics but it seems like the macOS text input event code is incidentally making some IME UI show up, so the way that text input events are generated on macOS would need to change (if possible) in order for a goal of having them independent from IME UI to be achieved, right?