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): iiimf-le-xcin-0.1.10-1 openoffice.org-1.9.92-2 How reproducible: Always 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.
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.