search

kettle11 / kapp

A pure Rust window and input library for Windows, Mac, and Web. (Work in progress)
Apache License 2.0
56 stars 4 forks source link

Proper IME (Input method editor) support #64

Open kettle11 opened 3 years ago

kettle11 commented 3 years ago

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 commented 3 years ago

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

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

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 😢