Red Hat Bugzilla – Bug 782484
ibus returns "No input window" for terminals executed via launcher
Last modified: 2012-03-18 21:29:08 EDT
Description of problem: If a user has some sort of desktop launcher that initiates a shell script, user is unable to use ibus in this window - s/he gets "No input window". Note that launching this via a different method (i.e., running it from within an existing terminal) seems to be ok - this appears specific to launching. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. in ibus, enable an alternate input method ("Chinese - Pinyin") 2. echo gnome-terminal >/tmp/testshell.sh 3. chmod u+x /tmp/testshell.sh 4. create a desktop launcher, Name: testshell, command=/tmp/testshell.sh 5. from within a terminal window, attempt to execute /tmp/testshell.sh. 6. In resulting gnome-terminal, ctrl-Space to switch to Chinese - Pinyin, and attempt to enter chinese characters ("ni hao") and observe results ("你好") 7. close spawned gnome-terminal 8. Launch testshell from the desktop launcher you created. 9. In resulting gnome-terminal, ctrl-Space to switch to Chinese - Pinyin, and attempt to enter chinese characters ("ni hao") Actual results: * ni hao * clicking the ibus icon shows "No input method" Expected results: 你好 * clicking the ibus icon in the systray shows relevant IME information Additional info: This is a regression of some sort - it used to work. I am not sure whether it is ibus or xfce, though I think it only started happening recently after upgrading ibus.
Fixing Fedora version -> 16
Hmm.., I think you don't run any window managers. The new ibus needs the focus in event to set the input methods. I think you can switch input method engines if you run 'metacity &' command. The current ibus uses no global input mode and it will be changed in f17 but I'd think changing f16 implementation might be a risk. So I'd suggest to run metacity or change the ibus property: 1. Run ibus-setup. 2. Select 'Advanced' tab and enable 'Use toggle shortcut keys to enable or disable an input method' check button.
I'm running xfwm as part of xfce. Also, setting the hotkey method does not appear to enable the ime in the scenario listed above.
I have no problem with xfwm. 1. Run gnome-terminal as the initial session. 2. Run xfwm4 3. Run ibus-daemon --xim I also tried xfce4-sesion and 'xfwm4 --replace' and ibus also works fine. Probably I will close this bug.
Please review the description and the steps. It's not a matter of just running $whatever from gnome-terminal. Rather, you will need to create a launcher (icon on the desktop, etc.) and launch $whatever from there. Items executed as triggered from a launcher fail.
Created attachment 559302 [details] Desktop launcher testcase 1. Place the attached launcher file in ~/Desktop. 2. Double-click to execute 3. Attempt to initialise the IME and/or click on the IME applet to read that it has "No input window" TBH I am still having a hard time determining whether this is an ibus bug or xfce.
I don't see any problems with attachment 559302 [details]. I think it should not be be a problem how gnome-terminal is launched. I think the problem is how you launch ibus-daemon and configure gtk-im-module. > TBH I am still having a hard time determining whether this is an ibus bug or xfce. Probably I think it's neither an ibus bug or xface but your setting failure. When you say to click the desktop file, it means the desktop enviroment is running with a window manager likes metacity. You could check if your client could load ibus gtk-im-module. % strace gnome-terminal 2>&1 | grep im-ibus.so stat("/usr/lib64/gtk-3.0/3.0.0/immodules/im-ibus.so", {st_mode=S_IFREG|0755, st_size=31640, ...}) = 0 open("/usr/lib64/gtk-3.0/3.0.0/immodules/im-ibus.so", O_RDONLY|O_CLOEXEC) = 13