Pull text from game text input

[Zoxc]

This is an alternative to https://github.com/rib/android-activity/pull/19 which does work with unicode characters.

There's still some race conditions to fix here though.

[rib]

I think when it comes to GameTextInput we should be aiming to expose a rust API that covers the full capabilities, so that it's possible to support standard IME application protocols based on a preedit string. I think this means we should have an event that effectively forwards everything in GameTextInputState, without the tricks to synthesize character events from that.

It's quite standard for IME interfaces to deliver an event with a "compose" region similar to this - I think the main thing that's a little different is that Android tracks a selection region in addition to a compose region.

I don't think there's reliable way to generate character events from this kind of protocol since there may be arbitrary changes in the string and regions between updates.

I would essentially expect that applications make a mutually exclusive choice between key/character-based input and IME input. This is also how the abstraction works in Winit I believe. The two approaches have quite different interfaces and IME input is rather abstracted away from the details of key/characters.

[rib]

I think my preference would be for set_soft_input_visible(&self, visible: bool) (since 'soft input' isn't a property that's inherently boolean on it's own)

though we might need to consider the async nature of this. I've got the impression that this may conceptually be a request on Android, and the Android Java API optionally provides a way to get a notification of completion.

We might want to consider the future possibility that we'll have an event that notifies application of completion, and so then instead of an API that looks like a property getter/setter, maybe it should be more like a request with a verb like show_soft_input(&self).

If we can't create a reliable, symmetric getter for this like pub fn soft_input_visible(&self) -> bool maybe that'll be another indication that we should treat this like a request with a verb based name.

[rib]

looking at the underlying Java API here: https://developer.android.com/reference/android/view/inputmethod/InputMethodManager#showSoftInput(android.view.View,%20int,%20android.os.ResultReceiver) I don't see a way of querying the current visibility, so I suppose I'm more thinking now that we should mirror how it works at the Java level and have an API that is documented to request that a soft-input interface be shown, which I think I'd probably name as show_soft_input(), or request_show_soft_input() consistent with GameTextInput and the Java API.

[rib]

It could be good to better understand the difference between passing the SHOW_IMPLICIT flag or not to the Java API to see if we should also expose a similar option for apps when requesting to show a soft keyboard.

It looks like the other SHOW_FORCED flag is deprecated so I guess we can ignore that one - even though GameTextInput supports it.

[rib]

yeah, looking further, it looks like we should have a corresponding hide_soft_input API like GameTextInput and Java and since the SHOW_FORCE and HIDE_NOT_ALWAYS flags are deprecated I guess we can get away with both requests just having a bool argument for is_implicit or is_user_explicit or something like that so that it's possible for applications to differentiate whether they are requesting to show the soft-keyboard in response to an explicit action from the user vs showing the keyboard because they think that's appropriate.

[Zoxc]

My idea was to have a separate IME mode which is more fully featured, but we could also require downstream IME support to get the software keyboard to work.

This PR still doesn't work on a real keyboard. Perhaps GameTextInput doesn't support keyboards?

[rib]

My idea was to have a separate IME mode which is more fully featured, but we could also require downstream IME support to get the software keyboard to work.

yeah, Android's soft keyboards are basically exposed via an IME interface so I think it's the most practical way.

Egui for example does already have some basic IME support I think but it probably makes assumptions currently about how IME works on desktop systems.

This PR still doesn't work on a real keyboard. Perhaps GameTextInput doesn't support keyboards?

For physical keyboards that's where I think you want the KeyEvent, interface instead of the IME interface. I'm not sure atm if there's a way to be agnostic of software vs physical keyboards - would have to poke around the Android docs more to check that.

In general though I don't think GameTextInput is geared towards handling physical keyboards (or at least if a physical keyboard is used it would be via an Input Method - similar to a software keyboard).

I would guess Android does have some way of redirecting physical keyboard input via an input method for being able to support classical input method features, like being able to compose Chinese han characters or Japanese hiragana and katakana from multiple key inputs. I'm not currently familiar with how that works on Android though at the moment.

[rib]

Closing this while it's hopefully addressed by #24 and #102