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

[YAMAMOTO Kengo / YamaKen]

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

I see. Thanks for the detailed explanation, Jae-hyeon.

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

OK.

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

Did you mean that any pressed() signal of button instances are
needed to be connected to QApplication::fixFocusInputContext()?

If so, please let me know about these questions.

  - Who connects it?
  - When is it connected?
  - How much does it cost about memory? (Qt/Embedded may be
    serious about it)

And it seems that fixFocusInputContext() is a typo of
fixInputContext(). Right?

> 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);
> +    }
> +  }
> +}

The gtk_widget_fix_input_context() interface seems good. But I
want to keep widget-level focus untouched. How about following
change? It is supposed that gtk_editable_set_position() calls
gtk_im_context_focus_{out,in}() as the workaround on setting
same position. This workaround does not affect widget-level
focus and does not break the GTK+ ABI.

    if (focus_widget && GTK_IS_EDITABLE (focus_widget)) {
      GtkEditable *editable = GTK_EDITABLE (focus_widget);
      gint pos = gtk_editable_get_position (editable);
    
      gtk_editable_set_position (editable, pos);
    }

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

It can be assumed that all widget that have im_context is a
GtkEditable, I think. So I expect that my code fragment written
as above works for it.

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

OK.

------------------------------------------------
YAMAMOTO Kengo / YamaKen  yamaken at bp.iij4u.or.jp
FAMILY   Given / Nick