Description of problem: Starting from 1.1.2-7 (1.1.2-{5,6} were fine) the preedit string get committed even tho the conversation isn't finished. Hence many extra characters get committed into document. Version-Release number of selected component (if applicable): 1.1.2-7 How reproducible: everytime Steps to Reproduce: 1. LANG=ja_JP.UTF-8 oowriter (1a. compare to LANG=ja_JP.UTF-8 gedit) 2. ctrl-space 3. type "sushi" + "space" Actual results: the preedit string is committed before it convert to kanji Expected results: up the that stage (3), only kanji is convert in preedit area. not suppose to have anything committed. Additional info:
Major i18n problem for -7 as it cannot allow japanese and korean IM to input correctly. This problem will make japanese and korean users unusable on OOo. I would like to put this to higher severity. This will block fc2 updates being pushed using -7. I checked some new codes from /patches/vclplug/xim-fixes.diff are pushed to gtkframe.cxx so i assume the problem lies around there.
Michael Meeks has made some "improvements" in the IM code recently, perhaps that fixes it... I'll do a 1.1.2-8 soon so you can test that and see if that fixes it.
Hmm, I'm wrong, 1.1.2-7 includes those "improvlements". Anyway, can you help me reproduce? 1) Which iiimf-* packages do i need to install? 2) Do I simply need to start htt_server, or what do I need to do to start that? 3) Then I set my LANG and launch OOo?
No problem. Hopefully the info on IIIMF and the src in IRC helps. Let me know if you need anything else.
Ok. Problem is that OOo attempts to squash key release events by keeping around the last key press event, and matching against the next key release event. If they match, nothing is done. If they key release event is for a different key, OOo will end the preedit mode and leave the current preedit text in the buffer. This was triggered by the xim-fixes.diff patch. Key press/release events are not always being received in paired order for some reason, hence the problem. Its unclear why OOo needs to do this, and its also quite broken since you're not guaranteed to receive key press/release events in sequential order. A partial fix will be in 1.1.2-8, but you must exit preedit mode to use menu accellerators (ie, Alt+F or Alt+O while preediting won't work). Leon, it seems that the IIIMF gimlet is accepting GDK key events with accellerators, like Alt+F, and it probably shouldn't. Why is that? You'll notice in the new version if you type Alt+F, the F gets stuck into the preedit stream, indicating that the gimlet "handled" the event.
1.1.2-8 should be built by the time you wake up tomorrow, Leon.
Thanks for the fix - It partially fixed the problem. Here is a situation of preedit still being committed before actual commit: 1. ctrl-space 2. type "sushi" 3. press "end" (preedit is commit; and preedit buffer is hidden) 4. type "nippon" (preedit buffer (sushi) is shown again along with nippon) Other than "end" key, you can also reproduce with "shift"+"." etc.. -- For accelerators, LE (language engine, i.e. cannaLE) have power to receive it when LE is activiated, but LE do not generally use the common accelerators. However for cannaLE, i tested with: 1. ctrl-space 2. type "wa" 3. Alt-F the menu seems highlighted but it is not expanded, so openoffice.org seems can able receive the I have tested with gedit and seems LE does not catch Alt-F.
erm, on gtk2 apps, gtk2 grabs the key event before dispatching it to the libraries and/or the applications. so what you saw on gedit is, because of LE doesn't catch Alt-F. correctly because of gtk2 grabbed Alt-F first.
grr, s/because of LE/not that because of LE/
Leon, please test with 1.1.2-9 in rawhide now
Sorry Dan, unfortunately I still can reproduce it in -9: 1. ctrl-space 2. type "sushi" 3. press shift (preedit should commit but it is committed; and preedit buffer is hidden; in gedit, press shift does not do anything) 4. type "nippon" (preedit buffer (sushi) is shown again along with nippon) I have also tried your modified lib in people.r.c, and I couldn't able to activiate the LE after restart OOo. Let me know what else can I able to assist on this problem.
s/(preedit should commit/(preedit should not be committed/
I've also tested 1.1.2-9. unfortunately it's still broken - just to cralify, yesterday's shared library didn't support gtk2 yet, right? llch just noticed that it didn't work without httx (XIM-IIIMF bridge program) when he overwrote it onto -9. the below testcase still fails on -9 anyway, using XIM or IIIM. 1. make sure htt_server and cannaserver is running 2. run oowriter with LANG=ja_JP.UTF-8 XMODIFIERS=@im=none GTK_IM_MODULE=iiim or 2.a. run httx with LANG=ja_JP.UTF-8 2.b. run oowriter with LANG=ja_JP.UTF-8 XMODIFIERS=@im=htt GTK_IM_MODULE=xim 3. press ctrl+space s u s h i shift result: preedit line is hidden. but it didn't happens on -8 + the libs with httx.
This test case may be easier to understand and see visibly bad effects. Description of problem: While using cannaLE in openoffice writer, there is strange behavior with the "!" key where the uncommitted characters before the "!" are duplicated. Version-Release number of selected component (if applicable): 12.0.1-17.svn1994 openoffice.org-1.1.2-9 Steps to Reproduce: 1. Activate cannaLE in openoffice.org writer. 2. Type "sugoi" but do not commit. 3. Type "!" and let go of the spacebar. 4. Type "!" and let go of the spacebar. 5. Type "!" and let go of the spacebar. Actual Results: Each time you hit "!" after uncommitted text, it duplicates all of that text along with a "!" appended to the end. You can only avoid the duplication of text if you use ENTER to commit prior to hitting "!".
Ok, root cause is iiimf (gtkimcontextiiim.c in im-sdk) which creates "fake" key events in iiim_event_dispatch(). Gdk receives the keypress, calls OOo. OOo calls iiim, which creates the "fake" key press events and posts them to the GDK event queue. OOo then receives those key events later and ends preedit. The questions are: 1) Why does IIIMF create these key events 2) Why does GTK not have issues with the events, but OOo does 3) How do we fix OOo to act the way GDK/GTK does, OR 4) How do we fix IIIMF to not act this way
Mostly fixed in 1.1.2-10, some other problems are iiimf-related (gtk_im_context_reset ()).