To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 Issue #|69051 Summary|scim hangul input and cursor keys Component|gsl Version|OOo 2.0.3 Platform|All URL| OS/Version|Linux Status|NEW Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|code Assigned to|pl Reported by|cmc
------- Additional comments from [EMAIL PROTECTED] Tue Aug 29 04:14:05 -0700 2006 ------- So, I have a scenario where the single keyinput short-circuit for the input engine commit breaks for me. To reproduce. 1. activate scim, select "hangul" 2. type "gksrmf" you should have one commited character, and one highlighted "in progress" character. 3. press right arrow What happens for me, is that the last glyph "disappears" and doesn't get set into the document, but I see that it is sent to the document through the doKeyCallback shortcut for a single unicode character. So, what I see as the sequence of events that OOo receives here when the right arrow is pressed is... 1. OOo gets "right-arrow" key event from gtk in GtkSalFrame::signalKey and adds it to m_nPrevKeyPresses 2. OOo gets "buffer commit" event from gtk, it falls into the single character condition, and checks to see what key is at the top of m_nPrevKeyPresses and reuses it's keycode (which is arrow) 3. writer gets an arrow keycode, but with "unicode character from buffer" value 4. but writer processes it as an arrow, so the character disappears from the screen 5. back in vcl, the real arrow key get processed 6. writer gets arrow keycode, normal arrow processing Now, on my x86_64 box I actually have a *different* sequence 1. OOo gets "buffer commit" event from gtk, either 1.a.1 m_nPrevKeyPresses is empty and the short-circuit is not used OR 1.b.1 falls into the single character condition, and checks to see what key is at the top of m_nPrevKeyPresses and reuses it's keycode "foo"[1] 1.b.2 writer gets an "foo" keycode, but with "unicode character from buffer" value 1.b.3 writer processes it as a character insertion, and use unicode character, all is well 2. OOo gets "right-arrow" key event from gtk in GtkSalFrame::signalKey, and stuff progress as normal [1] where foo != right arrow, as right arrow hasn't been seen yet. But foo generally seems a fairly arbitrary letter from the past. e.g. holding down a letter long enough to repeat the letter will generate multiple press events and thus add multiple characters to m_nPrevKeyPresses, but releasing it will generate one single release event and only pop one event from m_nPrevKeyPresses. Perhaps there is a simple fix here. or some race condition. Or the problem lies in the input engine. But the keypresses stuff seems unreliable. What about the following alternative hack patch? Too naive ? --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
