Bug 446674 - GTK 2.12.9 doesn't support changing the IM via XSETTINGS.
GTK 2.12.9 doesn't support changing the IM via XSETTINGS.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gtk+ (Show other bugs)
9
All Linux
low Severity high
: ---
: ---
Assigned To: Peng Huang
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-15 12:33 EDT by Feng Yu
Modified: 2008-05-16 19:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-16 01:14:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
updated patch to gtk-scim (704 bytes, patch)
2008-05-15 13:32 EDT, Feng Yu
no flags Details | Diff
patch to scim-bridge (369 bytes, patch)
2008-05-15 13:34 EDT, Feng Yu
no flags Details | Diff

  None (edit)
Description Feng Yu 2008-05-15 12:33:05 EDT
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.
Comment 1 Feng Yu 2008-05-15 13:32:21 EDT
Created attachment 305511 [details]
updated patch to gtk-scim
Comment 2 Feng Yu 2008-05-15 13:32:56 EDT
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.

Comment 3 Feng Yu 2008-05-15 13:34:16 EDT
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.
Comment 4 Feng Yu 2008-05-15 17:05:48 EDT
the best fix is to replace "ko:zh:ja" with "*" in the xim immodule's default
languages. It should be a bug of GTK.
Comment 5 Jens Petersen 2008-05-15 19:44:23 EDT
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.
Comment 6 Feng Yu 2008-05-15 21:08:51 EDT
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.
Comment 7 Feng Yu 2008-05-15 21:09:58 EDT
I also suggest not to install scim-bridge and scim-bridge-gtk if scim can
already work with the XIM framework.
Comment 8 Akira TAGOH 2008-05-15 22:25:06 EDT
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.
Comment 9 Akira TAGOH 2008-05-15 22:30:06 EDT
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
Comment 10 Jens Petersen 2008-05-15 22:51:13 EDT
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).
Comment 11 Feng Yu 2008-05-16 00:23:30 EDT
(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.
Comment 12 Jens Petersen 2008-05-16 00:56:59 EDT
(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.
Comment 13 Feng Yu 2008-05-16 01:14:03 EDT
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.



Comment 14 Feng Yu 2008-05-16 01:29:56 EDT
> 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.
Comment 15 Akira TAGOH 2008-05-16 02:57:26 EDT
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.
Comment 16 Akira TAGOH 2008-05-16 03:15:06 EDT
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.
Comment 17 Feng Yu 2008-05-16 10:33:40 EDT
(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.
> 

Comment 18 Feng Yu 2008-05-16 10:45:20 EDT
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 ?
Comment 19 Akira TAGOH 2008-05-16 14:25:48 EDT
(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.
Comment 20 Feng Yu 2008-05-16 19:35:28 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.