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):
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
Unable to copy and paste, keyboard acceleration does not work
Able to copy and paste, keyboard acceleration work as normal
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]
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.