Description of problem: Though im-chooser can enable scim in en_US locale, and the scim tray icon appears, left clicking the icon brings nothing. Version-Release number of selected component (if applicable): scim-1.4.7-23.fc9.i386 How reproducible: Always Steps to Reproduce: 1. Log in in en_US locale 2. enable scim in im-chooser 3. try to start any IM in anyway Actual results: no way to start any IM at all Expected results: being able to pick up an IM, just like want it used to be in F8 Additional info: If I log in in a defaultly im-enabled locale, saying zh_CN, all the ims are available.
Created attachment 305511 [details] updated patch to gtk-scim
The default locale signature in scim-bridge is wrong. It seems that gtk 2.12.9 doesn't support "" ="*" in gtk/gtkimmodule.c:match_locale editting /etc/gtk-2.0/i686-pc-linux-gnu/gtk.immodules, replace the last "" with "*" can solve the problem.
Created attachment 305512 [details] patch to scim-bridge parellel with the previous patch. This one is of more significance since The default gtk im module in fedora is scim-bridge-gtk.
the best fix is to replace "ko:zh:ja" with "*" in the xim immodule's default languages. It should be a bug of GTK.
Erm, if the scim icon is in the notification area on the panel it means SCIM is working. The imsettings framework in F9 will override the immodules cache defaults. Could you please try again without your changes to gtk.immodules. It should work and works for me.
The scim icon is in the tray. But you can't activate any input methods. Test case: 1: gtk.immodules "/usr/lib/gtk-2.0/2.10.0/immodules/im-xim.so" "xim" "X Input Method" "gtk20" "/usr/share/locale" "ko:zh:ja" en_US locale For a new user never logged in with zh_CN locale, im-chooser fails. After logged in with zh_CN locale once, the user can log in with en_US locale and im-chooser can enable scim as the input layer. The scim tray icon appears in the tray, but in any gtk application, the user can not choose any input method from scim. After replacing ko:zh:ja with "*", scim works for all the newly launched applications. 2:gtk.immodules "/usr/lib/gtk-2.0/2.10.0/immodules/im-xim.so" "xim" "X Input Method" "gtk20" "/usr/share/locale" "*" After logged in with zh_CN locale once, the user can log in with en_US locale and im-chooser can enable scim as the input layer. The scim tray icon appears, and all the input methods become available. 3:gtk.immodules "/usr/lib/gtk-2.0/immodules/im-scim-bridge.so" "scim-bridge" "SCIM Bridge Input Method" "" "" "*" After logged in with zh_CN locale once, the user can log in with en_US locale and im-chooser can enable scim as the input layer. There will be two scim tray icons in the tray. From one of them, the input methods are available, where none is availible from the other. It implies that the one for xim is not working, but the one for scim-bridge-gtk is working. From the above 3 points, I suggest it is totally related to GTK but a fault of SCIM. However I failed to locate any related changes in GTK's svn.
I also suggest not to install scim-bridge and scim-bridge-gtk if scim can already work with the XIM framework.
I'm afraid the kind of this issue is totally out of focus on im-chooser. and I don't care since scim is certainly running. First, that default locales, "ko:zh:ja" in this case, is used to determine which immodule are better for current locale in general. but im-chooser(imsettings) doesn't rely on it to enable any immodules on demand. I'm wondering that patch really fixes your problem. since scim has supported more languages, it would be better fixing the default locales though. but it should be different topic for this issue anyway. The main issue here should be, SCIM doesn't set the trigger key to activate IM if it's running at the first time on en_US. which may be a reason of confusion. you could still change the IME from the scim icon at the systray though.
Testcase to reproduce: 1. ensure IM isn't running. $ imsettings-stop SCIM (choose Exit from the pop up menu at the scim icon as needed) 2. remove $HOME/.scim 3. run IM $ imsettings-start SCIM 4. open any GTK+ applications 5. press ctrl+space Nothing to happen 6. run scim-setup and see FrontEnd->Global Setup->Hotkeys Nothing
We turned off the hotkeys for non-Asian desktop by default since my people complained about Ctrl+Space conflicting with our applications. If you use the mouse to turn on your input method it should work. You can set a hotkey with scim-setup (configuration).
(In reply to comment #8) > I'm afraid the kind of this issue is totally out of focus on im-chooser. and I > don't care since scim is certainly running. > > First, that default locales, "ko:zh:ja" in this case, is used to determine which > immodule are better for current locale in general. but im-chooser(imsettings) If current locale is en, which is not in the list, match_locale will return a 0. If match_locale() returns a zero, the immodule is not initialized. Hence xim won't be loaded in en_US locale, no matter scim is launched or not. Then gtkimmodule.c will try to match against scim-bridge, which says "" in the default_locale field. again non of the three matching works, thus another 0 is returned; scim-bridge become defunct as well. OK now we end up with a perfectly working scim, enabled by the pretty im-chooser, and every GTK application without any immodule in a default setup generated by im-chooser in F9. This is how the IM framework breaks in en_US locale in F9. It used to be working in F8. > doesn't rely on it to enable any immodules on demand. im-chooser doesn't rely on immodules, yes, because im-chooser don't accept any inputs. > I'm wondering that patch > really fixes your problem. If you wonder, the following are typed on my F9 laptop with the XIM entry hack: 这是一段中文。 > since scim has supported more languages, it would be > better fixing the default locales though. but it should be different topic for > this issue anyway. I think gtk.immodules is shipped with GTK. If there is a workaround it should be in im-chooser. > > The main issue here should be, SCIM doesn't set the trigger key to activate IM > if it's running at the first time on en_US. which may be a reason of confusion. You completely lost the point. > you could still change the IME from the scim icon at the systray though. You get this point, but the main issue here is that no IME is listed in the tray if it is not "*". It makes sense to disable scim by default for non-asian users, but it doesn't make sense to give non-asian locale users a defunct scim after we enabled scim explicitly in im-chooser, saying as long as scim is launched, it is not a bug anymore. Anyway, it is not im-chooser's fault. I said again and again I suggest it is something related to GTK. I am no expert on the IM topic. I tried hard to locate where the problem is introduced since F8, but eventually I failed. If any of the experts here can locate it and file a bug at GTK(supposing it is a GTK problem), I will really really appreciate and thank him or her. If there is no way to locate the problem in GTK, a work-around provided in im-chooser will also be very helpful. It IS a regression from F8. In F8 there is no any special requirement except to launch the im-chooser and select scim, in order to enable asian input methods in en_US locale.
(In reply to comment #11) > If current locale is en, which is not in the list, match_locale will return a 0. > If match_locale() returns a zero, the immodule is not initialized. Hence xim > won't be loaded in en_US locale, no matter scim is launched or not. > Then gtkimmodule.c will try to match against scim-bridge, which says "" in the > default_locale field. again non of the three matching works, thus another 0 is > returned; scim-bridge become defunct as well. > > OK now we end up with a perfectly working scim, enabled by the pretty > im-chooser, and every GTK application without any immodule in a default setup > generated by im-chooser in F9. This is how the IM framework breaks in en_US > locale in F9. It used to be working in F8. I don't think you understand: imsettings overrides those settings. If you enable scim through im-chooser - it will be available to all gtk apps irrespective of the locale. We expect non-Asian desktop users to turn on SCIM with im-chooser. Why do you prefer to run in en_US.UTF-8? :) > > since scim has supported more languages, it would be > > better fixing the default locales though. but it should be different topic for > > this issue anyway. > I think gtk.immodules is shipped with GTK. If there is a workaround it should be > in im-chooser. We include scim on our Live image version of Fedora too and we cannot enable it for all locale by default. > > The main issue here should be, SCIM doesn't set the trigger key to activate IM > > if it's running at the first time on en_US. which may be a reason of confusion. > You completely lost the point. > > you could still change the IME from the scim icon at the systray though. > You get this point, but the main issue here is that no IME is listed in the tray > if it is not "*". > > It makes sense to disable scim by default for non-asian users, but it doesn't > make sense to give non-asian locale users a defunct scim after we enabled scim > explicitly in im-chooser, saying as long as scim is launched, it is not a bug > anymore. > > Anyway, it is not im-chooser's fault. I said again and again I suggest it is > something related to GTK. > > I am no expert on the IM topic. I tried hard to locate where the problem is > introduced since F8, but eventually I failed. If any of the experts here can > locate it and file a bug at GTK(supposing it is a GTK problem), I will really > really appreciate and thank him or her. If there is no way to locate the problem > in GTK, a work-around provided in im-chooser will also be very helpful. > > It IS a regression from F8. In F8 there is no any special requirement except to > launch the im-chooser and select scim, in order to enable asian input methods in > en_US locale. Did you try using the mouse? There is no regression if you update from F8 you would keep your hotkey. For new installations no hotkey is defined by default though. As I see it you are basically complaining that no hotkey is defined. The hotkey is controlled by SCIM so it is not a gtk issue.
I did try using the mouse. It doesn't work. I didn't upgrade from F8. I did a new installation while keeping my old /home directory. I am not that stupid to ignore how to define the hotkeys. I already have my own work-around on my own box. If the Fedora developers can't repeat the problem and don't confirm it as a bug, just close it then. None of us want to spend more time on the topic. I compared the source code related to XIM in gtk and there is no difference. I traced back in the ChangeLog of scim.spec since 1.4.7-7 (fc8 version), and there is nothing specially related: the scim.conf framework is adapted, several patches are removed and restored. Nothing matters. As far as I know in the F9 release notes it was mentioned that there is some newly introduced dynamic xim feature, but I don't want to read any more source code. ROOT, the holy crap from CERN is already driving me crazy these days. I picked up a wrong time to upgrade the OS. It doesn't make any sense to disable xim immodule in GTK according to the locale the user is using, and to ensure it completely unconfigurable. It sounds like another ROOT.
> I don't think you understand: imsettings overrides those settings. imsettings can't override those settings. They are hardcoded in GTK and files only writable by root. > If you enable scim through im-chooser - it will be available to all > gtk apps irrespective of the locale. scim is availble, no problem. But XIM - immodule(gtk/modules/imxim.c) in GTK is not availible for all languages, it is simply skipped by gtk/gtkimmodules.c on en_US locale). Thus it leaves an availible, defunct scim that can't input anything to any GTK applications. In F8 all the things are different, but all these works. I guess it is due to someone added something to conform with the specifications better by adding some locale filter in some of the component in XIM framework. > > We expect non-Asian desktop users to turn on SCIM with im-chooser. > > Why do you prefer to run in en_US.UTF-8? :) > Because I live in an en_US locale. > > We include scim on our Live image version of Fedora too and we cannot enable > it for all locale by default. But gtk's xim-immodule shall be enabled for all locale by default. Then it is up to the user to launch scim or not. Using a "*" in xim immodule's default locale doesn't stop match_locale working for other (more specific locales), because "*"'s ranking is 1, whereas others will be 2 or 3. > > Did you try using the mouse? Did YOU try using the mouse? (I'd rather say, did you ever try to create a new user, log in with en_US, remove ~/.xinputrc if it is there, and enable scim via im-chooser?) I got a core dump there(with the supposed-no-core-dump im-chooser(4th release) from koji), for the newly created root account by the clean installation.
Since you have a workaround, there may be nothing more to discuss here. but apparently you are being confused and misunderstanding the behavior how GTK+ determines the default immodule for current session. (In reply to comment #11) > If current locale is en, which is not in the list, match_locale will return a 0. > If match_locale() returns a zero, the immodule is not initialized. Hence xim > won't be loaded in en_US locale, no matter scim is launched or not. > Then gtkimmodule.c will try to match against scim-bridge, which says "" in the > default_locale field. again non of the three matching works, thus another 0 is > returned; scim-bridge become defunct as well. No, that's wrong. GTK+ is trying to load the immodule as the following order: 1. look at Gtk/IMModule in XSETTINGS, which im-chooser/imsettings is changing through GConf through gnome-settings-daemon through XSETTINGS. if there are, initialize that immodule. 2. try to look up GTK_IM_MODULE like GTK+ in the previous release did 3. if no Gtk/IMModule nor GTK_IM_MODULE is specified, try to look up gtk.immodules against current locale. The way of what you are saying is used at step 3. that's why we are saying your fix is irrelevant to fix this essentially. And as you reported initially, you could see the scim icon at the systray after you turned on SCIM from im-chooser, that means SCIM is surely certainly running. and as I said at comment #8, you can't turn on IM by ctrl+space, because of comment #9. > If you wonder, the following are typed on my F9 laptop with the XIM entry hack: > 这是一段中文。 That may be actually because of the side effect of another bug. we have to find a way out to disable IM entirely. as I said the above, GTK+ is currently trying to find out immodule /randomly/ according to current locale - it's really up to the order of gtk.immodules that unable to control except modifying by the hand - and since there are some requirements to keep a compatible with XKB, we can't set up the immodule to Simple in order to have similar behavior like disabling. > You get this point, but the main issue here is that no IME is listed in the tray > if it is not "*". Listing IME at the scim icon at the systray and what the default locales in immodule is, is totally irrelevant. (In reply to comment #14) > scim is availble, no problem. > But XIM - immodule(gtk/modules/imxim.c) in GTK is not availible for all > languages, it is simply skipped by gtk/gtkimmodules.c on en_US locale). > Thus it leaves an availible, defunct scim that can't input anything to any GTK > applications. You can use SCIM on GTK+ applications. so why do you need to use XIM then? :) > But gtk's xim-immodule shall be enabled for all locale by default. Then it is up > to the user to launch scim or not. Using a "*" in xim immodule's default locale > doesn't stop match_locale working for other (more specific locales), because > "*"'s ranking is 1, whereas others will be 2 or 3. I'm afraid we can't do that for im-xim.so unless we have the certain way of managing immodule for every users and for every needs. as I mentioned the above, there are various requirements to input something. and SCIM isn't capable for every needs. someone may not wants to have another process to input because they could do that with another immodule like im-cedilla.so and im-cyrillic-translit.so and so on. apart from that, since gtk.immodules are generated by gtk-query-immodules-* automatically, it doesn't ensure im-xim.so is being listed after such immodules so far. > I got a core dump there(with the supposed-no-core-dump im-chooser(4th release) > from koji), for the newly created root account by the clean installation. See Bug#445129. Updated package is available in the testing repo now.
For what it worth mentioning for another possibility for not working: imsettings currently only supports GNOME and Xfce. but not KDE or other desktop maybe. because there are nothing of XSETTINGS manager running or XSETTINGS manager doesn't support Gtk/IMModule key able to deliver the settings to GTK+. For GNOME, gnome-settings-daemon is capable to work as the manager, and xfce-mcs-manager for Xfce. FYI.
(In reply to comment #15) > Since you have a workaround, there may be nothing more to discuss here. but > apparently you are being confused and misunderstanding the behavior how GTK+ > determines the default immodule for current session. > > No, that's wrong. GTK+ is trying to load the immodule as the following order: > > 1. look at Gtk/IMModule in XSETTINGS, which im-chooser/imsettings is changing > through GConf through gnome-settings-daemon through XSETTINGS. if there are, > initialize that immodule. > 2. try to look up GTK_IM_MODULE like GTK+ in the previous release did > 3. if no Gtk/IMModule nor GTK_IM_MODULE is specified, try to look up > gtk.immodules against current locale. > > The way of what you are saying is used at step 3. that's why we are saying your > fix is irrelevant to fix this essentially. > And as you reported initially, you could see the scim icon at the systray after > you turned on SCIM from im-chooser, that means SCIM is surely certainly running. > and as I said at comment #8, you can't turn on IM by ctrl+space, because of > comment #9. > I don't bother not being able to turn on IM by ctrl+space. If I have to use step 3 of the story, it means the 1 and 2 are failing. If they fail, there must some reason. Following your hints I located the gconf key at: /desktop/gnome/interface/gtk-im-module On my box it is set as scim-bridge. If I have to use step 3 with xim, it means, scim-bridge doesn't work. Where can I find the XSETTINGS ? > That may be actually because of the side effect of another bug. we have to find > a way out to disable IM entirely. as I said the above, GTK+ is currently trying > to find out immodule /randomly/ according to current locale - it's really up to > the order of gtk.immodules that unable to control except modifying by the hand - > and since there are some requirements to keep a compatible with XKB, we can't > set up the immodule to Simple in order to have similar behavior like disabling. > If the "1" step can work reliably, it is good to disable the 3. > > Listing IME at the scim icon at the systray and what the default locales in > immodule is, is totally irrelevant. > No it is relevant. Try to list the input methods when it is inappropiate to type any text, eg, on a button. You get no list. The list is obviously context dependent. What I experienced is that even in a textbox, I get no list. It seems that on my computer every widget becomes un-inputable for scim. the only explanation is that all the three steps failed, and no im-module is loaded. My workaround was to use the 3 step, which is deprecated according to your argument. > > See Bug#445129. Updated package is available in the testing repo now. >
For a newly created user (no changes in gtk.modules), enabling ime by im-chooser works. No ime menu is availible in 'terminal'. (user logged in by fast user switching) If I start a program by, eg env LANG=zh_CN gedit, the ime menu is availible for that particular application. gconf: /desktop/gnome/interface/gtk-im-module = scim-bridge TAGOH, would you like to have a test on your F9 ?
(In reply to comment #17) > I don't bother not being able to turn on IM by ctrl+space. > If I have to use step 3 of the story, it means the 1 and 2 are failing. If they > fail, there must some reason. Following your hints I located the gconf key at: > /desktop/gnome/interface/gtk-im-module > > On my box it is set as scim-bridge. Since it all works for me on even en_US except the hothey issue as I mentioned earlier, this is my guess and assuming you're running on ix86 box, but not x86_64. As you said, the above GConf key is what gnome-settings-daemon reaches to deliver the settings through XSETTINGS. and if it has something that is valid immodule name, it may be unlikely to fail creating an instance of immodule. otherwise GTK+ won't fall back to the next step to find immodule out, but just keeps that instance for current session. i.e. GTK+ uses scim-bridge for you regardless of scim-bridge is really working. so it would be a good idea to check if it's really from XIM. you can just try it with XMODIFIERS=@im=none on the desktop environment where you may think you can input something through XIM. in that test case, if it's really from XIM, you won't be able to input anything at all from SCIM then. but you can do with XMODIFIERS=@im=SCIM. > If I have to use step 3 with xim, it means, scim-bridge doesn't work. > Where can I find the XSETTINGS ? Assuming you're running on GNOME, please make sure if gnome-settings-daemon is running. or for Xfce desktop, xfce-mcs-manager. otherwise it won't works so far. > If the "1" step can work reliably, it is good to disable the 3. Yes, and it's supposed to do so... > No it is relevant. Try to list the input methods when it is inappropiate to type > any text, eg, on a button. You get no list. The list is obviously context > dependent. What I experienced is that even in a textbox, I get no list. It seems > that on my computer every widget becomes un-inputable for scim. Sorry, you lost me. what the list are you talking about? the IME list could be popped up from the SCIM icon at the systray, won't be changed against the context. to make sure, you can find it out in the systray (notification area) applet on gnome-panel - where would be located at the top of panel and the left side of User Switcher applet for fresh install. (In reply to comment #18) > For a newly created user (no changes in gtk.modules), enabling ime by im-chooser > works. No ime menu is availible in 'terminal'. (user logged in by fast user > switching) Sorry, "No ime menu is available in 'terminal'" for "a newly created user" ? but it works what? Please check the following if you see SCIM not working: $ locale $ ps aux | grep scim $ ps aux | grep gnome-settings-daemon $ ls -l $HOME/.xinputrc Also, attaching your $HOME/.scim/config would be faster to investigate.
Finally I caught the bug. It is in the GTK I am using. When updating my .spec file I forgot to merge the Patch 4. im-modules.patch from the Fedora one. Take a look at the difference between my ~/rpmbuild/BUILD/gtk+-2.12.9/gdk/x11/gdksettings.c and http://svn.gnome.org/svn/gtk+/trunk/gdk/x11/gdksettings.c : --- gdksettings.c 2008-03-12 00:17:26.000000000 -0400 +++ gdksettings.c.trunk 2008-05-16 19:26:44.000000000 -0400 @@ -65,7 +65,12 @@ "Xft/RGBA\0" "gtk-xft-rgba\0" "Xft/DPI\0" "gtk-xft-dpi\0" "Net/FallbackIconTheme\0" "gtk-fallback-icon-theme\0" - "Gtk/TouchscreenMode\0" "gtk-touchscreen-mode\0"; + "Gtk/TouchscreenMode\0" "gtk-touchscreen-mode\0" + "Gtk/EnableAccels\0" "gtk-enable-accels\0" + "Gtk/EnableMnemonics\0" "gtk-enable-mnemonics\0" + "Gtk/ScrolledWindowPlacement\0" "gtk-scrolled-window-placement\0" + "Gtk/IMModule\0" "gtk-im-module\0"; + I'll rebuild my GTK package. It will be fine then. Sorry for troubling you so much, TAGOH.