|Summary:||gtk should handle missing multilib immodules more gracefully|
|Product:||[Fedora] Fedora||Reporter:||Jens Petersen <petersen>|
|Component:||gtk2||Assignee:||Matthias Clasen <mclasen>|
|Status:||ASSIGNED ---||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||i18n-bugs, mclasen, myllynen, tagoh|
|Target Milestone:||---||Keywords:||FutureFeature, MoveUpstream, Reopened|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-01-17 02:22:05 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Jens Petersen 2008-06-26 03:43:25 UTC
Description of problem: Currently with im-scim.so or other gtk immodules installed on a multilib system gtk goes not fallback to XIM when the default gtk immodule is missing for an arch. Could you please enable im-xim.so by default for all locale so that gtk can fallback to XIM. Qt has done this for a long time. How reproducible: every time Steps to Reproduce: 1. install rawhide-x86_64 and turn on scim with im-chooser 2. install an i386 gtk app package (eg gedit.i386) 3. run application and try to use scim Actual results: 3. gtk falls back to no input method (ie simple IM context) Expected results: 4. should fall back to XIM allowing users to input in SCIM Additional info: If no XIM server (input method) is configured or available this change should not have any affect. Locale defaulting to specific gtk immodules should not be affected. users
Comment 1 Jens Petersen 2008-06-30 00:54:42 UTC
Created attachment 310546 [details] gtk2-xim-default.patch
Comment 2 Jens Petersen 2008-06-30 00:55:59 UTC
This should help input method users who experience multilib problems a great deal.
Comment 3 Matthias Clasen 2008-07-08 15:01:03 UTC
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.
Comment 4 Jens Petersen 2008-07-09 04:35:00 UTC
(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?
Comment 5 Tony Fu 2008-09-10 03:09:33 UTC
requested by Jens Petersen (#27995)
Comment 6 John Poelstra 2008-10-19 02:33:53 UTC
(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?
Comment 7 Akira TAGOH 2008-10-19 06:25:34 UTC
(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.
Comment 8 Jens Petersen 2008-11-07 00:24:06 UTC
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)
Comment 9 Jens Petersen 2008-11-09 23:12:05 UTC
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;).
Comment 10 Bug Zapper 2008-11-26 02:28:17 UTC
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
Comment 11 Matthias Clasen 2009-01-17 02:22:05 UTC
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.
Comment 12 Jens Petersen 2009-01-19 09:20:57 UTC
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?
Comment 13 Akira TAGOH 2009-01-19 10:17:35 UTC
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?
Comment 14 Jens Petersen 2009-02-19 04:59:05 UTC
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.
Comment 15 Bug Zapper 2009-06-09 09:37:51 UTC
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
Comment 16 Akira TAGOH 2009-06-18 03:33:07 UTC
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.
Comment 17 Jens Petersen 2009-06-18 09:08:31 UTC
(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?
Comment 18 Matthias Clasen 2009-06-18 16:02:58 UTC
Can I suggest that we fix the underlying multilib problem instead of inventing all these complicated fallback schemes ?
Comment 19 Akira TAGOH 2009-06-19 00:53:57 UTC
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.
Comment 20 Jens Petersen 2009-06-19 01:12:38 UTC
I think your suggestions are good. :) Or any way to specify gtkimmodule per arch under XSETTINGS?
Comment 21 Matthias Clasen 2009-06-20 20:25:42 UTC
no, I am not going to turn on xim for everyone.
Comment 22 Jens Petersen 2009-06-21 23:09:59 UTC
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).
Comment 23 Akira TAGOH 2009-06-23 01:27:22 UTC
That sounds good to me :)
Comment 24 Jens Petersen 2009-12-02 06:15:11 UTC
Moving back to gtk2 based on comment 18 (and comment 22 perhaps). I will try to file an upstream bug too.
Comment 25 Jens Petersen 2009-12-02 06:37:31 UTC
Comment 26 Bug Zapper 2010-03-15 12:01:21 UTC
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
Comment 28 Parag Nemade 2010-09-02 14:38:57 UTC
Can we have any update here? I don't see anyone replied in upstream bug.
Comment 29 Jens Petersen 2011-06-02 05:57:17 UTC
Still see this in F15.
Comment 30 Bug Zapper 2011-06-02 18:29:48 UTC
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
Comment 31 Jens Petersen 2011-06-09 06:06:01 UTC
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 :)?
Comment 32 Akira TAGOH 2012-01-31 03:01:43 UTC
for gtk3, this issue was fixed in 3.3.3, also added this support to imsettings in 126.96.36.199. FYI