Description of problem: ibus can not work in xterm Version-Release number of selected component (if applicable): [phuang@localhost ~]$ rpm -q im-chooser im-chooser-1.2.2-1.fc10.i386 [phuang@localhost ~]$ rpm -q imsettings imsettings-0.103.0-1.fc10.i386 How reproducible: Steps to Reproduce: 1. select ibus in im-chooser 2. start xterm and typing 3. Actual results: Did not get any chars in xterm. Expected results: Additional info: If I starts xterm with 'XMODIFIERS="@im=ibus" xterm', xterm can works fine.
No XIM_FORWARD_EVENT sent back from ibus. I'll look into ibus.
The above comment is a side-effect, because the XIM_FORWARD_EVENT sent back is usually sent synchronously. so it was the second time event and ibus was just waiting for XIM_SYNC event. Anyway, I have tracked down this issue. The real issue is that imsettings doesn't support any X events forwarded from the different screen yet, but ibus always sends back the X event without checking that, and set (XKeyEvent *)ev->same_screen to False. i.e. "xkp.xkey.same_screen = False" in _xim_forward_gdk_event in client/x11/main.c. this caused discarding the event in imsettings. I'm still not sure if just forwarding it as is really makes the expected behaviour and have never tested yet how the event is sent when inputing something from another screen. thus, I'd suggest to fix this in ibus as always sending same_screen = False is incorrect at least.
s/XIM_SYNC/XIM_SYNC_REPLY/, but anyway.
Setting same_screen = True works. Thanks.
Fixed in ibus-0.1.1.20081016-1.fc10
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Looks fine to me now in f10.