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

[YAMAMOTO Kengo / YamaKen]

Hi Etsushi,

At Tue, 17 Oct 2006 13:09:45 +0900,
ek.kato at gmail.com wrote:
> 
> 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.

> > - (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 #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'?

I'm not sure what you recognized about my explanations. Please
retry to understand how my APIset works, along with following
supplemental information.

- Toolkit-side code does not know whether the IM is relocatable
  or not. It simply issues displace and focus-out

- An IM is 'relocatable' if the IM clears bridge-level preedit
  in response to 'displace', and update the preedit in resonse
  to 'place'. uim-level preedit is kept uncleared through the
  displace-place sequence

- An IM is 'non-relocatable' if the IM clears its uim-level
  preedit in response to 'displace'

- The APIset I suggest is not sensible about an sequential
  occurrence of displace-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?

All preedit relocations are preformed as a compromise for
safety, as I described in qinputcontext.cpp. The scenario #6 for
uim is also. But sorry, the situation was confusable. I've
rewritten the scenario. Does it make sense for you?

Scenario #6: Preedit relocation (deferred relocation)
  1) Input a Japanese sentence in hiragana into a Japanese
     multi-segment IM placed on a browser window
  2) Click scrollbar of the window
  3) focus-out handler has been called at 1) and ignored
  4) The user accidentally clicked another textarea of the
     window which shares input context with the textarea
     1). Since the two textarea shares the input context,
     ordinary IMs should clear the preedit to be ready to input
     on the new textarea. But because committing the preedit
     when leaving the textarea 1) does not make sense for
     Japanese IM, and re-input same text costs high, the IM
     preforms preedit relocation as a compromise
  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
  10) The user can relocate the preedit back again to the
      textarea 1)

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