Bug 506474 - ibus-anthy no longer inputs Japanese in urxvt and uxterm
ibus-anthy no longer inputs Japanese in urxvt and uxterm
Product: Fedora
Classification: Fedora
Component: ibus-anthy (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jens Petersen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-17 09:24 EDT by Scott Robbins
Modified: 2009-06-17 22:49 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-17 22:35:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Scott Robbins 2009-06-17 09:24:42 EDT
Description of problem: 
ibus only works with some programs, such as Firefox, OpenOffice, and most GTK applications.  It doesn't work with urxvt (rxvt-unicode) or uxterm.  It had worked in the past, this seems to have happened in the first or second week of June, around the time of F11 release.  (Problem also exists in F12 rawhide).

This is probably an upstream bug as I'm able to reproduce the problem in an Ubnutu alpha installation.

Version-Release number of selected component (if applicable):

How reproducible:
After setting XMODIFIERS, LC_CTYPE (if applicable) GTK_IM_MODULE, open a uxterm or urxvt terminal.  Hitting ctl+space does nothing and there is no option to input Japanese.  Doing the same with Firefox or Gnome-terminal, to name two, produces the option for Japanese input as expected.

Steps to Reproduce:
1.Start ibus, set variables if necessary
2.Open uxterm and attempt to use ctl+space to enter Japanese
3.Mutter under your breath when it doesn't work.  (Ok, that one is optional).  :)
Actual results:

No ability to input Japanese

Expected results:
Ability to input Japanese.  (Which was working before.  Unfortunately, I don't use it that often on my Fedora machines, so am not quite certain as to the date.  However, judging from a post on Fedora forums, by someone with a problem inputting Chinese (post is at http://forums.fedoraforum.org/showthread.php?t=222553) probably 28 May, 2009.  

Additional info: None that seems relevant.  This seems to be consistent on three different systems, (one running rawhide) as well as on various Virtual Machines.)
Comment 1 Peng Huang 2009-06-17 21:03:57 EDT
1. What's the version of ibus packages? Please get version by 'rpm -qa ibus\*'
2. Please paste the output of 'ps aux|grep ibus'.
3. Please close ibus in im-chooser, and start ibus in console `ibus-daemon -v --xim`. and paste the output of it.

Comment 2 Scott Robbins 2009-06-17 22:17:07 EDT
Thanks for the quick response. 

rpm -qa ibus\*


This seems to be the latest available for F11.  

ps aux |grep ibus

scottro   2010  0.2  0.1 131960  2960 pts/3    S+   22:04   0:00 ibus-daemon
scottro   2011  0.2  0.2 136648  3304 pts/3    S+   22:04   0:00 /usr/libexec/ibus-gconf
scottro   2012  4.7  1.5 280432 23604 pts/3    S+   22:04   0:00 python /usr/share/ibus/ui/gtk/main.py
scottro   2020  1.8  0.7 185444 10828 pts/3    S+   22:04   0:00 python /usr/share/ibus-anthy/engine/main.py --ibus
scottro   2039  0.0  0.0  89000   812 pts/4    S+   22:05   0:00 grep ibus

Starting from console (I always do, actually, however I use ibus-daemon &--this is in flubox, but the same problem occurs in Gnome)

ibus-daemon -v --xim

(ibus-daemon:2040): IBUS-WARNING **: Connect to unix:path=/tmp/ibus-scottro/ibus-unix-0 failed: Failed to connect to socket /tmp/ibus-scottro/ibus-unix-0: Connection refused.
/usr/lib/python2.6/site-packages/dbus/connection.py:242: DeprecationWarning: object.__init__() takes no parameters
  super(Connection, self).__init__(*args, **kwargs)
/usr/lib/python2.6/site-packages/dbus/connection.py:242: DeprecationWarning: object.__init__() takes no parameters
  super(Connection, self).__init__(*args, **kwargs)

Now, after running the final command you mention--it works.  Trying after that, using ibus-daemon --xim & seems to work with all applications.  

That is, I have always used (and until that update, successfully) ibus-daemon &

Now, doing that only works with GTK apps.  However, adding the --xim option seems to fix the issue.  

So, I'm not sure if this should be closed, or perhaps treated as a documentation issue.

Thank you very much.
Comment 3 Peng Huang 2009-06-17 22:35:12 EDT
I think you could use im-chooser to start ibus. It will start ibus with right arguments.
Comment 4 Scott Robbins 2009-06-17 22:49:58 EDT
Yes, that also works.  The other way is a little easier and faster for me, but both ways solve the issue. 

I think this can be closed, and many thanks for your help.

Note You need to log in before you can comment on or make changes to this bug.