GNOME Bugzilla – Bug 603559
gtk should handle missing immodules better
Last modified: 2012-01-31 02:59:21 UTC
In multilib systems it can happen easily that a third-party immodule is installed for one arch but not the other say. In this case what should gtk do? The current behaviour looks undetermined or fragile at best with apps potentially having startup delays etc. One approach that might help with this might be to allow GTK_IM_MODULE to hold a colon separated list of immodules to fallback too, and would also allow distro to handle fallbacks in a more painless way. FWIW Qt has done fallback to its default XIM immodule smoothly for a long time. See also https://bugzilla.redhat.com/show_bug.cgi?id=452938 for a bit more earlier discussion.
Created attachment 158779 [details] [review] proposed patch
ping?
Jens, can you please confirm if the patch fixes your issue ?
The patch still applies to recent gtk2 and gtk3 releases. I tested on gtk3-3.1.8 with GTK_IM_MODULE=gtk:xim and it doesn't seem to work for me unfortunately. I could be missing something? Akira, could you also try testing?
GTK_IM_MODULE=scim:xim (with no scim installed) works though.
Created attachment 193297 [details] [review] revised patch tested for all the above case and works fine.
Patch makes sense to me. Can we get this in?
Review of attachment 193297 [details] [review]: I don't think this is an improvement to the user experience, really. Randomly switching between scim and xim is just as much of a failure as randomly switching between ibus and simple. The proper fix is to standardize on one im framework, and really integrate it as a mandatory component of the desktop. That being said, this patch looks harmless enough. You need to update the documentation to reflect the new syntax, though, in two places: - the GtkSettings:gtk-im-module docs in gtk/gtksettings.c - the GTK_IM_MODULE docs in docs/reference/gtk/running.sgml
Created attachment 200324 [details] [review] take 2 Thanks for reviewing. added an attach to update the doc. FWIW this is the multilib issue and not relevant to the desktop integration. I still think this would be reasonable solution so far because no one propose anything else; IMHO the above suggestion will still fails unless we get rid of the immodule mechanism, because even if standardizing IM and integrating into the desktop, this issue is still persist if one forgets to install either of 32bit/64bit binary for immodule, because the way to determine the fallback on current implementation is unreliable. The cache file like gtk.immodules and immodules.cache considered harmful because the order of the list is really important and hardly affects to the fallback though, it's uncontrollable really, anyway. I want to see any reliable method to determine the default IM on GTK+.
Review of attachment 200324 [details] [review]: Looks ok
(In reply to comment #10) > Created an attachment (id=200324) [details] [review] > take 2 > > Thanks for reviewing. added an attach to update the doc. > > FWIW this is the multilib issue and not relevant to the desktop integration. I > still think this would be reasonable solution so far because no one propose > anything else; IMHO the above suggestion will still fails unless we get rid of > the immodule mechanism, because even if standardizing IM and integrating into > the desktop, this issue is still persist if one forgets to install either of > 32bit/64bit binary for immodule, because the way to determine the fallback on > current implementation is unreliable. Sure, multilib is a whole another level of failure... but 'integration' will also mean to arrange things so that it is damn well impossible to 'forget to install either'.
The following fix has been pushed: 4d7e47d Allow fallback for input method modules
Created attachment 200740 [details] [review] Allow fallback for input method modules Accept a :-separated list of module names in GTK_IM_MODULE and the corresponding setting, to deal a bit better with broken situations.
*** Bug 528708 has been marked as a duplicate of this bug. ***