[Uim] Focus and cursor position shift handlings (bug #7729)

[Etsushi Kato]

Hi YamaKen,

On 10/15/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> These 4 handlers in addition to preexisting 'reset' handler will
> be added if there are no problems. Please review the concept,
> interface, namings and usage of it. Jae-hyeon, please confirm
> the scenario #3 and #4 with your requirements.
>
> I'll commit actual interface codes to trunk once it is reviewed.
>
>
> - (reset)
>
>   Reset the context to neutral state. Internal state that
>   considered as 'global' may be kept. This handler MUST NOT
>   commit a string and/or update the preedit.  If a preedit
>   string is existing on a GUI toolkit-level reset, the bridge is
>   responsible to clear it.

Fine.

> - (focus-out)
> - (focus-in)
>
>   Notify the context that the textarea is being focused
>   out/in. This handler may commit a string and/or update the
>   preedit.

Fine.

> - (displace textarea-local?)
>
>   Notify the context that the input at current input point
>   (textarea and/or cursor position) has been discontinued. This
>   handler may commit a string, but must not update/clear the
>   preedit. Bridge-level preedit must be cleared by bridge itself
>   (uim-level preedit may be preserved for subsequent 'place'
>   handler call).
>
> - (place textarea-local?)
>
>   Notify the context that the input point (textarea and/or
>   cursor position) has been relocated. This handler may commit a
>   string and/or update the preedit.

I can understand the situation needed to commit characters with
displace handler, but not for place handler.  Actually I don't
understand Scenario #6 below well.

> Scenario #1: Clear all web forms by 'clear' button
>   1) Input a Japanese sentence in hiragana to a web form and
>      hold it in the preedit
>   2) Click 'clear' button
>   3) The GUI tookit clear the text of the form
>   4) The GUI tookit reset the input context of the form
>   5) The uim bridge clear toolkit-level preedit
>   6) The uim bridge call uim_reset_context()
>   7) reset-handler has been called
>   8) The context clear uim-level preedit and transit all input
>      states to neutral

OK.

> Scenario #2: Reset a partial input sequence of a Latin IM
>   1) Input a dead key
>   2) Click another window
>   3) focus-out handler has been called
>   4) The IM reset the character composition sequence (dead key 1))
>   5) When the focus is backed to the original textarea, the user
>      can input any character from beginning of its input
>      sequence. This behavior is important to avoid user confusion

Yes. This functionality is definitely needed for such IM.

> Scenario #3: Commit precomposed Hangul character of a 2 beol-sik IM (1)
>   1) Input some hangul jamos and compose a character in the preedit
>   2) Click another window
>   3) focus-out handler has been called
>   4) The IM commit the character and clear preedit
>
> Scenario #4: Commit precomposed Hangul character of a 2 beol-sik IM (2)
>   1) Input some hangul jamos and compose a character in the preedit
>   2) Click another position of the same textarea
>   3) 'displace' handler has been called
>   4) The IM commit the character and clear preedit
>   5) 'place' handler has been called
>   6) ignore 5)

Fine.

> Scenario #5: Preedit relocation (direct relocation to another textarea)
>   1) Input a Japanese sentence in hiragana into a Japanese
>      multi-segment IM
>   2) Click another textarea which shares input context with the
>      textarea 1)
>   3) 'displace' handler has been called at textarea 1)
>   4) The context clear the bridge-level preedit of 1) by
>      im-clear-preedit
>   5) focus-out handler has been called at 1) and ignored
>   6) focus-in handler has been called at 2) and ignored
>   7) 'place' handler has been called at textarea 2)
>   8) The context update the preedit of 2) by the preserved
>      uim-level preedit

OK.  But how can we determine the contexts are relocatable one?  Do we
need to get the information of continuous sequence about 'displace'
and 'focus-out'?

> Scenario #6: Preedit relocation (deferred relocation)
>   1) Input a Japanese sentence in hiragana into a Japanese
>      multi-segment IM
>   2) Click another window
>   3) focus-out handler has been called at 1) and ignored
>   4) Click another textarea which shares input context with the
>      textarea 1)
>   5) 'displace' handler has been called at textarea 1) by using
>      preserved the internal variable last_text_widget of the GUI
>      toolkit
>   6) The context clear the bridge-level preedit of 1) by
>      im-clear-preedit
>   7) focus-in handler has been called at 4) and ignored
>   8) 'place' handler has been called at textarea 4)
>   9) The context update the preedit of 4) by the preserved
>      uim-level preedit

As noted above, I can't imagine this situation.  Is it the 'safety' behavior
what you described in 'Preedit Relocation' section of qinputcontext.cpp?

Cheers,
-- 
Etsushi Kato
ek.kato at gmail.com