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