Bug 243563

+1

Warren, you changed this in xorg-x11-xinit 1.0.2-19, as per bug #237054.  The
comment was that users should use im-chooser to select input method, which is a
reasonable solution, but is clearly not sufficiently discoverable.

How do you suggest we make it discoverable?

I thought a little more about this.  I understand that people are surprised by
this new F-7 behavior.  But I am convinced that this is the *correct* behavior,
and the way we had it prior was incorrect.

http://togami.com/~warren/archive/2007/im-chooser-design.jpg
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236974
Part #3 of the solution was not implemented yet, which would make the interface
of im-chooser more obvious.

This is the correct behavior, because it behaves as expected for COMMON
expectations.
- English (or other non-IM) languages don't have IM by default.
- IM languages have IM by default.

For uncommon cases, you explicitly choose something else.  This is no less
difficult than enabling IM on Windows or Mac.
- System > Preferences > Input Method if you want to enable or choose a
different IM.

For this reason, I recommend closing this NOTABUG.  Any comments?

Well, when "Part 3", _is_ implemented, and would allow me to run scim on en_US,
maybe then it's the time to disable automatic launch of scim, at startup. But
until that happens, it is certainly a bug.

It makes no sense to me to blanketly disable a feature, that worked before, with
no warning. Just because there might be a better alternative at some time in the
future. I just do not follow this logic.

Right now, if someone doesn't want scim, they just won't install it. That's the
current way to choose whether or not you want to use it: you do or do not
install it. It may not be ideal, but it works.

Perhaps there's some other part of gnome, or other core package that has scim
now listed as a prerequisite, and that was the driving reason for this change:
to avoid having scim get in the way of people who don't need it, but who must
now have it installed as a part of their desktop. If so, then this should be
filed as a bug against the other package. scim should not be a required desktop
component right now, and the other package needs to be refactored to make scim
dependency optional.

im-chooser *already* does let you enable scim fairly easily, only the wording
isn't obvious.  Part 3 is only an improvement to the interface.

A further improvement would be im-chooser allowing you to install SCIM and your
choice of language support via pirut in a convenient way.

However, I have to disagree that disabling it by default in languages that don't
normally need it is bad.  I agree that it is not fun for the extreme minority of
users who depended on the old behavior, but this new behavior is correct and no
more difficult than Windows or Mac.

