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

[Etsushi Kato]

Hi YamaKen,

Thanks for the explanation.  It makes your point very clear :)

On 11/6/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> At Mon, 6 Nov 2006 17:43:39 +0900,
> ek.kato at gmail.com wrote:
> > 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.

OK.

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

button-press or something?  (I think focus-out shouldn't be called
here since even if the window is scrolled, keypress event should be
treated appropriately in the input context with window scrolled back.
But this is totally not related to the question here...)

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

OK.  I almost understand the meaning, thanks.  I'll check Qt code later.

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

Hehe, I understand the meaning of 'API revision suggestion' now :)

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