Bug 444814 - Amharaic defaults to native input
Amharaic defaults to native input
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gtk2 (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Target
  Show dependency treegraph
 
Reported: 2008-04-30 15:01 EDT by Bill Nottingham
Modified: 2014-03-16 23:14 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-29 22:57:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mclasen: fedora_requires_release_note+


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2008-04-30 15:01:30 EDT
Description of problem:

Boot the livecd.

Choose Amharaic (Ethiopia) from the locale dialog.

You end up in a mode where:
- the scim chooser applet isn't visible
- attempting to type in anything gives you ethiopic characters

According to im-chooser (when run via prefs), there is not an input method
enabled. Enabling it appears to clean things up.

Version-Release number of selected component (if applicable):

rawhide 20080430 livecd
Comment 1 Jens Petersen 2008-05-01 04:24:18 EDT
Why should scim be running for Amharaic?  Is it?

Reproducible on my rawhide testbox without scim installed.
Only seems to happen for gtk apps.

Comment 2 Jens Petersen 2008-05-01 04:26:13 EDT
gtk.immodules enables the im-am-et.so input method by default for am locale.
Comment 3 Matthias Clasen 2008-05-01 10:35:47 EDT
I guess the situation is the same for all the immodules that claim the default
for some language.

So, what is the intended behaviour that we want here ? Should we patch gtk to
make none of the input modules the default for the languages they support ?
Comment 4 Jens Petersen 2008-05-01 18:57:46 EDT
I don't think this is a regression, right - I guess it has been like this "forever".
So removing from the F9Blocker list.

I tempted to reassign this to Tagoh, since I think he has some plans to make changes
related to this kind of default IM behaviour hopefully for F10.
Comment 5 Akira TAGOH 2008-05-02 08:26:14 EDT
This is a bit different to what I'm thinking of the situation. of course I'm
aware of this and my opinion is opposite of this claim, because:

1. that's hard to keep the consistency among the toolkits for the kind of the
toolkit specific Input Method in im-chooser.
2. making none of the immodule breaks the usability for people who wants to use
immodules like this and which to keep the compatibility with XKB thing like
im-cedilla.so.

I'd rather like to have IM Engines in scim for other languages to meet the above
term. that would makes people happier to provide the certain compatibility for
their experience among all the applications.
Comment 6 Bug Zapper 2008-05-14 06:26:22 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Tony Fu 2008-09-09 23:15:28 EDT
requested by Jens Petersen (#27995)
Comment 8 Bug Zapper 2008-11-25 21:14:36 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Matthias Clasen 2009-01-16 21:19:21 EST
I guess one way to fix this would be to split the gtk im modules off from the main gtk package, either as a single -immodules package, or if you want to be more finegrained, one subpackage per module. Then we can put those subpackages in the corresponding language support groups, and not install them by default.
Comment 10 Jens Petersen 2009-01-19 04:24:48 EST
Yeah sounds reasonable (or gtk2-extra-immodules).
Comment 11 Matthias Clasen 2009-01-29 22:57:34 EST
I've now split the im modules off into a gtk2-immodules subpackage
Comment 12 Matthias Clasen 2009-02-06 12:43:49 EST
This should get mentioned in the F11 release notes, in the Internationalization section:

The 'native' input method modules that used to be shipped with gtk2 have been
moved to a separate gtk2-immodules package. If you've previously used 'native' GTK+ input methods, e.g. by setting the GTK_IM_MODULE environment variable, or by relying on GTK+ picking an input method based on the locale, you may have to install the gtk2-immodules package. Users of the default input method framework (scim/ibus) are not affected by this change.

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