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

[YAMAMOTO Kengo / YamaKen]

At Sat, 18 Nov 2006 04:10:31 +0900,
ek.kato at gmail.com wrote:
> 
> On 11/17/06, Etsushi Kato <ek.kato at gmail.com> wrote:
> > On 11/17/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > Oops, sorry. You're right. But I think that the responsibility
> > > violation of your code should be avoided even if it's a
> > > workaround hack. I prefer keeping im_context private to text
> > > widgets, as described in gtk_entry_init(). And I also want to
> > > keep full-implementability of user text widgets that use
> > > im_context possible.

> > > static void
> > > gtk_entry_init (GtkEntry *entry)
> > > {
> > >   ...
> > >   /* This object is completely private. No external entity can gain a reference
> > >    * to it; so we create it here and destroy it in finalize().
> > >    */
> > >   entry->im_context = gtk_im_multicontext_new ();
> > >   ...
> > > }
> >
> > Agreed.
> 
> After some thought, I think making im_context information available on
> gtkwidget.c is simple solution.

I took a look at the patch. But even if it is a easy
implementation for this workaround, it isn't a good solution for
GTK+ toolkit itself.

In current implementation of GTK+, only the text widget
implementations GtkTextView and GtkEntry know and depend on
GtkIMContext. And each text widget instances can assume current
state of their own im_context based on what they operated on the
object, since the im_context is a private object. But once your
patch has been applied, these simplicity about class dependency
and object state consistency will obviously be lost. I think
that it is a considerable loss of the design and
maintainanceability of GTK+ toolkit. So the "fix input context"
operation should be delegated to each text widget as an abstract
message (such as I suggested), instead of directly be
manipulated on the private entity im_context from outside.

Even if you have designed it for the further input method API
improvement of GTK+, it is not reasonable to do it now
(i.e. exposing the im_context for only this workaround is not
reasonable).

> It will make
> gtk_widget_fix_focused_input_context() available even in a custom
> widget with GtkIMContext which doesn't inherit GtkEntry or
> GtkTextView.

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

At Fri, 17 Nov 2006 19:13:28 +0900,
ek.kato at gmail.com wrote:
> 
> On 11/17/06, YAMAMOTO Kengo / YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > How about using move_cursor signal with zero move to notify text
> > widgets the event?
> 
> 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.

But again, since calling gtk_im_context_focus_out() and
gtk_im_context_focus_in() as a pair is bother and unmeaningful,
defining a static function such as fix_im_context_weakly() in
each text widget implementation seems better.

/*
 * Hints that committing or clearing of composing character/string for
 * almost all languages that have ephemeral automatonish input
 * context. But some input contexts such as Japanese multi-segment
 * style methods may ignore it (i.e. context and preedit may not be
 * cleared). This is a workaround for auto-committing/clearing and it
 * should be formalized as a GtkIMContext interface once we have
 * gotten confident about its rationale.
 */
static void
gtk_entry_fix_im_context_weakly (GObject *object)
{
  GtkEntry *entry = GTK_ENTRY (object);

  gtk_im_context_focus_out (entry->im_context);
  gtk_im_context_focus_in (entry->im_context);
}

> Or just call
> gtk_im_context_focus_out() and gtk_im_context_focus_in() sequentially
> within it?

Yes, as a workaround in each text widgets.

> 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 &&
>         (GTK_IS_TEXT_VIEW (focus_widget) || GTK_IS_ENTRY (focus_widget)))
>       g_signal_emit_by_name (focus_widget, "move_cursor",
>                              GTK_MOVEMENT_LOGICAL_POSITIONS, 0, FALSE);
>   }
> }

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