Text input rework

Unfortunately, we can’t just ask OS to give us a character alongside with a key press event. Most complex text input systems compose characters from multiple key presses and we shouldn’t try to interpret these key presses at all, because they are not intended by the user to be interpreted in application-specific way. So we need a way to indicate if a control expects text input at all or wants just raw key events. Our iOS/Android backends do that by checking if focused control is a TextBox.

Another problem is “preedit” or “marked” text. GTK app with preedit: Winforms app without preedit

See this video: https://vimeo.com/211472594

As you can see, input method interacts with text input area to display incomplete text sequences. This is done with XIM callbacks and NSTextInputClient (we partially implement NSTextInputClient to get text input at all).

That’s quite a lot of methods and it’s not quite possible to properly express them using routed events. Avalonia is built on the routed event model, so I propose to determine input handler (if any) by sending GetTextInputHandlerEventArgs and expect TextInputHandler property to be set if someone wants text input. Then everything text-related will be passed directly to said handler.

For now it will contain only one method, so we could solve at least the first problem and lay the foundation for text input system interaction

Old OnTextInput will be removed.

@AvaloniaUI/core

[kekekeks]

We could use some kind of a “virtual” text store that only contains preedit sequence (manipulated by XIM, TSF and Cocoa) and current cursor position (manipulated by our textbox). That will keep our public API more stable since the API surface will be smaller.

[robloo]

[RDY] win32 ime #6223