(In reply to comment #5)
> It makes no sense to me to blanketly disable a feature, that worked before,
> with no warning. Just because there might be a better alternative at some time
> in the future. I just do not follow this logic.

I agree with this.  And I am not convinced that it only affects
"the extreme minority of users".  I have heard quite a number of
complaints about this already.

> Right now, if someone doesn't want scim, they just won't install it. That's
> the current way to choose whether or not you want to use it: you do or do not
> install it. It may not be ideal, but it works.

Yes, I too feel the new behaviour is a regression relative to FC6.

> Perhaps there's some other part of gnome, or other core package that has scim
> now listed as a prerequisite, and that was the driving reason for this change:
> to avoid having scim get in the way of people who don't need it, but who must
> now have it installed as a part of their desktop. If so, then this should be
> filed as a bug against the other package. scim should not be a required
> desktop component right now, and the other package needs to be refactored to
> make scim dependency optional.

Yes it was basically done to workaround the problem that yum package groups
work badly when the same package appears in several package groups
(eg scim core packages) and so scim got installed by default in F7.
I filed bug 244954 earlier today which summarises the problem.

IMHO the current solution is only really right for the LiveCD, which is
a lesser usage-case.

I am planning to add scim meta packages to F8 so that scim doesn't
need to be installed by default again.

I seem to remember there used to be links in /etc/alternatives to change the
system default IME on a per-locale basis.  I still have various symlinks like
/etc/alternatives/xinput-zh_CN lying around back from the days before SCIM was
included in fedora.

Wouldn't it make sense to do something like that?

A clean install of Fedora could include symlinks like:

/etc/alternatives/xinput -> no_ime.conf
/etc/alternatives/xinput-as -> scim.conf
/etc/alternatives/xinput-bn -> scim.conf
...
/etc/alternatives/xinput-zh -> scim.conf

and the load order would be:

use ~/.xinputrc if it exsts,
otherwise use the most specific link in alternatives that matches the current
locale.


im-chooser would still need to be fixed, but would read in the list of system
defaults from /etc/alternatives.

(In reply to comment #8)
> I seem to remember there used to be links in /etc/alternatives to change the
> system default IME on a per-locale basis.  I still have various symlinks like
> /etc/alternatives/xinput-zh_CN lying around back from the days before SCIM was
> included in fedora.

Yes we did, but then we realised that it was really over-engineered,
and did not really give us any real gain over just a single xinputrc file.
So we moved to that in FC6 IIRC.  Though XIM clients that are restricted
to a specific locale still make use of locale specific configuration I think.

Also input method usage is real a user desktop choice,
leaving it to system configuration was found to be less useful.

> use ~/.xinputrc if it exists,
> otherwise use the most specific link in alternatives that matches the current
> locale.

Perhaps making xinput.sh user configurable would satisfy you? :)

If users still need to run im-chooser anyway by default to enable IM
I don't really see how adding those alternatives back really helps.

There are obviously two camps here, the camp that wants SCIM to run by default
in some particular locale without users having to run im-chooser, and the camp
that thinks that SCIM should not run by default in certain locales in order to
simplify things.

Some method to modify the system defaults, along with a default configuration
put into place at install time would satisfy both camps.

The /etc/alternatives mechanism provided that.  So would any other way of making
xinput.sh administrator-configurable that was more robust against package
upgrades than "edit the hardcoded list of locales in the file"

I suggested /etc/alternatives because I thought it was the way of doing things
like this.  But if the concern here is overengineering, then something as simple
and underengineered as changing the line assigning _language_list to read the
list in from some other place would satisfy all the stakeholders here.

conceptually, something like:

33c33
<     _language_list="as bn gu hi ja kn ko ml mr ne or pa si ta te th ur vi zh"
---
>     _language_list="`cat /etc/X11/xinit/locales.d/*`"

It's not just mere starting of scim, additionally some environment variable(s)
must be initialized in order to activate an IME -- such as GTK_IM_MODULE. I
haven't yet checked whether the existing im-chooser does that, or not.

(In reply to comment #10)
> xinput.sh administrator-configurable that was more robust against package
> upgrades than "edit the hardcoded list of locales in the file"

Well, note that the hardcoded list was quite ad hoc way and was a popcorn
workaround for the groupremove issue. we could have much better idea if we could
find that issue earlier. we don't want to keep that there in the future.

> I suggested /etc/alternatives because I thought it was the way of doing things
> like this.  But if the concern here is overengineering, then something as simple
> and underengineered as changing the line assigning _language_list to read the
> list in from some other place would satisfy all the stakeholders here.
> 
> conceptually, something like:
> 
> 33c33
> <     _language_list="as bn gu hi ja kn ko ml mr ne or pa si ta te th ur vi zh"
> ---
> >     _language_list="`cat /etc/X11/xinit/locales.d/*`"

So I'd disagree with this idea. and it doesn't necessarily helps people who
wants to have another IM. managing those files per IM is too complicated. we
should try to find another way rather than changing around xinput.sh.

(In reply to comment #11)
> It's not just mere starting of scim, additionally some environment variable(s)
> must be initialized in order to activate an IME -- such as GTK_IM_MODULE. I
> haven't yet checked whether the existing im-chooser does that, or not.

It's not responsible for im-chooser. im-chooser is just to choose one of IM
config files that is came from the IM packages. and xinput.sh actually
initializes them according to the IM config file when X is bringing up.
 

Created attachment 157457 [details]
Presentation of the problem for me

(In reply to comment #2)
> Warren, you changed this in xorg-x11-xinit 1.0.2-19, as per bug #237054.  The

> comment was that users should use im-chooser to select input method, which is

> a reasonable solution, but is clearly not sufficiently discoverable.

Except they cannot -- when I try to run im-chooser I have choice between No IM
and default (i.e., no IM). See attached screenshot. My locale is cs_CZ, so in
your division of the world I don't need any IM, but the reality is that I
CANNOT have any IM (unless manually editing configuration files in /etc/X11 and
even there is not clear documentation what should I do).

My problem is that without any IM (not even XIM) I have no [Compose] key
working at all (and I like my curly quotes and em-dashes). Should I file a
separate bug for this?

Created attachment 157458 [details]
the screenshot as previous one but with LANG=C

Sorry, this is probably more easy to parse.

Help me out here.  Why would you _not_ want SCIM ?

Matej, you are only confused because the im-chooser interface was not updated. 
If you want to enable SCIM you need to choose "Custom", which is confusing but
it DOES work right now.

It seems that we need a more comprehensive redesign than just simply clarifying
im-chooser.

Proposal: Meeting to Design IM Install/Configuration/Activation Strategy
========================================================================
There seem to be multiple issues here with nobody entirely happy with the series
of compromises and hacks that we currently rely upon.  I propose that we hold
meetings to discuss the overall design of IM activation and configuration on
Fedora.  We must put together a big-picture overall design

Possible topics could include:
- What should be configured and how? (avoid removal breakage issue)
- What should be installed and how?
- Default behavior on different LANG desktops?
- .d directory for drop-in language support definitions?
- Tagoh's theoretical DBus IM design (i.e. start SCIM without re-login)

https://www.redhat.com/mailman/listinfo/fedora-i18n-list
Meeting agendas and post-meeting summaries are to be posted here.  Details that
are too complex to be discussed during meetings should be discussed in mailing
list threads.  Meetings are to be held on irc.freenode.net channel #fedora-i18n.

How do people feel about this?  Let us take this discussion to fedora-i18n-list,
put together an initial meeting agenda, and schedule a meeting.

(In reply to comment #16)
> It seems that we need a more comprehensive redesign than just simply clarifying
> im-chooser.

That's true, but also shouldn't we just hard Require scim for all Gnome/Xorg/???
(I am not sure on which leve) desktops?

s/leve/level

Meaning: it shouldn't hurt anybody (we have so much useless junk already loaded
;-)) and it could help a lot of people (my example shows, that not just Asian
guys would love to use it).

(In reply to comment #15)
> Help me out here.  Why would you _not_ want SCIM ?

Well if you don't want to input Asian languages like Chinese, Indic, Japanese,
or Korean then you probably don't need SCIM installed.

Warren, I agree having Fedora I18n meetings is a good idea and we should
certainly do that.  We already have a number of ideas of how to improve
things considerably in Fedora 8 but it would certainly be valuable to
discuss it in the Fedora community.

I will send a proposal to fedora-i18n-list and see if we can agree on
a time and date.

I think if we backport the scim xinput tests from F8 that check whether
any usable IMEs are installed we could turn on IM by default again in
F7 xinput.sh.

Hmm... 
1) SCIM installed by default on English.
2) But not SCIM languages...
3) If SCIM languages... then SCIM by default.

This might be acceptable, although what would this be called in the Input Method
dialog?

(2) would be the same as if scim is not installed (ie corresponds to none.conf
in im-chooeser).

Anyway I suggest waiting to do this until after F8 is released,
since the new stuff needs a bit more testing. :)

Perhaps the Input Method dialog could say "None Available" and offer a button to
install them, with a pirut-like chooser limited to the language groups.  This
would be a nice addition to F9.

(In reply to comment #25)
> Perhaps the Input Method dialog could say "None Available" and offer a button to
> install them, with a pirut-like chooser limited to the language groups.  This
> would be a nice addition to F9.

im-chooser displays the kind of message now without offering the IM installation
if no IM is available. it sounds nice. but how to determine which IM is offered?
I'd say in advance I don't like having the hardcoded package name in im-chooser say.

(In reply to comment #25)
> offer a button to install them, with a pirut-like chooser limited to the
language groups.

Sounds like a nice idea - dunno if pirut can do that yet, but feel
free to file an rfe at least.  (For system-config-language we now offer
to install the language support package group for the new system language.)

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

I am going to close this since I think there is general consensus that this is
the right thing now.