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

[Jae-hyeon Park]

Hello YamaKen,

YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> writes:
> At Tue, 7 Nov 2006 03:26:22 +0900,
> ek.kato at gmail.com wrote:
> > 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?

I agree that patch should be done at the toolkit level, not at the
application level.

> 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

I don't know whether or not these are the right functions to issue
focus-out/in.  An example code at
http://doc.trolltech.com/3.3/wizard-example.html
calls QLineEdit::text() [in Wizard::dataChanged()] whenever a new
Korean syllable is committed.  I am afraid it may cause the following
problem.  The string enclosed in "" means preedit.
A user types Hangul characters, namul (나물), and the input proceeds
in the following sequence.

    "n"
    "na"
    "nam"
    na"mu"

Here, na is committed, and "mu" is remaining in preedit.  At this
point, QLineEdit::textChanged() signal is emitted, and
Wizard::dataChanged() calls QLineEdit::text().  Then, focus-out is
issued, and "mu" is committed which should not.

    namu
    namu"l" (나무ㄹ)

I think some other part of the toolkit should be patched.

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

Regards,

Jae-hyeon