Red Hat Bugzilla – Bug 104299
gtk2: kinput2 "enter" commit broken in gaim
Last modified: 2007-11-30 17:10:31 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Description of problem:
gaim-0.6X Japanese characters looks great in Severn+, unfortunately kinput2
exhibits behavior making it almost unusable for Japanese users.
* Normally you would send an instant messenge by hitting ENTER.
* kinput2 uses the ENTER key in order to "commit" characters. Japanese users
hit the ENTER key, and nothing happens within gaim.
* CTRL-ENTER does "commit" characters, but almost nobody knows this since other
kinput2-capable applications do not need it.
* When you are done entering characters, if kinput2 is still active (user did
not disable with SHIFT-SPACE) the customary ENTER to send instant messenge does
nothing. Customarily Japanese users rarely need to turn off kinput2.
ChipX86 of the gaim project mentioned that he talked with Owen Taylor about this
problem. He mentioned that otaylor indicated that this problem is within gtk2,
and unfortunately it would be very difficult to fix because it would take a
large rewrite or refactoring to make it possible. On a somewhat unrelated note,
I suspect this is the cause of similar unusability of gaim in Windows for
Additionally all gtk2 applications suffer from an unrelated annoying behavior
described in Bug 84860 and Bug 84859 while qt applications do not have this problem.
Just filing this here and hoping gtk2 can be fixed one day. For the moment I
cannot convince any of my Japanese friends to live on Linux.
Version-Release number of selected component (if applicable):
This is actually gaim's bug, because gaim is going to send the messages if the
users are hitting ENTER. I'm not sure the author knows this issue, but gaim has
a workaound to fix this issue. it is the Interface->Shortcuts->Control-Enter
sends message on the preferences. it works to me.
To fix this issue correctly, gaim will needs to check
gtk_im_context_filter_keypress() when it receives the keyevent and keyval is
GDK_Return or GDK_KP_Enter then.
Created attachment 94440 [details]
I did a quick hack, and I've tested gaim with this patch. it works fine to me.
Thanks! I asked gaim developers to regression test it to make sure it causes no
non-japanese problems, and I'm giving this to japanese users tonight for
I am very aware of this problem, and have been since it was introduced
(0.60cvs). Unfortunately, what I am _not_ aware of is a clean solution. I
personally use the Ctrl+Enter-to-send method. This has been in the gaim
bugtracker in several incarnations, and I have filed or posted to a couple of
related Gtk2 bugs for it. (http://bugzilla.gnome.org/show_bug.cgi?id=90082 and
The second bug there indicates that otaylor agrees with me that the patch
attached to this report, while seeming to work, is potentially problematic.
I would LOVE to come up with a clean and correct solution to this problem, it is
one of the longest-outstanding gaim international-usability bugs I am aware of.
Hmm, yes, if GtkIMContext is designed as the applications doesn't need any extra
code perfectly, this patch is also just workaround, though.
Tested this workaround quite a bit with several users. It seems to behave
exactly how I expect now.
Is the only concern that it is using a private gtk2 interface, which may
disappear at any time?
Ethan said this as the reason why he will not be committed to gaim upstream. In
any case unless we discover that this breaks something, I am applying this to
Fedora Linux's gaim packages.
Please apply this to gaim-0.70. This patch has been in fedora.us 0.68 and 0.70
for 20 days now with no ill effects.
"This seems to be working" != "This is good and correct", Warren. As indicated
in the above referenced bugs, this is not a solution I am pleased with, and I do
not intend to apply it to gaim.
I was not referring to upstream gaim, I was referring to downstream Fedora Core
where we have a predictable gtk2 that wont change during a stable release and
break the underlying private interface which this depends upon.
Owen what would you recommend?
After talking with owen about this, I've included this patch in 0.71-2. Should
be in the next tree.