Description of problem: When going to invoke an application with ibus immodule, I can see an warning like: IBUS-WARNING **: Connect to unix:path=/tmp/ibus-tagoh/ibus-localhost-12 failed. Failed to connect to socket /tmp/ibus-tagoh/ibus-localhost-12: No such file or directory and can't activate IM. Version-Release number of selected component (if applicable): ibus-1.1.0.20090407-3.fc11.x86_64 How reproducible: always Steps to Reproduce: 1.log into the remote machine with ssh 2.run application 3. Actual results: No ibus working Expected results: ibus should works as scim does. Additional info:
The better solution is fall back to xim im context, but gtk lack the API to create im context from im module.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Would it be useful to have some script to start ibus-daemon on the remote machine or can we just run ibus-daemon like that for that?
But it may conflict with im-settings. So it is better to let user to use XIM by self.
What SCIM had taken a way to accomplish that, i.e. bringing up the necessary process from immodule was a trade-off for this issue I suppose.. If we decide that that way is evil, I tend to agree with using XIM.
How to get XIM working?
Nevermind - guess I was testing cross-locale yesterday. Should ssh export XMODIFIERS then? locale$ ssh -X remote remote$ ibus-daemon ; GTK_IM_MODULE=ibus gtk-app also seems to work well enough FWIW.
(In reply to comment #7) > Nevermind - guess I was testing cross-locale yesterday. > > Should ssh export XMODIFIERS then? Yeah > > locale$ ssh -X remote > remote$ ibus-daemon ; GTK_IM_MODULE=ibus gtk-app > > also seems to work well enough FWIW. But it only works if the remote machine has ibus.
(In reply to comment #8) > > Should ssh export XMODIFIERS then? > Yeah Ok - I am changing component to openssh and hope that XMODIFIERS can be added to SendEnv list in /etc/ssh/ssh_config.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This works fine. closing. thanks.