Bug 130751
| Summary: | IM commiting in the wrong direction in gtkhtml | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lawrence Lim <llim> | ||||||
| Component: | gtkhtml3 | Assignee: | Dave Malcolm <dmalcolm> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | dmalcolm, eng-i18n-bugs, nigel, otaylor, tools-bugs, walters, wtogami | ||||||
| Target Milestone: | --- | Keywords: | i18n | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2004-09-23 06:31:50 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 125997, 131589 | ||||||||
| Attachments: |
|
||||||||
|
Description
Lawrence Lim
2004-08-24 10:11:35 UTC
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. |