[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 --- Additional comments from m...@openoffice.org Fri Jul 24 09:39:21 + 2009 --- *** Issue 75040 has been marked as a duplicate of this issue. *** - 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: issues-unsubscr...@gsl.openoffice.org For additional commands, e-mail: issues-h...@gsl.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 User pl changed the following: What|Old value |New value Target milestone|OOo 2.x |OOo 3.x --- Additional comments from [EMAIL PROTECTED] Fri Oct 19 14:01:47 + 2007 --- adjusting target due to limited resources - 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]
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 User pl changed the following: What|Old value |New value Target milestone|OOo 2.1 |OOo 2.x --- Additional comments from [EMAIL PROTECTED] Mon Oct 9 02:41:59 -0700 2006 --- changing target, i guess if there need to be fixes in gtk this won't make it into 2.1 - 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]
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 --- Additional comments from [EMAIL PROTECTED] Tue Sep 26 02:26:45 -0700 2006 --- Hmm, it looks like at least part of this, and possibly all of this, is the ordering that gtk gets to process events fired from the IM. i.e. this is with scim-bridge and gtk, and at least under some circumstances (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206261) some key events will be delivered to the app out of the intended sequence, so it's pointless to address any possible remaining problems with e.g. the hangul IM until the event ordering is reliable. - 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]
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 --- Additional comments from [EMAIL PROTECTED] Mon Sep 11 04:08:37 -0700 2006 --- Actually i have problems reproducing the problem (which probably just shows that one cannot trust input methods very far :-) ). Does the following patch solve the problem for you ? - 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]
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 User pl changed the following: What|Old value |New value Attachment is patch| |Created an attachment (id= | |39078) proposed patch for | |gtkframe.cxx --- Additional comments from [EMAIL PROTECTED] Mon Sep 11 04:11:38 -0700 2006 --- Created an attachment (id=39078) proposed patch for gtkframe.cxx - 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]
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 User pl changed the following: What|Old value |New value Target milestone|--- |OOo 2.1 --- Additional comments from [EMAIL PROTECTED] Thu Sep 7 09:51:57 -0700 2006 --- I don't see how m_aPrevKeyPresses can be empty in the commit callback: you should only be able to come here via gtk_im_context_filter_keypress, that is while still being in handleKeyEvent. The only way this could happen is that an IM eats an event but actually returns false in gtk_im_context_filter_keypress, this would lead to handleKeyEvent popping an event from the stack falsely. The m_aPrevKeyPresses.empty() in signalCommit is actually just a sanity check to avoid accessing an empty list in weird conditions. BTW: the single key handling is just a workaround itself; many controls do not handle extended text input and therefore rely on corresponding key events - including by the way on the modifier state which cannot be determined without a key event. I guess that normally these would not get filtered, but i would not necessarily want to rely on that thinking of the many many input methods we're talking here. However this leaves us with a key event (cursor right in this case), which gets a replaced unicode by the IM, certainly a valid case, which is not handled well currently. As immediate measure i think we could change CheckSingleKeyCommitHack so it would return false for gdk keyvals that do not correspond to a unicode (like cursor keys, function keys, etc.) What's your opinion ? - 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]
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 User pl changed the following: What|Old value |New value Assigned to|pl|cmc --- Additional comments from [EMAIL PROTECTED] Mon Sep 4 02:06:52 -0700 2006 --- Omitting the whole key release swallow stuff could break those input methods that do not swallow those events. However there was a patch in CWS vcl64 to send key release events also through gtk_im_context_filter_keypress (which is wrongly named and was documented wrong), please try whether that fixes the problem already; this should be the case if hangul properly filters the release events corresponding to the key presses. The relevant gtkframe.cxx version would be 1.52 and newer - 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]
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 User cmc changed the following: What|Old value |New value Assigned to|cmc |pl --- Additional comments from [EMAIL PROTECTED] Mon Sep 4 02:32:09 -0700 2006 --- unfortunately this is with OOD680_m2 which has that workspace integrated into it :-(, perhaps this could be described as a problem in this particular hangul input engine, but I'm also worried about stuff like holding down e.g. f for a few seconds which seems to generates multiple gtk key-press events but only one key-release event, so logic based on whether the backbuffer of keypresses is empty or not seems a little dodgy. - 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]
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
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]
[gsl-issues] [Issue 69051] scim hangul input and curs or keys
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=69051 User cmc changed the following: What|Old value |New value Attachment is patch| |Created an attachment (id= | |38820) possible patch --- Additional comments from [EMAIL PROTECTED] Tue Aug 29 04:14:26 -0700 2006 --- Created an attachment (id=38820) possible patch - 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]
