[Uim] Focus and cursor position shift handlings (bug #7729)
YAMAMOTO Kengo / YamaKen
yamaken at bp.iij4u.or.jp
Thu Nov 9 09:53:54 EET 2006
At Tue, 7 Nov 2006 03:26:22 +0900,
ek.kato at gmail.com wrote:
>
> 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
(snip)
> > > > > 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.
I've tested Qt-3.3.7 with attached patch and I realized that it
exactly behaves as you said. Excuse me of my mis-remembrance or
mis-generalization of a Qt-internal focus processing.
In scrollbar case, such behavior is acceptable for uim and does
not cause a problem.
> > > > 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?
Yes.
> 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.
I've confirmed it on Qt3. An ordinary push button does not
produce focus-out on press, as you said.
This is a problem for the design assumption of uim focus-out
API. It assumed that a button-press produces focus-out to commit
preedit string on a button-press, as Jae-hyeon and I discussed
in the message below.
To resolve the "auto-commit on a button-press" problem, I
thought of these 4 solutions. I prefer 1. as an effective and
not so improper way. Etsushi, Jae-hyeon, what do you think about
it?
1. Patch GTK+ and Qt itself as:
- Issues focus-out - focus-in sequence for input context on
any text getter method of text widgets, such as
QLineEdit::text(), QTextEdit::selectedText(), etc
- To avoid input context -internal state inconsistency about
focus, focus-in should be issued immediately after the
focus-out for preedit committing
- To avoid unexpected affections, the focus-out and focus-in
are only issued for input context. Widget-level focus
should not be changed
- Inappropriate 'reset' handlings of the toolkits should also
be patched together since it is related to the auto-commit
issue
2. Patch applications as:
- Issues the focus-out - focus-in for input context of a text
widget such as Firefox's text fields
3. Patch applications as:
- Calls a new immodule-level API 'terminate' dedicated for
this problem, to notify input context that its client want
to finish the text composition
- Since the timings "its client want to finish the text
composition" are application-specific semantics and cannot
be detected by toolkit layer, applications are responsible
for it. But since such i18n-aware responsibility is hard to
be done by ordinary programmers, this solution will not
work well
- This solution also works for Japanese multi-segment text
properly
4. Hack uim bridges as:
- Snoops button-presses of the same window of the input
context, and issues the focus-out - focus-in sequence
Except for this "auto-commit on button-press" issue, I think
that no problem about the new APIset is existing. So I'll commit
the new interfaces to trunk once this issue has been finished
and if no further discussion is proposed.
At 26 Oct 2006 15:05:25 +0900,
jhpark at tuhep.phys.tohoku.ac.jp wrote:
>
> 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:
> > >
> > > (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.
------------------------------------------------
YAMAMOTO Kengo / YamaKen yamaken at bp.iij4u.or.jp
FAMILY Given / Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qt-x11-free-3.3.7-textedit-focus-monitor-20061109.diff
Type: application/octet-stream
Size: 2228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/uim/attachments/20061109/0bec3aad/attachment.obj
More information about the uim
mailing list