TextArea: on Ime::Disabled use finish_compose() instead of clear_compose()

[0x241F31]

I'm implementing Android IME integration with masonry using InputConnection

I noticed TextInput removes entered text on focus loss by sending Ime::Disabled from here:
https://github.com/linebender/xilem/blob/main/masonry_core/src/passes/update.rs#L617
and then calling clear_compose() within TextArea handler.

I feel this event should be sent from IME itself.
Additionally, common UI pattern is to keep entered text inside an input field on focus loss.

As I don't see convenient way to override such behavior from outside of masonry, my proposal is to use finish_compose() until there's more idiomatic solution.

[xStrom]

@DJMcNab @xorgy does this look like a reasonable change?

[DJMcNab]

I selected this behaviour based on the way the IME acted on GNOME; when I changed between windows, the current IME selection followed my cursor. So if we used the behaviour you are proposing, on systems where the IME behaved like that, moving repeatedly between windows would repeat the IME content several times. Now, that might have been a bug in mutter rather than an intentional choice (although I've found that it can be hard to tell the difference with GNOME).

Perhaps I'm misunderstanding when the Ime::Disabled event is sent though, and this is talking about a different case. This is all paged out at the moment.
It would be nice if the IME sent us either a final commit or cancel, but that is too much to hope for!

I'd maybe like to get some clarification from a Winit maintainer about how they expect this case to work.
That being said, I'm happy for this to land speculatively to unblock you, although I'll delegate to @xStrom to actually press the button.

[0x241F31]

Nah I'm not blocked, if you're comfortable with holding this PR I'm fine.

[xStrom]

I'm not familiar with this to know what's best, so I guess we can leave it as waiting for now. If someone thinks we should move forward with it, make sure to post here.

[xorgy]

At first blush this doesn't make sense to me. Usually cancellation of the IME isn't meant to cause the preedit text to be committed, as far as I'm aware (especially if the preedit is incomplete, like pinyin or incomplete hangeul). Some systems retain the preedit state and make it follow the focus (so that you pick up where you left off, in the new target), but I'm not sure that's standard either.

[0x241F31]

At first blush this doesn't make sense to me. Usually cancellation of the IME isn't meant to cause the preedit text to be committed, as far as I'm aware (especially if the preedit is incomplete, like pinyin or incomplete hangeul). Some systems retain the preedit state and make it follow the focus (so that you pick up where you left off, in the new target), but I'm not sure that's standard either.

Right now, when TextArea loses focus, entered text is simply removed. This behavior doesn't align with mobile and desktop UX.

[xorgy]

Right now, when TextArea loses focus, entered text is simply removed. This behavior doesn't align with mobile and desktop UX.

I'm curious what you're looking at in terms of desktop UX around this, because when I cancel/dismiss my IME (mozc, rime-bopomofo, rime-lunapinyin) on X11+Fcitx5 on any toolkit on my machine, it clears the preedit text rather than committing it. I don't clearly remember what the norm is on macOS or Windows, but would have suspected it was similar, but I'm happy to be corrected on that. I do notice that preedit text ends up committed on loss of focus, but that's separate from general Ime::Disabled (which is triggered differently, in particular on winit on two platforms at least it is triggered after every commit, as well as when the input method is cancelled/dismissed manually).
On InputConnection I suppose the behavior is different, because there is a distinction between the composition region and mere preedit text (the latter is often displayed separately, inside the OSK UI). For Google Keyboard Japanese, dismissing the OSK causes the composed text to be committed in standard Android views; Google Keyboard 注音符號 IM displays preedit hints over the OSK rather than in a composing region, and just commits completed conversions. I'll have to check what the hardware keyboard IME behavior is on Android, it may differ as well.

This might be a separate issue where Ime::Disabled is the wrong thing to trigger on loss of focus, and we may need an additional variant (or have widgets handle loss of focus directly, and don't fire Ime::Disabled on loss of focus).