Bug 493406

Summary:	ibus is turned on by default for all locales
Product:	[Fedora] Fedora	Reporter:	Matthias Clasen <mclasen>
Component:	imsettings	Assignee:	Akira TAGOH <tagoh>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	dcantrell, i18n-bugs, mclasen, petersen, phuang, tagoh, wtogami, wwoods
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	NEEDSRETESTING
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-04-23 21:17:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	476775, 481098

Description Matthias Clasen 2009-04-01 16:45:13 UTC

...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.

Comment 1 Akira TAGOH 2009-04-02 05:46:50 UTC

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 ?

Comment 2 Jens Petersen 2009-04-02 09:06:42 UTC

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.

Comment 3 Peng Huang 2009-04-02 10:42:59 UTC

Hi Jens,
Please use `gnome-session-properties` check if you make ibus autostart during session startup?

Comment 4 Jens Petersen 2009-04-02 13:33:17 UTC

I only see imsettings-start and imsettings-applet (both on and I guess at least the former is needed).

Comment 5 Matthias Clasen 2009-04-05 03:57:44 UTC

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:

imsettings-applet
/usr/libexec/im-settings-daemon
/usr/bin/ibus-daemon --xim
/usr/libexec/gconf-im-settings-daemon
/usr/libexec/ibus-gconf
/usr/libexec/ibus-x11 --kill-daemon

No wonder our login time is never getting any better...

None of this is GTK+s fault.

Comment 6 Akira TAGOH 2009-04-06 03:07:52 UTC

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.

Comment 7 Akira TAGOH 2009-04-06 07:37:55 UTC

*** Bug 493698 has been marked as a duplicate of this bug. ***

Comment 8 Akira TAGOH 2009-04-07 12:30:06 UTC

Fixed in imsettings-0.106.2-1.fc11.

Comment 9 Jesse Keating 2009-04-16 18:54:58 UTC

Putting this on the preview blocker and marking with needsretesting to make sure it's fixed.

Comment 10 Jens Petersen 2009-04-17 06:29:36 UTC

I can confirm that is this fixed in current rawhide but would also appreciate a final signoff by Fedora QA or releng.

Comment 11 Will Woods 2009-04-23 21:17:45 UTC

Confirmed - works as expected when switching between (e.g.) en_US and ja_JP.