Description of problem: This situation only occurs in Evolution Mail when creating a new Mail Message. In other widgets the LE works fine. Version-Release number of selected component (if applicable): im-sdk 11.4-70.svn1875 evolution 1.5.92.2-2 How reproducible: Always Steps to Reproduce: 1. In the ko locale, open Evolution 2. Select the Mail compoent and create a new Mail Message 3. In the main Mail Messgae area, start using hangul LE Actual results: Characters get committed from right to left. Expected results: Characters should be committed from left to right. Additional info:
Shouldn't this be assigned to evo/gtkhtml3 or something then?
Looking into the problem it is definitely about gtkhtml. Moving the component.
Debugged as follow: - Currently when you enter string into preedit buffer, gtkhtml will create preedit area (a text with black background attr) at the cursor position. - The problem arises when a input method commits a string while preedit buffer is not empty, the string will be committed at the cursor position again - Hence the string is behind of "preedit area" as the preedit area did not move. - When the input method commits another string, it will be at the back of the first committed string
Created attachment 103672 [details] proposed patch - first draft Attached is the proposed patch. I have tested in CJK input methods and they worked okay with it.
I haven't tested it, but the patch looks sane to me. Owen's working on the 3.3.0 branch so I'd like his opinion before I apply (and hopefully we can get it upstream)
The patch makes sense to me, if you want to file it upstream, Leon, I'll say the same there.
Dave & Owen, thanks! Filed and attached my proposed patch & description: http://bugzilla.ximian.com/show_bug.cgi?id=65670
Owen, I found out a problem on the current implementation is it affects normal non-IM typing coz it uses commit as well. This is a better patch for ignoring the positioning when typing in english so that it gets positioning correctly on all occasions now. If you can commit again asap then it would be wonderful. Apologies on this. Test case tested: 1. moving cursor then type 2. return then type 3. insert between characters on a. normal english typing b. korean (partial commit) c. traditional chinese (full commit) d. indic hindi
Created attachment 103937 [details] new patch for above description
Tested with Leon's gtkhtml3 test build which includes the patch, korean input has been resolved. In additional, tested with en, ja, tw and cn to ensure the patch does not affect other input. The result is very positive. Thanks.
I'm seeing some problems with the latest gtkhtml3 in rawhide (bug #113104); are they related to these changes?
Sorry, that should have read bug #133104
3.3.2 is completely screwed up, yes, you probably want to dup that bug on this. I have a candidate patch that I'm going to build into the build system now. Not sure it is better for CJK, but at least should make the composer usable for English. (This has been my top priority bug for the last day, since I'd like to be able to compose mail...)
*** Bug 133104 has been marked as a duplicate of this bug. ***
gtkhtml3-3.3.2-3 (in Rawhide) has what I think is a pretty good set of fixes for this problem. It tests out for me with various input methods.
*** Bug 133173 has been marked as a duplicate of this bug. ***
*** Bug 133202 has been marked as a duplicate of this bug. ***
Rawhide works for me too, shouldn't we close this bug?
I have tested rawhide with CJK and en_US input with the scenario described in this bug together with bug 133104, bug 133173 and bug 133202. If possible, we will resolve the bug after receving confirmation from Indic input.
I have tested hindi with gtkhtml3-3.3.2-3 (from Rawhide) for this issue using UnitLE. Confirmed that the characters are input correctly from left to right.
Thanks Jatin. Confirmed fixed in rawhide and resolving this bug.