GNOME Bugzilla – Bug 118651
gtkimmulticontext doesn't set_use_preedit on subsequent slaves
Last modified: 2011-02-04 16:12:02 UTC
On Tue, 2003-07-29 at 09:36, Botond Botyanszki wrote: > Hello, > > The GtkIMContext interface provides an API gtk_im_context_set_use_preedit > that the application can call to notify the input method whether it > supports preedit or not. > I think it is usually called by the application after GtkIMMultiContext is > instantiated. I have only seen gnome-terminal actually using this API. > > The problem is that if the input method is changed (by switching to a > different one in the MultiContext menu), the newly loaded module cannot > know about the preedit support, because the set_use_preedit function isn't > called again. > > e.g. if I start gnome-terminal with > `GTK_IM_MODULE="my-module" gnome-terminal` > then my-module gets the use_preedit value, but if I start gnome-terminal > without any im modules preloaded and then switch to my-module from the > menu, it won't get the set_use_preedit flag. > > Is this a faulty design in GtkIMContext, or should the application > (gnome-terminal/libvte) do something else in addition ? A bug in GtkIMMulticontext - it should remember the flag and pass it to the new "slave" input method. Please file a bug in bugzilla about it. I wouldn't object to a patch along with it either. Regards, Owen
Created attachment 18751 [details] [review] fix for "gtkimmulticontext doesn't set_use_preedit on subsequent slaves"
Created attachment 19357 [details] [review] Patch preserving bin compat and covering a few more things
Tue Aug 19 14:37:46 2003 Owen Taylor <otaylor@redhat.com> * gtk/gtkimmulticontext.[ch] (struct _GtkIMMulticontext): Replace client_window field with 'priv' pointer, retaining binary compatibility. * gtk/gtkimmulticontext.c (gtk_im_multicontext_set_slave): save use_preedit/cursor_location/focus status and set up the new slave appropriately. (#118651, Botond Botyanszki)