Proper IME (Input method editor) support

[kettle11]

• [x] Windows (Thanks @lunabunn !)
• [ ] Mac
• [ ] Web

kapp's IME support should make it easy to implement correct behavior. Proper IME input is critical for inputting characters in most non-English languages.

Probably events need to be emitted when the intermediate results change and when a final text input occurs.

Previously the CharacterReceived event handled the latter. Instead a TextInput (or a better name?) event with a String should be sent as it's closer to the platform native behavior. Allocating a String shouldn't be a problem for these events as they're relatively infrequent.

[kettle11]

I've noticed a complication with this approach on MacOS.

When holding the 'a' key the following things occur:

• CharacterReceived { character: 'a' } is sent
• A candidate window appears with different accents over 'a'
• If an accent is selected then CharacterReceived { character: 'à' } is sent.

The expected behavior is that the original 'a' will appear immediately but will be replaced by the 'à' when it's selected.

Unfortunately with the events kapp exposes there's no way to do that properly because the original a is not a candidate.

Maybe a more complex set of events will be needed to properly interface with system text input. Perhaps SDL's approach can be a useful inspiration: https://wiki.libsdl.org/Tutorials/TextInput ?

[lunabunn]

IMHO the expected behavior there (as an end user) would be IMEComposition { composition: "a" } IMECompositionEnd CharacterReceived { character: 'à' } but I understand that doesn't align very well with how MacOS handles these events. Would it be practical to synthetically generate these events? SDL also seems to have only 2 events, I don't really see how that model would be beneficial over what we have now (unless I'm missing something).

[lunabunn]

Just for the record, I've also been working on implementing this for Web. Blocked on https://github.com/rustwasm/wasm-bindgen/issues/2489

[lunabunn]

IMHO the expected behavior there (as an end user) would be IMEComposition { composition: "a" } IMECompositionEnd CharacterReceived { character: 'à' } but I understand that doesn't align very well with how MacOS handles these events. Would it be practical to synthetically generate these events? SDL also seems to have only 2 events, I don't really see how that model would be beneficial over what we have now (unless I'm missing something).

Nevermind. This would feel "off" on MacOS because you're not actually composing when you type in English on Mac, therefore the underline is not displayed (in native applications, at least). This would definitely require some different events, unless we decide to do something really stupid like synthesizing a backspace to replace the character 😢