Red Hat Bugzilla – Bug 203057
GTK+ grabs keys for accelerator key before passing through IM
Last modified: 2007-11-30 17:11:40 EST
Description of problem:
When you create new mail, and you want to use Hanja in korean.
We type korean char and then press F9 for Hangul/Hanja converting.
It is working with Hangul/Hanja converting.
But, if you doesn't want convert after you press F9, you need to press ESC key.
when press ESC key it asks to kill new mail windows.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Turn on Hangul with SCIM in evolution
2. Make new mail.
3. type "rh"
4. press F9
5. press ESC key
cancel the new mail
cancel Hangul/Hanja convertion
> Steps to Reproduce:
> 1. Turn on Hangul with SCIM in evolution
> 2. Make new mail.
> 3. type "rh"
> 4. press F9
> 5. press ESC key
Using the following steps does not crashes or kills the composer window on
Can you please confirm the status of this bug?
Yes after press ESC key
It was asking me "Are you sure you want to discard the message".
Did you type "rh" in Korean? Because steps 3 & 4 is converting korean to Chinese
I still cannot reproduce this bug...
This is *exactly* what I followed
- start evolution from en_US locale
- new > mail message
- focussed the composer - ascii mode
- activated scim, selected hangul
- pressed "rh" and then F9 to bring candidate selection window
- hit escape
Is it specific evolution? I mean with gedit/kedit/firefox whats the result? All
behave perfectly as expected for me.
Can you please attach a backtrace if its possible for you?
Please check the version of scim...
rpm -q scim scim-hangul
apparently summary is misleading. read the original report carefully. it says
that Escape key should works to cancel the conversion instead of destroying the
composer window. You can see the differenct behavior between evolution and
It won't asks you to discard editing unless you typed something on the composer
window once, because preediting doesn't makes any changes. therefore no
This is because GTK+ grabs the key event in front if the applications sets any
keys as the accelerator keys. it really depends on the applications if this
happens or not though, actually this is a well-known GTK+ bug.
reassigning to gtk2 for the above reason.
"bug" is up for discussion. Well-known behaviour, yes.
Upstream bug tracking this is http://bugzilla.gnome.org/show_bug.cgi?id=90082