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

[Jae-hyeon Park]

Hello YamaKen,

YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> writes:

> 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.
> 
> - (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.
> 
> - (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.
> 
> 
> 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
> 
> 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
> 
> 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)
> 
> 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
> 
> 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
> 
> 
> Notes:
> 
> 1. In scenario #1, uim context must not commit a string, update
>    or clear the preedit. It may make widget-level consistency
>    broken, and breaks 'reset' semantics.
> 
> 2. Some (or most?) GUI toolkit issues a reset on inappropriate
>    timings such as focus-out. Such tookit assumes that all input
>    context is ephemeral like Latin character composition. But
>    most Japanese IMs are definitely not.
> 
>    To deal against such toolkits, uim IMs may ignore
>    reset-handler as a temporary solution. We should send patches
>    for such toolkits to the toolkit developers to fix the
>    problem.
> 
> 3. See the document of QInputContext to know what is preedit
>    relocation.
> 
>      http://anonsvn.freedesktop.org/svn/immqt/immodule-qt-x11/trunk/src/kernel/qinputcontext.cpp
> 
> 
> 4. Scenario #4 and #5 requires appropriate support of the GUI
>    tookit. But since I am not confident with the 'place' and
>    'displace' API about the note 5. (see below), API revision
>    suggestion for GUI toolkits should be deferred for now.
> 
> 5. Some combined call of the handlers (see below) are needed to
>    reduce text flicker on a focus-sensitive preedit display. But
>    since such IMs are rare and unneeded for now, it is not
>    supported to reduce development cost and keep the API simple.
> 
>    - focus-out and displace
>    - focus-in and displace
>    - focus-in and place

Scenarios #3 and #4 are indeed the behaviors expected of a normal
Hangul input method.  Thank you very much for the detailed
consideration.  I think they are okay from the view point of
implementing Hangul input.  I have a couple of thoughts to add.

(1) Can displace and place handlers be combined?  It seems that
    displace handler is called only after another textarea is clicked
    and this is the main difference from focus-out.  I came to think
    of this when I was wondering whether or not we need to distinguish
    focus-out and displace, and similarly focus-in and place.

(2) It is necessary that clicking on a different widget of the same
    window should generate a focus-out call or similar.  The following
    is an example scenario.

    1) Run gedit with
       $ LANG=en_US.UTF-8 gedit test.txt &
       (LANG is set just for displaying menu items in English)
    2) Input a Korean word, but leave the last (Hangul) character
       still in the preedit state.
    3) Click on the floppy disk (Save) icon.
    4) focus-out handler is called.
    5) The preedit is committed.
    6) The whole word is saved to test.txt

    Some applications, for example firefox, seem to fetch the content
    of the preedit when a button is clicked, even if an IM does not
    commit the string.  For example, if you write a word in the search
    form at www.google.com, leaving it in the preedit state, and click
    on the "Google Search" button, the string is entered.

    This behavior of firefox and the above required focus-out event
    generation are related issues.  I think firefox's approach is a
    workaround and will be redundant (or unexpected from a Japanese'
    point of view?) if (2) is correctly implemented.

I am sorry for not being actively involved in uim development.  I am
busy these days, and in particular, I am applying for the next postdoc
position.  Still, I am trying to follow important developments,
particularly those related to Hangul input.

Regards,

Jae-hyeon