GNOME Bugzilla – Bug 593868
gtk_im_multicontext_set_client_window recreate a new slave input context every time
Last modified: 2009-11-30 05:31:24 UTC
gtk_im_multicontext_set_client_window recreate a new slave input context every time Virtaal requires switching of Input methods each time an edit action is done (http://bugs.locamotion.org/show_bug.cgi?id=1119) I investigated the bug of virtaal. It is because gtk_im_multicontext_set_client_window recreate a new slave input context every time. Is it possible to avoid it?
I found gtk defines global_context_id to identify the im module for all screens. If im module is changed in any screens, this global value will be changed too. If the screens have different settings of im module, maybe it will cause some problem. So I think gtk should get rid of it, or define separated context_id for each screen.
Created attachment 142296 [details] [review] A patch to fix this problem
After looking at this some more, I am not really convinced that GTK+ is at fault here at all. I see the very same problem in every application that has multiple text widgets. Focus the first one, select an input method in the ibus applet, focus the next one, see ibus revert to 'no input method'. Even when I have an ibus input method selected in a gedit document, and open a new one, the new tab opens and the text view in it has 'no input method'. What happens inside GTK+ is that the text view creates a new immulticontext, and inside of it an new im context for the input method that is specified in the im-module setting: "ibus". And that new instance of the ibus im context for some reason does not take over the input method that is selected in the ibus applet, but insists on going back to 'no input method'.
Currently, ibus does not support shared input context between widgets or applications. We need consider many things for shared IC (for example how to handle preedit string, surrounding string, and etc, when switch focus between widgets or applications). Probably I will implement it in the future. But for this case, the simply way is fixing it in the immulticontext. BTW, if gtk or immulticontext could support shared IC, it will be perfect. All IMs do not need care of it.
Now, thats a convenient argument. 'Shared im context is hard, so let GTK+ do it instead of ibus'
Also, this is not really about sharing the im context. Just about setting the new im context to use the same engine.
As an aside, I'll note that I was quite confused by IM this week. I assumed there would be just "one" input method, or rather that it would be global. When Benjamin told me to read how Entry does it and pointed me to the code in gtk/gtkentry.c, I finally clued in that it is one per Widget. I have no opinion on the above conversation, other than to simply say that I did find it a bit strange that text entry GtkWidgets have to each create their own GtkIMContext*. I'm sure there's a reason for it (that has nothing to do with "hard"). I didn't know anything about this topic a week ago, so feel free to ignore my first impressions. AfC
(In reply to comment #5) > Now, thats a convenient argument. > > 'Shared im context is hard, so let GTK+ do it instead of ibus' :). It could avoid duplicating those code in different im contexts. It should also configurable in im menu or some where. If you like this design, I will try to provide a patch. (In reply to comment #6) > Also, this is not really about sharing the im context. Just about setting the > new im context to use the same engine. Actually, we don't know how many users really like all widgets with same engine or status. For many users were used to play with separated IC, because most time, we type different things in different widgets or applications. But for same widget, it should keep input method status all the time.
I think this change will fix your problem (will be in 2.17.11): commit 1c0ecc0380f8e30df297c5f1156c11ce70c98c81 Author: Matthias Clasen <mclasen@redhat.com> Date: Fri Sep 4 18:09:44 2009 -0400 Rework the way IM contexts are set Add a function to obtain the effective context id, and reset the slave only when the effective context id is different from the current context id, when setting a client window and on focus in. This might fix bug 593868 and bug 567124.
http://git.gnome.org/cgit/gtk+/tree/gtk/gtkimmulticontext.c#n290 I think in 209 line, if the immulticontext need not recreate a new slave context, it should set client window of slave context. Thank you very much.