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

[YAMAMOTO Kengo / YamaKen]

Hi Jae-hyeon,

At 16 Oct 2006 15:08:53 +0900,
jhpark at tuhep.phys.tohoku.ac.jp wrote:
> 
> YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> writes:
> 
> > 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)

> > 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.

Cannot. Although some call patterns that can be combined as I
wrote as above exist, following situations need the separated
handlers in addition to the focus handlers, or else multiplexed
and parameterized handlers. Since such parameterized handlers
are complex and not beneficial for everyone, I chose the 4
separated handlers way.

a. displace, place sequence without focus-out and/or focus-in

   See scenario #4. All the events are occurred in the same
   textarea (and so no focus-out occurs), and notifies the input
   context that cursor position has been changed. It should be
   distinguished from focus-in/out since uim uses the focus
   ownership transfer as inter-context activity arbitration, and
   of course the focus-handlers are semantically incorrect for
   cursor position changes. This sequence is the primal usage of
   the two handlers, and probably corresponds to the
   gtk_im_context_set_cursor_location() of GTK+.

b. focus-in, displace, place sequence

   Suppose an input method that has mode-indicator in preedit as
   follows.

     nihongo"nyuuryoI[kana]"

     - The string enclosed in "" means preedit
     - "I" means cursor
     - "[kana]" is the mode-indicator displayed as string in
       preedit

   When the user clicked another window, focus-out handler is
   called and the input method commit the string in response to
   the handler call.

     nihongonyuuryo"I[kana]"

   And then user clicked the point immediately after "nihongo"
   of the text, focus-in handler is called first and ignored.

     nihongonyuuryo"I[kana]"

   Second, displace handler is called at the previous cursor
   position and the input method clear the preedit.

     nihongonyuuryo""

   Last, place handler is called at the new cursor position and
   the input method update the preedit as follows.

     nihongo"I[kana]"nyuuryo

   To accomplish this operation regardless of implementation of
   the GUI toolkit, the four separated handlers are necessary, I
   think.

> (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

The focus-handlers are supposed to work as you described. Don't
worry.

>     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.

Thanks for the information. I didn't realized about the
issue. Do you know whether the behavior is Firefox-specific or
GTK+-generic?

Although it will be redundant and unneeded for us once the
handlers are implemented, it will not cause any harms for almost
all ordinary input methods (including Japanese ones).

One possible problem is that Firefox fetches the "[kana]"
indicator of the above example together with the search
string. But since such input methods will not be appeared for
now, it is not an emerging problem.

> I am sorry for not being actively involved in uim development.

No, no. Take it easy, and please excuse me of the one-year
deferment for the focus and cursor-move handlers implementation.

> 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.

Good luck, and take care of your own life first. Feel free to
select when and what code of uim you write. I favor elaborated
codes written with one's fun and preference. Keep your fun
writing.

------------------------------------------------
YAMAMOTO Kengo / YamaKen  yamaken at bp.iij4u.or.jp
FAMILY   Given / Nick