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

[Etsushi Kato]

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

Hmm..., I've confirmed that kate (kdebase-3.5.5, Qt-3.3.7 with
immodule) neither produces unsetFocus with clicking a scrollbar.

> > > 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...)
>
> The scrollbar behavior is acceptable. But focus-out by
> button-press is required to commit/clear preedit by uim
> appropriately. Does a button-press produce focus-out?

You mean pressing toolbar buttons (like "Save" button) with mouse
pointer?  Both GTK+2 and Qt3 don't seem to produce focus-out with
pressing "Save" button for overwriting existing files.  When pressing
a button with pop up (drop down?) label menu, they seems to cause
focus-out.  I've checked with gedit and kate.

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