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

YAMAMOTO Kengo / YamaKen yamaken at bp.iij4u.or.jp
Sat Nov 18 21:55:35 EET 2006


At Sun, 19 Nov 2006 03:07:29 +0900,
ek.kato at gmail.com wrote:
> 
> 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.

> I thought you would say so ;)

I'm glad to be understood. Excuse me of my adherence :p

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

How about just add it without ABI incompatibility such as
following (or in more appropriate way)? It impacts very less
than exposing im_context.

g_object_set_qdata (G_OBJECT (widget), quark_is_text_widget, TRUE);

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

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



More information about the uim mailing list