Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154789 - keyboard acceleration when xcin LE (zh_TW) is activated
Summary: keyboard acceleration when xcin LE (zh_TW) is activated
Alias: None
Product: Fedora
Classification: Fedora
Component: iiimf-le-xcin
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Leon Ho
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-14 07:16 UTC by Lawrence Lim
Modified: 2014-03-26 00:52 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-20 04:05:30 UTC

Attachments (Terms of Use)
simple patch (deleted)
2005-04-18 12:05 UTC, Caolan McNamara
no flags Details | Diff
a proposed patch (deleted)
2005-04-19 11:29 UTC, Akira TAGOH
no flags Details | Diff

System ID Priority Status Summary Last Updated 47420 None None None Never

Description Lawrence Lim 2005-04-14 07:16:22 UTC
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: oowriter with zh_TW.UTF-8 ctrl-space, a enter, b enter, c enter, d enter, e enter 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 07:17:13 UTC
Please ignore the Additional Info.

Comment 2 Caolan McNamara 2005-04-14 08:02:40 UTC
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 12:05:28 UTC
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 08:56:06 UTC
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 08:57:35 UTC
s/and presumably gedit/and presumably xchat/

Comment 6 Akira TAGOH 2005-04-19 11:28:35 UTC
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 11:29:31 UTC
Created attachment 113356 [details]
a proposed patch

Leon, does it make sense?

Comment 8 Leon Ho 2005-06-20 04:05:30 UTC
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.