| Summary: | cannot input Japanese on Android because the inputtype is password | ||
|---|---|---|---|
| Product: | SDL | Reporter: | tamo <ttakah+sdl> |
| Component: | *don't know* | Assignee: | Sylvain <sylvain.becker> |
| Status: | ASSIGNED --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | minor | ||
| Priority: | P2 | CC: | sylvain.becker |
| Version: | HG 2.0 | ||
| Hardware: | ARM | ||
| OS: | Android (All) | ||
| Attachments: | s/VISIBLE_PASSWORD/NORMAL/ | ||
|
Description
tamo
2019-08-29 08:48:23 UTC
Created attachment 3935 [details]
s/VISIBLE_PASSWORD/NORMAL/
For the record, this was added here: "We found an issue where certain Android keyboards (like the S6 with predictive text) wouldn't work ... Certain keyboards use a predictive text mode that does not dispatch a traditional onKey events, which is troublesome ... but telling the OS to use a "visible password" keyboard helps deal with this problem ... perhaps there's some other way (onKeyPreIme?) to do "textediting" events, but for now, this should be a fast fix ... I hear it affects the Galaxy Tab A 8.0", Galaxy S6, Asus ZenPhone 2, maybe others" https://hg.libsdl.org/SDL/rev/b98c133b5cfd https://developer.android.com/reference/android/text/InputType.html#TYPE_NUMBER_VARIATION_NORMAL TYPE_NUMBER_VARIATION_NORMAL is 0x00000000 TYPE_NUMBER_VARIATION_PASSWORD is 0x00000010 Thanks, Sylvain. Your information is definitely what I've wanted! (I'm afraid hg annotate doesn't tell me the history of android-project.) Then, if you just want to suppress "suggestions" (I don't know when onKey events are emitted and when not), what about FLAG_NO_SUGGESTIONS? https://developer.android.com/reference/android/text/InputType.html#TYPE_TEXT_FLAG_NO_SUGGESTIONS I'd like to stress that the current implementation makes SDL's great TextInput workframe nearly useless for Asian users. Your patch sounds totally correct. But I can't reproduce previous bug (my keyboard hides the suggestions when It appears in SDL). Maybe we should get the original poster in to see if that doesn't conflict. But he (Joshua Granick, aka singmajesty) and his Open FL no longer uses SDL, does he? https://github.com/openfl/openfl/search?q=SDL&unscoped_q=SDL I'd like to take a closer look at android-project code someday, but I'm afraid it's not today. Maybe just dispatching onKey on text event would work? I reached out to Joshua but having heard yet. I'm not against just applying this patch though, fwiw. --ryan. (In reply to Ryan C. Gordon from comment #6) > I'm not against just applying this patch though, fwiw. Go ahead, please. ;) I found an official guide (https://developer.android.com/training/keyboard-input/commands.html ) which reads: "You should never rely on receiving key events for any key on a soft input method (an on-screen keyboard)." It makes sense, I think -- because a key basically represents one single character, like a single-quoted char in C, while a soft input can represent a longer string, like a double-quoted string in C. They are fundamentally different things, even if the results are the same, e.g. 'S' and "S". So we should not expect that we can handle every input via onKey events. There are many kinds of input, so we have to take care of many kinds of events. Restricting the input type is not the way to go. I've added it in https://hg.libsdl.org/SDL/rev/6f0ec1079286 This patch broke all individual key events for the soft keyboard, so I'm reverting it and reopening this bug for investigation of a better solution. https://hg.libsdl.org/SDL/rev/d642e14375b6 Maybe we can re-enable the patch and find another way to handle the pre-IME text that provides key events for ASCII non-composed characters? Sylvain, can you investigate? Yes I can try, but please provide more information about "pre-IME text that provides key events for ASCII non-composed characters". What keyboard ? device ? text ? SDL functions ? you use, and what do you observe good/wrong ? |