...which is not what people expect.
We used to have a solution that made scim enabled only in certain locales. I think we need something like that back.
No changes has been made around this. imsettings is responsible to enable/disable input method though it's supposed to work on certain locales. can you give us more info like which locales did you see ibus enabled?
I suspect this might be related to http://bugzilla.gnome.org/show_bug.cgi?id=567124 ?
Even after turning off IM in im-chooser - input method is still enabled in next session.
I can reproduce easily in en_US.UTF-8 for F11Beta and current rawhide.
Moving to gtk2.
Please use `gnome-session-properties` check if you make ibus autostart during session startup?
I only see imsettings-start and imsettings-applet (both on and I guess at least the former is needed).
If I log into a fresh account, in the en_US locale, I see none.conf being sourced, so the locale filtering in /etc/X11/xinit/xinitrc.d/50-xinput.sh seems to be working. But still, something sets the gconf key /desktop/gnome/interface/gtk-im-module to 'ibus', and the ibus statusicon is visible.
And we are still running 6 (!) processes in an en_US session for undesired IM support:
No wonder our login time is never getting any better...
None of this is GTK+s fault.
Sorry, this was my fault since imsettings stops to bring IM process up in X session but in the desktop session. /etc/xdg/autostart/imsettings-start.desktop brings it up anyway because imsettings-start doesn't look at $IMSETTINGS_MODULE that is used to determine which IM would be preferred for current session.
*** Bug 493698 has been marked as a duplicate of this bug. ***
Fixed in imsettings-0.106.2-1.fc11.
Putting this on the preview blocker and marking with needsretesting to make sure it's fixed.
I can confirm that is this fixed in current rawhide but would also appreciate a final signoff by Fedora QA or releng.
Confirmed - works as expected when switching between (e.g.) en_US and ja_JP.