[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