Fix the initial candidate window position

[rhysd]

Fixes #2792. Closes #2800.

The issue is that the candidate window is already open when InputMethod::Open event is handled in the window manager. Since set_ime_cursor_area is not called yet when the window is opened, the position of the window is at the top left corner.

To fix this, we need to call set_ime_cursor_area earlier before the window is opened. winit's example calls the function just after calling set_ime_allowed.

This PR calls the function when allowing IME so InputMethod::Allowed event now has the position of the window.

Here is the video:

fix.mp4

[kenz-gelsoft]

I think this is sane fix for the problem I catched earlier on original PR:

#2777 (comment)

I investigated winit's macOS platform code and I find it correctly updates the internal ime_position queried from the OS and invalidates it when we call winit::Window::set_ime_cursor_area().

And as far as I tested macOS iuput methods doesn't reposition immediately while it is currently displayed. This is not only on winit apps but also on native macOS apps.

So this is not a bug of winit but is a cross platform limitation. We need to set_ime_cursor_area() before the subsequent Preedit event I guess.

Sorry about the misinformation on the decision of the initial API design.

[kenz-gelsoft]

How about merging Allowed and Open state like this?

EDIT: Sorry this is bad. This can't express the Open state with on-the-spot preedit.

kenz-gelsoft@3cfe5eb

[rhysd]

That sounds also work and simpler. Basically agree. One downside on it is that window.set_ime_allowed is called every time when the preedit content and cursor rendering is updated. I don't know how window.set_ime_allowed is implemented in winit (probably it calls the low-level platform-specific APIs directly), but the usage would be fairly irregular.

[rhysd]

But I have an idea for avoiding the downside.

So I'd like to suggest to make a PR with the commit by @kenz-gelsoft and then I will send a PR to your fork.

[kenz-gelsoft]

@hecrj Sorry for disturbing, I proposed merging Allowed and Open states in this PR, but it was not simple to handle in this PR.

I think this PR should be included in the first release (0.14 I expects) which supports input method.

Please review this as-is.

[hecrj]

I have simplified the InputMethod API to have only 2 states: Disabled and Enabled.

Could you test and make sure everything works as expected?

[rhysd]

@hecrj Thank you for reworking my patch. As far as I tried, it worked fine. (Checked only TextInput for my usage)