Hide Forgot
Description of problem: When x input method in gtk3 application, hangul input is broken. $ gedit [...] ** (gedit:3457): WARNING **: Invalid change to preedit string, first=0 length=1 (orig length == 0) ** (gedit:3457): WARNING **: Invalid change to preedit string, first=0 length=1 (orig length == 0) ** (gedit:3457): WARNING **: Invalid change to preedit string, first=0 length=3 (orig length == 0) ** (gedit:3457): WARNING **: Invalid change to preedit string, first=0 length=1 (orig length == 0) Version-Release number of selected component (if applicable): 1.3.99.20110127-4.fc15.x86_64 How reproducible: always Steps to Reproduce: 1. launch gedit 2. change to x input method in gedit 3. input hangul Actual results: rkrkrkrkrkrkrk가가가가가 Expected results: 가가가가가가가가가가가 Additional info: gtk3-3.0.0-1.fc15.x86_64 ibus-hangul-1.3.0.20100329-5.fc15.x86_64
Interested. Thanks for filing the bug. I might notice the issue but I forgot it. We need to remove the snooper when we switch the input methods.
https://github.com/fujiwarat/ibus/commit/6575fab67eaf6f8e483a001f26dbfd61c3258e0a
http://koji.fedoraproject.org/koji/taskinfo?taskID=2845917
ibus-1.3.99.20110206-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/ibus-1.3.99.20110206-2.fc15
ibus-1.3.99.20110206-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Not Fixed in ibus-1.3.99.20110206-4.fc15.x86_64. gtk3-3.0.1-2.fc15.x86_64 ibus-hangul-1.3.1-1.fc15.x86_64
There are two problems. One is that snooper was not removed when the im client is switched from ibus to xim and it was fixed in ibus-1.3.99.20110206-4.fc15. Another is that ibus-x11 doesn't receive KeyPress events because KeyRelease events are buffered in X11. If the im client is gtk-xim, the gtk_im_context_xim_filter_keypress() calls XFilterEvent() and XFilterEvent() calls XSendEvent() internally. ibus-x11 receives the key event from XFilterEvent() -> WaitXIMProtocol() -> xim_forward_event(). ibus_hangul_engine_process_key_event returns FALSE in KeyRelease. If the process_key_events returns FALSE, xim_forward_event() sends the same event again with XIM_FORWARD_EVENT. It seems gdk does not pick up the forwarded KeyRelease events with XFilterEvent() in _gdk_x11_display_queue_events(). So if you type the next chars, the events are not KeyPress but the buffered KeyRelease. XFilterEvent() always returns FALSE for the buffered events in _XimProtoKeypressFilter(). So gtk-xim outputs the ASCII chars but not the chars from ibus-hangul. XIM_FORWARD_EVENT has the option of sync_bit but it seems it's not handled correctly at present. The possible solution is to ignore the KeyRelease event for gtk-xim. --- ibus/client/x11/main.c +++ ibus/client/x11/main.c @@ -654,7 +654,7 @@ xim_get_ic_values (XIMS xims, IMChangeIC for (i = 0; i < (int) call_data->ic_attr_num; ++i, ++ic_attr) { if (g_strcmp0 (XNFilterEvents, ic_attr->name) == 0) { ic_attr->value = (void *) malloc (sizeof (CARD32)); - *(CARD32 *) ic_attr->value = KeyPressMask | KeyReleaseMask; + *(CARD32 *) ic_attr->value = KeyPressMask; ic_attr->value_length = sizeof (CARD32); } } I'll talk with the maintainer.
If we apply this fix, we need to make sure there is no regressions in qt3, qt4, X and Java. I'll be back this problem after beta maybe because now I focus on gnome-shell. I guess this problem is not so critical since you can use ibus client but not gtk-xim.
I'd suggest this is a gtk3 bug: https://bugzilla.gnome.org/show_bug.cgi?id=645993