Bug 243563 - scim no longer gets started by xinit
scim no longer gets started by xinit
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Warren Togami
:
: 402681 (view as bug list)
Depends On: 250226
Blocks: 241630
  Show dependency treegraph
 
Reported: 2007-06-09 15:15 EDT by Sam Varshavchik
Modified: 2008-05-01 01:05 EDT (History)
7 users (show)

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


Attachments (Terms of Use)
Presentation of the problem for me (27.83 KB, image/png)
2007-06-20 09:00 EDT, Matěj Cepl
no flags Details
the screenshot as previous one but with LANG=C (23.45 KB, image/png)
2007-06-20 09:01 EDT, Matěj Cepl
no flags Details

  None (edit)
Description Sam Varshavchik 2007-06-09 15:15:47 EDT
Description of problem:

After upgrading to xinit, scim no longer gets started

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

1.0.2-19.fc7

How reproducible:

Always

Steps to Reproduce:
1. Upgrade FC6 English desktop, with scim, to FC7
2. Log in
  
Actual results:

scim no longer gets started

Expected results:

scim continues to work as in FC6

Additional info:

FC7's /etc/X11/xinit/xinitrc.d/xinput.sh, in FC7, reads:

    # FIXME: This hardcoded list has to be gone in the future.
    _language_list="as bn gu hi ja kn ko ml mr ne or pa si ta te th ur vi zh"

This _entire_ piece of logic needs to be scrapped. Just because I'm running
en_US.UTF-8 does not mean that I cannot use scim to compose E-mail, in
Thunderbird, in Chinese.
Comment 1 Matěj Cepl 2007-06-15 11:41:54 EDT
+1
Comment 2 Adam Jackson 2007-06-15 17:13:56 EDT
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.
Comment 3 Warren Togami 2007-06-15 17:28:41 EDT
How do you suggest we make it discoverable?
Comment 4 Warren Togami 2007-06-19 13:06:51 EDT
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?
Comment 5 Sam Varshavchik 2007-06-19 18:53:45 EDT
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.
Comment 6 Warren Togami 2007-06-19 22:24:53 EDT
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.
Comment 7 Jens Petersen 2007-06-19 23:53:04 EDT
(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.
Comment 8 Wesley Tanaka 2007-06-20 00:27:57 EDT
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.
Comment 9 Jens Petersen 2007-06-20 01:08:14 EDT
(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.
Comment 10 Wesley Tanaka 2007-06-20 06:29:09 EDT
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/*`"


Comment 11 Sam Varshavchik 2007-06-20 06:40:41 EDT
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.

Comment 12 Akira TAGOH 2007-06-20 08:17:30 EDT
(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.
 
Comment 13 Matěj Cepl 2007-06-20 09:00:23 EDT
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?
Comment 14 Matěj Cepl 2007-06-20 09:01:37 EDT
Created attachment 157458 [details]
the screenshot as previous one but with LANG=C

Sorry, this is probably more easy to parse.
Comment 15 Adam Jackson 2007-06-20 09:22:45 EDT
Help me out here.  Why would you _not_ want SCIM ?
Comment 16 Warren Togami 2007-06-20 13:46:38 EDT
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.
Comment 17 Warren Togami 2007-06-20 14:54:13 EDT
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.
Comment 18 Matěj Cepl 2007-06-20 16:52:47 EDT
(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?
Comment 19 Matěj Cepl 2007-06-20 16:54:21 EDT
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).
Comment 20 Jens Petersen 2007-06-20 21:17:21 EDT
(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.
Comment 21 Jens Petersen 2007-06-20 21:24:34 EDT
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.
Comment 22 Jens Petersen 2007-09-21 01:20:29 EDT
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.
Comment 23 Warren Togami 2007-09-21 13:15:36 EDT
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?
Comment 24 Jens Petersen 2007-09-21 21:26:22 EDT
(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. :)
Comment 25 Warren Togami 2007-09-22 16:04:54 EDT
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.
Comment 26 Akira TAGOH 2007-09-24 04:17:51 EDT
(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.
Comment 27 Jens Petersen 2007-09-25 02:20:57 EDT
(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.)
Comment 28 Jens Petersen 2008-01-21 02:48:05 EST
*** Bug 402681 has been marked as a duplicate of this bug. ***
Comment 29 Jens Petersen 2008-05-01 01:05:00 EDT
I am going to close this since I think there is general consensus that this is
the right thing now.

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