Bug 154789
Summary: | keyboard acceleration when xcin LE (zh_TW) is activated | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lawrence Lim <llim> | ||||||
Component: | iiimf-le-xcin | Assignee: | Leon Ho <llch> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | caolanm, eng-i18n-bugs, tools-bugs | ||||||
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: | 2005-06-20 04:05:30 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: | |||||||||
Attachments: |
|
Description
Lawrence Lim
2005-04-14 07:16:22 UTC
Please ignore the Additional Info. looks like ctrl as a OOo modifier doesn't get accepted when iiimf is enabled, ctrl space to disable iiimf and its ok. Created attachment 113320 [details]
simple patch
This simple patch would enable the ctrl + ... modifiers when the iiimf is
enabled, only allow ctrl + space to be caught by iiimf so as to enable/disable
the iiimf itself. Not sure yet if that would disable other useful ctrl + foo
which iiimf needs to see.
Looking into this, I see that the same problem affects also affects xchat, and that gtk_im_context_filter_keypress returns true for a ctrl + c/v/q combo. Why does gtk_im_context_filter_keypress return true for a ctrl + c and ctrl + v etc, i.e. the same state as c and v. Would it not be better to differenciate at the iiimf level between modified letters and unmodified letters and not capture them in the filter in the first place ? gtk (and so gedit) basically checks for its global accelerators before attempting to gtk_im_context_filter_keypress what the user has typed, so ctrl-c and ctrl-v are removed from the queue before iiimf sees them in the gedit case. While OOo (and presumably gedit) pass their keystrokes through gtk_im_context_filter_keypress and assume it knows what it's doing and only processes what it passes through to the application. Which does seem safer, rather than second guess what accelerators are safe to hide from the filter. s/and presumably gedit/and presumably xchat/ I see what you mean. well, it's because xcin LE eats all ctrl+? key events and processes it. gtk_im_context_filter_keypress is basically filtering the keyevents which was processed by the input method, but not all key events. in fact, it doesn't happen on Canna LE and Hangul LE, because these LEs doesn't process the unnecessary key events. reassigning to iiimf-le-xcin then. Created attachment 113356 [details]
a proposed patch
Leon, does it make sense?
Thanks Tagoh-san and Lawrence. It is fixed in rawhide now. |