text_input documentation improvements on by default, needed for pygame.TEXTINPUT #2333
Conversation
|
This is probably related to key.unicode emulation, and how we document this depends on whether we want to tell users that going forward, you shouldn't use key.unicode and use TEXTINPUT events instead, or whether we want to support not only key.unicode into all eternity, but also the mixing of If you don't run your games on an Android tablet or a Touchscreen PC with an on-screen keyboard (recent Ubuntu versions work really well in this configuration), you don't need to care about this, but I do so I do. So I'd propose documenting the current behaviour, and probably also turning off key.unicode emulation once I realise the documentation part is a no-brainer, and the stopping emulation part is highly contentious. But once you use pygame.key.stop_text_input(), you are using a new pygame 2.0 API, and you explicitly demarcate text input (as opposed to keyboard controls), so you don't need TEXTINPUT events outside of the demarcated sections, and you don't key.unicode emulation. |
|
I realise I didn't explicitly comment on this pull request: In its current form, I don't think this enough. We should document what pygame.key.start_text_input() and pygame.key.stop_text_input() actually do on desktop environments like windows, GNOME, android, and mac os, and what kind of behaviour you can expect with different languages (human languages, not programming languages). There are two parts to this:
We probably also need some example code and a screenshot of how both this works, and expose all of the necessary functionality properly. I know PyGame currently does the on-screen keyboard part properly (so this should be mentioned in the docs), but may be struggling with the IME part, but in this case we should aim to fix IME instead and mention that IME might currently be broken, not remove all mentions of IME from the docs. |
|
I must say I'm a bit confused that the pr was merged, because after reading your comment I agree that some information could be added... oh well 🤔
That was not my intention... I mainly wanted to remove the part that said that the normal pygame.TEXTINPUT events were not dependent on But you're right that a lot more information could be added. I can't, unfortunately, test much of the IME stuff for now (I'm using a mac and it's not working... #2328 ) edit: Maybe the accent menu and IME stuff are separate things? I don't much about all this, I should test it more... |
While trying the new
pygame.TEXTINPUTevents, I found some things in the docs that I thought could be improved...The pygame docs says that "normal" pygame.TEXTINPUT events are not dependent on
start_text_input()andstop_text_input(), but they are according to the SDL docs.https://wiki.libsdl.org/SDL_StartTextInput
Testing shows that normal pygame.TEXTINPUT events will stop when pygame.key.stop_text_input() is called, but the whole SDL TextInput thing is on by default, so there is no need to call start_text_input() for them to work.
Everything also works in the textinput.py example file when pygame.key.start_text_input() is removed.
But I don't understand much about the advanced
TEXTEDITING/ IME stuff... perhaps there's something I missed.Thanks 😄