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

[YAMAMOTO Kengo / YamaKen]

At Mon, 6 Nov 2006 17:43:39 +0900,
ek.kato at gmail.com wrote:
> 
> 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:
> > > > 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.
(snip)
> 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.

Both two sequences below are exactly what I intended. Thanks for
your effort.

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

Oh, really? Qt produces a focus-out event on 2). Is there an
alternative method to sense such occurrences on GTK+?

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

To distinguish scenario #6 from #5, a toolkit-side support is
required. Current GTK+ cannot handles scenario #6. The
difference is that whether the widget which acquired focus
immediately after the focus-out event of previous text widget is
text widget or not. In scenario #5, the widget 2) is also a text
widget. So textarea->textarea direct preedit relocation is
performed. But in scenario #6, the widget 2) is a scrollbar. The
toolkit must detect it, and the displace handler calling is
suppressed. The suppressed displace is called at 5) using the
toolkit-side variable last_text_widget, when the user clicked
another text widget. I did such handlings in immodule for Qt
although the API was not generalized as place/displace at that
time.

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

I supposed following. But since it requires considerable changes
of GTK+ and also involves hard discussions, it should be kept
unimplemented for now. We should focus to more important things
first.

gtk_a_text_widget_focus_in(widget, event)
{
  ...
  if (last_text_widget)
    gtk_im_context_displace(last_text_widget->im_context);
  ...
  gtk_im_context_focus_in(widget->im_context);
  gtk_im_context_place(widget->im_context);
}

At Sun, 15 Oct 2006 11:35:18 +0900,
yamaken at bp.iij4u.or.jp wrote:
> 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.

Oops, what I intended was scenario #5 and #6.

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