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

Jae-hyeon Park jhpark at tuhep.phys.tohoku.ac.jp
Thu Oct 26 09:05:25 EEST 2006


Hi YamaKen,

YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> writes:

> At 16 Oct 2006 15:08:53 +0900,
> jhpark at tuhep.phys.tohoku.ac.jp wrote:
> > 
> > (1) Can displace and place handlers be combined?  It seems that
> >     displace handler is called only after another textarea is clicked
> >     and this is the main difference from focus-out.  I came to think
> >     of this when I was wondering whether or not we need to distinguish
> >     focus-out and displace, and similarly focus-in and place.
> 
> Cannot. Although some call patterns that can be combined as I
> wrote as above exist, following situations need the separated
> handlers in addition to the focus handlers, or else multiplexed
> and parameterized handlers. Since such parameterized handlers
> are complex and not beneficial for everyone, I chose the 4
> separated handlers way.

Now, I think I understand the difference between displace and place.
A displace handler is called before the toolkit moves the (visible)
preedit area, and a place handler is called after the preedit area has
been moved to a new location.  Is this correct?

> > (2) It is necessary that clicking on a different widget of the same
> >     window should generate a focus-out call or similar.  The following
> >     is an example scenario.
> > 
> >     1) Run gedit with
> >        $ LANG=en_US.UTF-8 gedit test.txt &
> >        (LANG is set just for displaying menu items in English)
> >     2) Input a Korean word, but leave the last (Hangul) character
> >        still in the preedit state.
> >     3) Click on the floppy disk (Save) icon.
> >     4) focus-out handler is called.
> >     5) The preedit is committed.
> >     6) The whole word is saved to test.txt
> 
> >     Some applications, for example firefox, seem to fetch the content
> >     of the preedit when a button is clicked, even if an IM does not
> >     commit the string.  For example, if you write a word in the search
> >     form at www.google.com, leaving it in the preedit state, and click
> >     on the "Google Search" button, the string is entered.
> > 
> >     This behavior of firefox and the above required focus-out event
> >     generation are related issues.  I think firefox's approach is a
> >     workaround and will be redundant (or unexpected from a Japanese'
> >     point of view?) if (2) is correctly implemented.
> 
> Thanks for the information. I didn't realized about the
> issue. Do you know whether the behavior is Firefox-specific or
> GTK+-generic?

I think it is firefox-specific.  If you do the above example with
gedit now, you actually lose the last character in preedit.

> Although it will be redundant and unneeded for us once the
> handlers are implemented, it will not cause any harms for almost
> all ordinary input methods (including Japanese ones).

I see.

> One possible problem is that Firefox fetches the "[kana]"
> indicator of the above example together with the search
> string. But since such input methods will not be appeared for
> now, it is not an emerging problem.

This should be solved once the focus-out hander call is correctly
implemented.  It will clear the preedit before firefox fetches its
content.

> Good luck, and take care of your own life first. Feel free to
> select when and what code of uim you write. I favor elaborated
> codes written with one's fun and preference. Keep your fun
> writing.

Thanks!

Jae-hyeon



More information about the uim mailing list