GNOME Bugzilla – Bug 58201
XIM backend should be loaded in all locales
Last modified: 2011-02-04 16:16:03 UTC
XIM backend is expected to use in Asian locales on Solaris, but actually is not in any korean, simplified or traiditional chinese locales while used in all japanese "ja", "ja_JP.PCK".
Changing default locales from "ja" to "ja:ko:zh" in gtk.immodules file makes gtk-xim module used in korean and chinese locales as well, but the gtk-xim should be tried in all locales, at least on Solaris. I wonder listing all locale names for gtk-xim would be right and best solution. Instead, can we define a default input method for all locales? For instance, "all" for default locales can be a special case to make the input method the default ?
Created attachment 816 [details] [review] make 'all' a keyword to use the input method for all locales
Loading XIM backend for all locales is certainly not correct for many systems, and most users. On XFree86, for instance: a) Has many more features than the generic input module (such as direct Unicode input) b) Is vastly more efficient than loading a huge compose table for startup time and memory usage. (In fact, XFree86 doesnt' even ship a UTF-8 compose table. Support a "all locales" element probably makes sense, but to correspond to Pango usage it shoudl be "*" not "ALL".
I understand loading XIM for all may not be correct on other systems, but would like to do so on Solaris. A new patch to use "*" for all locales and use "*" for XIM on Solaris(#ifdef sun) is being attached shortly.
Created attachment 818 [details] [review] use "*" for all locales in gtk.immodules
Is the patch posted at 07/30/01 20:48 okay to commit?
I'd like to hear from you about the status of this bug. Using '*' for all locales is okay? Or, do you want regular expression be used here? Please let me know if there is anything I can help.
Go ahead and commit the "*" change. I don't like the #ifdef sun; basically policy should never be #ifdef'ed. And we'll probably get someone trying to compile GTK+-2.0 on SunOS 4 someday (or at least on Solaris 2.5 or whatever, SunOS 4 seems to have almost vanished now.) What we would do for Red Hat would be to maintain a local pathc in the src RPM that changed that line of code. If that's too ugly, or doesn't fit with the way you work, an alterantive would be a configure option like: ./configure --with-xim-locales="*"
Thanks, I'm going to commit gtkimmodule.c change for "*". For the other problem, --with-xim-locales="*" would be used for Solaris build if available, but in general, do we also want to create as many configure options as the number of im modules, like ./configure --with-thaiim-locales="en_US.UTF-8,th_TH" ?
I spoke with Laca(Laszlo Peter) about platform specific configuration like this, and we'd prefer to make some change in CVS rather than applying a local patch. For example, can we change 'make install' in gtk+ so that it should install the right gtk.immodules for the platform? If it is possible approach, we also want 'gtkrc' for the platform to be installed by 'make install'.
For now, you probably want to have your desktop startup script export GTK_IM_MODULE=xim. Making installation do platform-specific configuration is something we haven't done before and could get pretty complex and we could end up with huge sets of platform specific configuration data in the GTK+ distribution.
Moving input method related bugs to input-methods component
shall we close this "wont fix"?
I'm going to close this - using GTK_IM_MODULE=xim is a good workaround, and we expect the needs of XIM backend will be less and less by increaing number of other input methods backends.