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

[Etsushi Kato]

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

It may be a bad idea as Jae-hyeon noted, and seems difficult to solve
the problem by a text widget itself.

To solve the problem at toolkit layer, it requires cooperation between
text widgets and other widgets such as tool buttons, which I think
only a application class or a toplevel window can notify the event to
the input context.

For Qt, it may be possible to add fixFocusInputContext() member to
QApplication class, and make slot functions of pressed() signal in
button widgets call it.

In GTK+, how about adding gtk_widget_fix_input_context(widget) in
GtkWidget and call this from gtk_button_button_press() in GtkButton.

--- gtkwidget.c.orig    2006-11-16 03:37:53.000000000 +0900
+++ gtkwidget.c 2006-11-16 03:39:57.000000000 +0900
@@ -8057,5 +8057,23 @@
   g_object_notify (G_OBJECT (widget), "no-show-all");
 }

+void
+gtk_widget_fix_input_context (GtkWidget *widget)
+{
+  GtkWidget *toplevel, *focus_widget;;
+
+  g_return_if_fail (GTK_IS_WIDGET (widget));
+
+  toplevel = gtk_widget_get_toplevel (widget);
+
+  if (GTK_WIDGET_TOPLEVEL (toplevel)) {
+    focus_widget = GTK_WINDOW (toplevel)->focus_widget;
+    if (focus_widget) {
+      g_signal_emit (focus_widget, widget_signals[FOCUS_OUT_EVENT], 0);
+      g_signal_emit (focus_widget, widget_signals[FOCUS_IN_EVENT], 0);
+    }
+  }
+}
+
 #define __GTK_WIDGET_C__
  #include "gtkaliasdef.c"

--- gtkbutton.c.orig    2006-06-08 21:47:05.000000000 +0900
+++ gtkbutton.c 2006-11-16 03:37:12.000000000 +0900
@@ -1355,6 +1355,9 @@
     {
       button = GTK_BUTTON (widget);

+      /* call input context focus in/out */
+      gtk_widget_fix_input_context (widget);
+
       if (button->focus_on_click && !GTK_WIDGET_HAS_FOCUS (widget))
        gtk_widget_grab_focus (widget);

It seems work fine with a quick text.


>    - To avoid input context -internal state inconsistency about
>      focus, focus-in should be issued immediately after the
>      focus-out for preedit committing

OK.

>    - To avoid unexpected affections, the focus-out and focus-in
>      are only issued for input context. Widget-level focus
>      should not be changed

OK.  But in GTK+, it is difficult since generic widget doesn't have
any information about input context as in my test code.

>    - Inappropriate 'reset' handlings of the toolkits should also
>      be patched together since it is related to the auto-commit
>      issue

Yes.  We need to propose this change anyway.

> 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

Hmm... can we modify all the existing application? ;)

> 4. Hack uim bridges as:
>
>   - Snoops button-presses of the same window of the input
>     context, and issues the focus-out - focus-in sequence

This may be possible.  It also solve the input context specific
focus_in/focus_out handling in GTK+.  But I prefer toolkit level
solution.

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