scp-fs2open
fix popups with inputboxes cancelling text input
Text input is enabled when an inputbox is created and disabled when it's destroyed. If a screen has an inputbox and can trigger a popup that also has an inputbox, then text input is disabled when the popup is closed thereby preventing the original screen's inputbox from working.
Setting as draft since, although it addresses a particular problem found on the PXO screens, it doesn't really fix the underlying issue. So this PR may be scrapped in favor of a better solution.
Technically SDL_StartTextInput() should only be called when a user is required to enter text, as it can open an onscreen keyboard, so calling it when an input box is created is wrong. This PR toggles text input when an input box's focus is gained/lost. But it's unclear how well the existing retail ui code handles focus states so this may not be a complete solution.
A bigger issue is that SDL_StartTextInput()/SDL_StopTextInput() is called in individual situations rather than as a global setting. So text input can be stopped even when it's still needed and requires exiting and returning to a screen to re-enable input. Text input is started on creation of each input box ui element and stopped on deletion of each of those elements. It is also started/stopped when the debug console is used. And the newer rocket ui code will also toggle text input. These instances conflict with each other.
I think that, at a minimum, handling SDL_StartTextInput()/SDL_StopTextInput() in a global way is needed so that the number of starts must be matched by the number of stops. Going through to the retail ui code to confirm how well focus states are handled may also be a good idea.
Tagging @z64555 for his input on this.
The SDL wiki is a little thin on the usage of SDL_StartTextInput and SDL_StopTextInput, and judging by the behavior reported we'll need to make a mutex or counter to regulate when these two routines are actually called.
According to the SDL wiki, the two functions enable/disable certain events from generating, and again the reported behavior would suggest that they are managed in a simplistic way. We may be able to make a case with the SDL dev's or at least check their issue tracker to see if others have come into a similar issue.
