GNOME Bugzilla – Bug 351476
Right after saving a document, Korean Input System temporarily works wrong.
Last modified: 2007-09-02 13:21:44 UTC
Please describe the problem: After saving a docoument, Korean Input System package(nabi) showing wrong behavior. In normal situation, nabi assembles 2 or 3 jamos(components) to show meaning of word. But due to the bug of gedit, nabi doesn't assemble jamos after saving document(Ctrl+S). Steps to reproduce: Prerequisite : you should use nabi(Korean Input Package) to reproduce this bug and make .gnomerc in home folder. It contains these environment configuration. ==================================================== export XMODIFIERS="@im=nabi" export GTK_IM_MODULE=xim ==================================================== 1. Write short sentence. 2. Ctrl+S and continue typing. Actual results: after step 2, Korean input system(nabi) seperates each jamo(components) rather than assembles 2 or 3 jamos. This is not a proper behavior because Korean characters should assemble to have a meaning. Expected results: normal input continues. Does this happen every time? yes.(also Korean Input System(nabi) developer confirmed too) Other information: This bug does not show up in the other application(e.g. openoffice, bluefish, winefish, evolution etc).
We really need help in investigating this kind of bugs.
Thanks Paolo. What information should be informed of to fix this bug? I would help you finding, and investigating this bug.
Actually I don't know where to start to investigate this bug. If you are a developer, you could try to reproduce it inside a debugger and try to see what is going bad.
Finally, I found the reason. I seems that the XFilterEvent() function is called twice for a event. So it causes the xim server to malfunction. In im-xim.so, gtk_im_context_xim_filter_keypress() calls XFilterEvent with every keyevent. However, for some reason, the same keyevent is delivered to gtk_im_context_xim_filter_keypress() twice. Especially, when the user presses Control, Alt and Shift keys in hangul mode, it may happen.
The problem is that the keyevent will be delivered to gtk_im_context_xim_filter_keypress() inside gedit_window_key_press_event(). When a user presses a key, gedit_window_key_press_event() will call gtk_widget_event() on the focused_widget. Inside gtk_widget_event(), gtk_im_context_xim_filter_keypress() will be called. This function always processes XFilterEvent() whether it handled or not. Then, gedit_window_key_press_event() will call GTK_WIDGET_CLASS (gedit_window_parent_class)->key_press_event (widget, event). This call gtk_im_context_xim_filter_keypress() again with the same key event. This makes the xim not work.
Is there any progress on this problem?
Which version of gedit are you using/looking at?
I don't remember what version it was. But now, I've tested it with GEdit 2.18.2 and gtksourceview 1.8.3, and I found it works fine. I'm using debian unstable.
indeed that's why I asked, I am pretty sure it was fixed in 2.18. Thanks for your feedback.