GNOME Bugzilla – Bug 81506
can't input characters using XIM in applet's GtkEntry
Last modified: 2010-01-24 01:06:00 UTC
built from HEAD, 2002-05-09 my locale is zh_CN.GB2312, using an XIM application called "miniChinput". While I can input in common appliction's GtkEntry using XIM (just use the XIM input method, the XIM application have not poped up), I can't do so in applet's. Saw this bug in gdict's applet and mini-commander. I switch the input method to "Default" and all is ok. I guess this is a panel bug so I file it here.
Hi - what window manager are you using ? Kevin: does this sound like its your GtkEntry focus problem ?
What is XIM? I don't understand what it is supposed to do. Yah, this may be a window manager issue that has since been fixed (if you are using Metacity)
I also don't understand what it is supposed to do. Mark : where could I get this info ?
about XIM, just see here: http://developer.gnome.org/arch/i18n/xim.html I guess it's not related to the focus problem, for I *did* focus into the GtkEntry. But I'll rebuild from CVS and try this again.
What's the status on this bug, carton@linux.net.cn?
I updated gnome2 from cvs and it seems that this bug is still unsolved.
Trying this with mini_commander_applet, here is my little finding. It seems that there are some key inputs (like ENTER, TAB) which are not given to its gtkentry's "key_press_event" signal handler, and this could be a fatal problem with the input methods if they use these non-filtered keys to execuate some input method functions. ( Actually, not being able to receive ENTER is kinda fatal for the Japanese input methods I'm using - it's hard to commit composed text without receiving it.) carton: does the above have anything to do with your problem here?
maybe， but my problem here seems to be worse. I'm using a Chinese input method called "xsim", after I press "Ctrl-Enter" to activate that input method, whatever I typed has no response, the over-the-spot compose box does not display, and I can't press "Ctrl-Enter" to switch back. All that I can do is right click and choose the "Default" input method from menu to switch back. Anyway, since most people won't use XIM input method here, so it won't disturb too much.
The problem here is that mini-comander uses ENTER/TAB to execute commands/tab complete respectively and probably stops the key_press signal there. I'm not sure what the solution is.
Hello. I suffer from this bug, using the default settings from a complete GNOME 2.4.1 tarball build/install (at least I'm pretty sure it's this bug). I can middle-click style insert text into the applet prompts and click ``Lookup'' (in the case of the Dictionary Lookup applet, can't do anything really with the Command Line applet). I can't get any of the applet prompts to take keyboard focus, even when I haven't opened any other applications (no cursor blinks in the prompt). I've tried all the input methods available in the menu that appears when I right-click on the text prompt: Default, Amharic (EZ+), Cedilla, Cyrillic (Transliterated), Hangul (KSC 5601), IPA, Inukitut (Transliterated), Thai (Broken), Tigrigna (Eritrean), Tigrigna (Ethiopean), Unicode Character Map, Vietnamese (VIQR), and X Input Method. I am very troubled. :-(
If I click on the white space of one of the prompts, and then click on either Applications or Actions in the main menu, I can see the cursor blinking in the applet's input box (but I still can't type in it, and as soon as I close the menu the cursor disappears). If I move an applet from one panel to another, I am able to type something in immediately after the move as long as no application windows get selected in the interim period.
Has this bug been resolved?
Haven't heard anything for quite a while. Closing.