Created attachment 310546 [details]
gtk2-xim-default.patch

This should help input method users who experience multilib problems a great deal.

Hmm, have you tested this patch ?

I don't see in the code how this patch could make it work in a situation where
the xsettings says "scim", but scim is not available. 

(In reply to comment #3)
> Hmm, have you tested this patch ?

Yes I believe so.  I can retest when I can get rawhide-x86_64 to install.

> I don't see in the code how this patch could make it work in a situation where
> the xsettings says "scim", but scim is not available. 

Well I guess in the same way that it currently falls back to XIM for CJKT?

requested by Jens Petersen (#27995)

(In reply to comment #4)
> (In reply to comment #3)
> > Hmm, have you tested this patch ?
> 
> Yes I believe so.  I can retest when I can get rawhide-x86_64 to install.
> 
> > I don't see in the code how this patch could make it work in a situation where
> > the xsettings says "scim", but scim is not available. 
> 
> Well I guess in the same way that it currently falls back to XIM for CJKT?

Did you have a chance to test this?

(In reply to comment #3)
> Hmm, have you tested this patch ?
> 
> I don't see in the code how this patch could make it work in a situation where
> the xsettings says "scim", but scim is not available. 

I agreed. it may works on some box but may not on some, because it's really up to the order of gtk.immodule and what the kind of immodule you currently have.

I tested again and it still works for me.  Here is what I did:

1) install F10-Preview or rawhide x86_64
2) boot, login, and turn on scim with im-chooser
3) yum remove gedit.x86_64
4) yum install gedit.i386 (note scim-bridge-gtk.i386 is not installed)
5) run gedit and try to use scim (can't use xim)
6) sed -i -e s/"ko:ja:th:zh"/"*"/ /etc/gtk-2.0/*/gtk.immodules
7) run gedit again (xim works for scim)

(7) seems an improvement on (5)

I forgot to say that step (4) requires adding a i386 repo but any i386 gtk app that supports immodules should be ok (ie not gtk-demo;).

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

putting "*" for xim would mean that _all_ locales would default to loading xim, even en or de. That has been discussed (and rejected) upstream before, see  http://bugzilla.gnome.org/show_bug.cgi?id=58201. 

I don't think we should work around multilib deficiencies in this way.

Moving this to imsettings since the solution suggested in the upstream bug was to use GTK_IM_MODULE=xim by default.

Having said that: who is right, KDE or GNOME?

What's the expected behavior here? do we want to use im-xim.so by default anyway? that's really up to xinput conf from IM packages and right now imsettings just exports envvar from it though.

Or do you want imsettings to resolve multilib issue and set GTK_IM_MODULE=xim as needed?

I am not sure what the solution is, but I filed this bug to improve the behaviour under multilib when a requested gtk immodule is missing.

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

Hmm, well, do you want to have a kind of GTK_IM_MODULE_FILENAME=im-ibus.so in ibus.conf say? it may be possible to pre-check if immodule is available before setting up GTK_IM_MODULE in xinput.sh though. and if not, fall back to xim or simple with notification say.

(In reply to comment #16)
> Hmm, well, do you want to have a kind of GTK_IM_MODULE_FILENAME=im-ibus.so in
> ibus.conf say? it may be possible to pre-check if immodule is available before
> setting up GTK_IM_MODULE in xinput.sh though. and if not, fall back to xim or
> simple with notification say.  

Yeah the hack I used to have for scim was: only enable im-scim-bridge
if immodules matched gtk2 multilib otherwise try im-scim and then fallback to XIM,
which sounds similar to your suggestion above.  In the end it got a bit
fragile but maybe it can be done better?

Can I suggest that we fix the underlying multilib problem instead of inventing all these complicated fallback schemes ?

Sure. that would be ideal way and I like it rather than having a hack.
Do you have any idea to resolve this issue?

Given that you are going to modify gtk+ to deal with this multilib problem without the above, if GTK_IM_MODULE is set or immodule is explicitly requested through XSETTINGS, how about falling back to im-xim.so anyway when the request isn't accepted by any reasons? otherwise works as usual, i.e. trying to look up against current locale?  Though we need to move im-xim.so back to gtk2 package for Fedora.
That may somewhat makes sense and workable solution for everyone regardless of the needs of IM. though it will takes a little overhead to deal with the key events due to passing through XIM protocol anyway.

Aside from that, the interesting idea is to take similar way we did for fonts. i.e. adding a tag like gtkimmodule(ibus) to rpm and pulling in through PackageKit if not available? that may takes some time to finish. so it may be far away from ideal, but anyway.


FWIW it may be a good idea to notify users if the requested immodule isn't available and fall back to something. that would avoid confusion.

I think your suggestions are good. :)

Or any way to specify gtkimmodule per arch under XSETTINGS?

no, I am not going to turn on xim for everyone.

How about something like using:

  GTK_IM_MODULE=ibus:xim

to tell gtk2 first to try ibus, then xim, and then just use simple input *for each arch* (and similarly though XSETTINGS).

That sounds good to me :)

Moving back to gtk2 based on comment 18 (and comment 22 perhaps).

I will try to file an upstream bug too.

Ok filed https://bugzilla.gnome.org/show_bug.cgi?id=603559.

This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

attached a patch for comment #22 on upstream bug.

Can we have any update here? I don't see anyone replied in upstream bug.

Still see this in F15.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Also affects gtk3 I think.

Matthias would this be a good time to revisit this
and think how gtk can handle multilib modules better
(and also avoid bugs like bug 711018 :)?

for gtk3, this issue was fixed in 3.3.3, also added this support to imsettings in 1.2.7.1. FYI