Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 154789 - keyboard acceleration when xcin LE (zh_TW) is activated
keyboard acceleration when xcin LE (zh_TW) is activated
Product: Fedora
Classification: Fedora
Component: iiimf-le-xcin (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Leon Ho
: i18n
Depends On:
  Show dependency treegraph
Reported: 2005-04-14 03:16 EDT by Lawrence Lim
Modified: 2014-03-25 20:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-20 00:05:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
simple patch (1.04 KB, patch)
2005-04-18 08:05 EDT, Caolan McNamara
no flags Details | Diff
a proposed patch (614 bytes, patch)
2005-04-19 07:29 EDT, Akira TAGOH
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 47420 None None None Never

  None (edit)
Description Lawrence Lim 2005-04-14 03:16:22 EDT
Description of problem:
When iiimf-le-xcin is activated, keyboard acceleration such as copy (ctrl-c) and
paste (ctrl-p) does not work properly anymore. This is not observed for Canna LE
(ja) and hangul LE (ko). 

Reason why I file this bug is because it is possible to do copy and paste in the
gedit application when the LE is turned on.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.run oowriter with zh_TW.UTF-8
2.press ctrl-space, a enter, b enter, c enter, d enter, e enter
3.press shift-home, ctrl-c, ctrl-p OR press ctrl-q

Actual Results:  
Unable to copy and paste, keyboard acceleration does not work

Expected Results:  
Able to copy and paste, keyboard acceleration work as normal

Additional info:

it seems to be not depending on any locales. I can reproduce this on
zh_TW.UTF-8 too say. also, it affects FC2 and FC3.
Comment 1 Lawrence Lim 2005-04-14 03:17:13 EDT
Please ignore the Additional Info.
Comment 2 Caolan McNamara 2005-04-14 04:02:40 EDT
looks like ctrl as a OOo modifier doesn't get accepted when iiimf is enabled,
ctrl space to disable iiimf and its ok. 
Comment 3 Caolan McNamara 2005-04-18 08:05:28 EDT
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.
Comment 4 Caolan McNamara 2005-04-19 04:56:06 EDT
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.
Comment 5 Caolan McNamara 2005-04-19 04:57:35 EDT
s/and presumably gedit/and presumably xchat/
Comment 6 Akira TAGOH 2005-04-19 07:28:35 EDT
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.
Comment 7 Akira TAGOH 2005-04-19 07:29:31 EDT
Created attachment 113356 [details]
a proposed patch

Leon, does it make sense?
Comment 8 Leon Ho 2005-06-20 00:05:30 EDT
Thanks Tagoh-san and Lawrence. It is fixed in rawhide now. 

Note You need to log in before you can comment on or make changes to this bug.