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

[Etsushi Kato]

On 11/19/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> At Sun, 19 Nov 2006 03:07:29 +0900,
> ek.kato at gmail.com wrote:
> > > I supposed that it simply emits the move_cursor signal
> > > regardless of receiver widget class. Since identifying receiver
> > > class as follows disallows user text widget implementation, it
> > > cannot be accepted.
> > >
> > >   (GTK_IS_TEXT_VIEW (focus_widget) || GTK_IS_ENTRY (focus_widget))
> >
> > Since "move_cursor" signal is not a general widget signal, it will
> > cause a error if it is emitted to non-GtkEntry/GtkTextView widget
> > (though maybe harmless).  We need a new generic widget signal or make
> > move_cursor signal generic if we use delegate method, I think.
>
> Oops. Sorry, I misunderstood about g_return_if_fail() which is
> invoked in g_signal_emit_by_name().

I've read GObject Reference Manual and found g_signal_parse_name().
Using this solves the problem without adding new attribute to
GtkWidget.

void
gtk_widget_fix_input_context (GtkWidget *widget)
{
...
  if (GTK_WIDGET_TOPLEVEL (toplevel))
    {
      focus_widget = GTK_WINDOW (toplevel)->focus_widget;
      if (focus_widget)
        {
          guint id;
          GQuark quark;
          if (g_signal_parse_name ("move_cursor",
                                   G_TYPE_FROM_INSTANCE (focus_widget),
                                   &id, &quark, TRUE))
            g_signal_emit(focus_widget, id, quark,
                          GTK_MOVEMENT_LOGICAL_POSITIONS, 0, FALSE);
        }
     }
}

However, again, I don't think emitting "move_cursor" is suitable in
this case.  If we use "move_cursor" for GtkEntry/GtkTextView to notify
button_press in toolbuttons, it will break your model about
distinguishing focus-in/out and place/displace.  "move_cusor" handlers
in GtkEntry/GtkTextView are off course used for real cursor move by
keyboard, and this should use place/displace model.  Or you intended
that call fix_im_context_weakly() only if count of "move_cursor" is 0,
and call displace_im_context() and place_im_context() when count != 0?
 This seems to be a pretty dirty hack for me.

And as noted above, to revise im reset code in
gtkentry.c/gtktextview.c, it requires preedit displace/place handlers
in GtkIMContext.  Do you intended that this also shouldn't be touched
at the moment?

On 11/19/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > That's fine.  And it is needed to revise semantics of
> > gtk_text_view_reset_im_context() and _gtk_entry_reset_im_context().
>
> Yes. The corrupted use of gtk_im_context_reset() of GTK+ is
> needed to be corrected, and properly distinguished from input
> termination that involves commit and/or preedit update.
>
> The latter operation can be replaced with the focus-out/in
> sequence. It can be expected that almost all IMs commit and/or
> update its preedit on the sequence without a reset.
>
> > It may requires additional interface with GtkIMContext.
>
> I think that now is not the time to add the interface. For
> almost all languages that have ephemeral automatonish input
> context, the interface may be named as 'fix', 'finish' or
> 'terminate'. But in Japanese multi-segment IM, its context
> should not be terminated by a trivial button-press. Such
> Japanese IM should be able to ignore it. So the interface should
> be named as 'weak_fix', 'finish_hint', 'request_terminate' or
> else.
>
> But at this time, I'm not confident whether the dedicated
> interface for it is really needed or not. We should acquire more
> experiences about it before suggesting a new API.

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