[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