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

I thought you would say so ;)

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

Well, if current GTK+ has any text widget attribute (like
GTK_IS_TEXTWIDGET attribute), I would agree with you and use a
delegate method.  But it doesn't seem to be designed so, I would
prefer to expose im_context and use directly from GtkWidget.

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

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.



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

OK.

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

I agree adding meaningful name for the interface is difficult.

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

OK.

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

This seems fine.

Anyway, maybe exposing im_context is big change at the moment (without
clearly designed new IM API), let's go ahead with your idea.

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