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

[Etsushi Kato]

On 11/6/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 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:
> > > - (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 #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

OK.  Now I understand the meaning of 'relocatable' as a state of
uim-level preedit when 'place' handler is called including focus
change.

But maybe I still don't understand about the timing of 'displace'
handler, and who calls it.  Following is my understanding in a bridge.

1. Just move cursor within a text area (as scenario #4)

  gtk_something_move_cursor(w) {
    uim_displace_context(c1, true); // -> (anthy-displace-handler ac1 #t)
    ...
    uim_place_context(c1, true); // ->  (anthy-place-handler ac1 #t)
  }

2. Click anther text area in a application (as in scenario #5)

  gtk_something_leave_notify(w1) {
    ...
    uim_displace_context(c1, false); // -> (anthy-displace-handler ac1 #f)
    // or this may be called at the top of gtk_something_focus_out()
  }
  gtk_something_focus_out(w1) {
    ...
    uim_focus_out_context(c1); // -> (anthy-focus-out-handler ac1)
  }
  gtk_something_focus_in(w2) {
    ...
    uim_focus_in_context(c2); // -> (anthy-focus-in-handler ac2)
  }
  gtk_something_enter_notify(w2) {
    ...
    uim_place_context(c2, false); // -> (anthy-place-handler ac2 #f)
    // or this may be called at the end of gtk_something_focus_in()
  }

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

Hmm... First of all, I don't think focus-out is called at the timing
of 3).  Anyway, why 'displace' handler is called after the 'focus-out'
handler in this case?  I still don't understand the difference between
scenario #5 and #6.  Or 'displace' handler is called at the top of
newly clicked context?  If so, doesn't it conflicts with the sequence
in scenario #5?

gtk_something_focus_out(context) {
  ...
  uim_focus_out_context(context);
  last_text_widget = context;
}
gtk_something_focus_in(new_context) {
  uim_displace_context(last_text_widget);
  ...
  uim_focus_in_context(new_context);
  ...
  uim_place_context(new_context, false);
}


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