GNOME Bugzilla – Bug 522885
GTK applications can not destroy IMContext immediately.
Last modified: 2012-05-26 19:53:10 UTC
Please describe the problem: In the trunk, gtk added a new featrue - supporting XSETTINGS for immodule. Please refer bug 502446. I found a problem with it, when users use XSETTINGS to change the immodule settings, all gtk applications will not destroy old IMContext immediately. The widget having im context must be focused in, and then the MultiContext will destroy the old im slave context. It's very weird, especially, if there are many input widgets on screen, users must click widgets one by one. Steps to reproduce: 1. Open several gedit or gnome-terminals. 2. Use im-chooser to enable Input Method, and select SCIM as Input Method. 3. Focus to gedits. 4. Use im-chooser to disable Input Method. Actual results: SCIM will not be disable. You will see scim's tray icons. If you click gedits one by one, the scim will exit. Expected results: All scim im contexts will be destoried immediately, and scim will exit. Does this happen every time? always. Other information:
To fix this, we'll need to keep a list of all GtkIMMulticontext instances and in im_module_setting_changed, run over that list and call gtk_im_multicontext_set_slave (multicontext, NULL, FALSE).
Does it work that let GtkIMMulticontext listen to GtkSettings' signals and call gtk_im_multicontext_set_slave (multicontext, NULL, FALSE) by self?
That would work too, but there can be a lot of entries in an application, and the setting will only change infrequently. In those cases, we usually connect a single handler (like we already do in the current code) and have it iterate over all the objects that need to know about the change.
*** Bug 528502 has been marked as a duplicate of this bug. ***
Of course, there is nothing that forces scim to wait for the last client to exit before it goes away.
Hmm, just found this now. IIUC, this should be fixed with the patch in bug 675365.
ok, lets assume so