|Summary:||should start IM by default on desktop|
|Product:||[Fedora] Fedora||Reporter:||Jens Petersen <petersen>|
|Component:||imsettings||Assignee:||Akira TAGOH <tagoh>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||i18n-bugs, katzj, pnemade, tagoh, triage|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-06-24 09:17:11 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Jens Petersen 2007-07-31 05:44:16 UTC
Description of problem: Current xinput.sh only starts IM for desktop in CIJK locale. This is pretty confusing for Western users who install scim but don't understand when it does not start, and also Eastern users who prefer to run their desktop in English. How reproducible: every time Steps to Reproduce: 1. groupinstall language support for some Asian lang 2. start desktop in English Actual results: SCIM is not started. Expected results: SCIM to start. Additional info: SCIM was started by default in FC6 and it seemed to make everyone happy.
Comment 1 Jens Petersen 2007-07-31 05:57:58 UTC
We could not start SCIM though say if no IME's (or m17n input maps) are installed though, but that could be done in the scim xinput file.
Comment 2 Akira TAGOH 2007-09-14 10:49:47 UTC
Just for updates, do we need to think about Live CD issue separately? the issue is a bit inconsistent between them.
Comment 3 Akira TAGOH 2007-09-21 14:56:53 UTC
should be fixed in 0.5.2-2.fc8.
Comment 4 Jeremy Katz 2007-09-22 14:02:47 UTC
Except that your fix is specific to when the live CD is running. Which means that once a user has installed off of the live CD, they fall back to the behavior of having scim starting and confusing them if they're the normal, non-CJKI case.
Comment 5 Akira TAGOH 2007-09-24 01:32:10 UTC
(In reply to comment #4) > Except that your fix is specific to when the live CD is running. Which means > that once a user has installed off of the live CD, they fall back to the > behavior of having scim starting and confusing them if they're the normal, > non-CJKI case. Indeed, you're right. I don't have any good idea for that so far. we need to think about it more then. and even not sure if we shouldn't get rid of the hardcoded list until we have any solution for that too. Any comments?
Comment 6 Jeremy Katz 2007-09-24 14:32:44 UTC
I thought we had come to a pretty good conclusion before F7 where the _default_ case would be that it would be we only run with the hard-coded list (well, it would be nice to have the list be able to grow based on something dynamic giving the languages which have a reasonable input method, but that's really a side note). Then, if you're running with a locale that _isn't_ one of those locales, you have to say you want it. The use case specified in the first comment here is so out of the normal that optimizing it ends up hurting the other 99% of users :(
Comment 7 Akira TAGOH 2007-09-24 23:51:33 UTC
We did. however in fact we got so many compliant against it, because they usually were required to just install the package to use in F6 or before. at this point, it could say an regression bug. and it should be an issue that we can't kiss off at this moment IMHO.
Comment 8 Jens Petersen 2007-09-25 00:29:42 UTC
Frankly I would almost rather remove SCIM by default from the LiveCD than keep the terrible hard-coded list in xinput.sh. I feel there must be a better solution, there must be some way to get the installation via livecd to do the Right Thing?
Comment 9 Jens Petersen 2007-09-25 03:39:34 UTC
I wonder if it would make sense to do a i18n livecd spin? That would certainly help solve this problem until we have a better solution on the desktop.
Comment 10 Jeremy Katz 2007-09-25 14:43:30 UTC
(In reply to comment #7) > We did. however in fact we got so many compliant against it, because they > usually were required to just install the package to use in F6 or before. at > this point, it could say an regression bug. and it should be an issue that we > can't kiss off at this moment IMHO. Just because something is changed doesn't mean it's wrong or bad. There were also lots of complaints when we went to UTF-8 by default from people saying that it was a regression. That didn't mean that we stood down and stuck with legacy encodings. (In reply to comment #9) > I wonder if it would make sense to do a i18n livecd spin? > That would certainly help solve this problem until we have > a better solution on the desktop. No, this is missing the point entirely. One of the goals of the live CD is to showcase the areas that Fedora excels in. One of which is our support for lots of locales. If you have to go and download another live CD to see that, then we've lost.
Comment 11 Jens Petersen 2007-09-26 01:06:50 UTC
> Just because something is changed doesn't mean it's wrong or bad. There were > also lots of complaints when we went to UTF-8 by default from people saying > that it was a regression. That didn't mean that we stood down and stuck with > legacy encodings. For utf-8 we had general agreement within engineering at least afaicr... :) I don't like it, but if we have to have the same behaviour for live and normal installs then I guess we have to keep the hardlist for now. :-/ Otherwise maybe we could do an additional hack to make the hardlist also apply to live installs. For F9 we want to do something like a dialog the first time a user starts a desktop session asking if s/he wants to use the installed input methods, or at least allow users to control input methods more dynamically on the desktop.
Comment 12 Jeremy Katz 2007-09-26 01:55:56 UTC
(In reply to comment #11) > > Just because something is changed doesn't mean it's wrong or bad. There were > > also lots of complaints when we went to UTF-8 by default from people saying > > that it was a regression. That didn't mean that we stood down and stuck with > > legacy encodings. > > For utf-8 we had general agreement within engineering at least afaicr... :) No, there was plenty of disagreement at the time, even internally > I don't like it, but if we have to have the same behaviour for live and normal > installs then I guess we have to keep the hardlist for now. :-/ > Otherwise maybe we could do an additional hack to make the hardlist also > apply to live installs. Additional hacks really don't seem like the answer here... > For F9 we want to do something like a dialog the first time a user starts > a desktop session asking if s/he wants to use the installed input methods, ... I suspect this will meet some (strong) resistance from the desktop group as there has been similar resistance to all sorts of "first login wizards" just because they end in all kinds of pain > or at least allow users to control input methods more dynamically on the > desktop. This would be the better approach -- if scim didn't end up affecting common keyboard shortcuts and wasn't configured via a notification icon (it's not notifying -- thus it might not make sense to use the notifiation area), then it starts to get a lot easier to have it enabled by default while not being intrusive. It really really really makes a lot of sense to stop thinking about this as something that's i18n-specific and instead that it's a more general concern of input on the desktop and thus get the discussion going with a wider audience including the desktop/GNOME guys as well as the X guys.
Comment 13 Matthias Clasen 2007-09-26 02:05:41 UTC
> For F9 we want to do something like a dialog the first time a user starts > a desktop session asking if s/he wants to use the installed input methods, > or at least allow users to control input methods more dynamically on the > desktop. I have to agree with Jeremy here, a first-login dialog is really not the way to go. What would be possible is to mention input methods and other setup issues more prominently in the release notes or whatever we end up showing in the browser by default. And start up the browser at login time. Does more dynamic input method control include the gconf key/gtk setting that we discussed via mail earlier ?
Comment 14 Jens Petersen 2007-09-26 02:23:07 UTC
(In reply to comment #13) > Does more dynamic input method control include the gconf key/gtk setting that > we discussed via mail earlier ? I think so, Tagoh has some more ideas on that, but we haven't actually designed it yet.
Comment 15 Akira TAGOH 2007-09-27 14:10:35 UTC
that's just an rough idea - IM might be /enabled/ through any key or the applet by clicking or select an item from the menu or whatever, and bringing up IM via dbus say. and notify the changes of IM, including such as XMODIFIERS, GTK_IM_MODULE and QT_IM_MODULE, to the applications through gconf key and XSETTINGS things.
Comment 16 Jeremy Katz 2007-10-10 19:22:18 UTC
Ping? We have just over a week until the Fedora 8 freeze and this behavior is still broken.
Comment 17 Jens Petersen 2007-10-10 23:34:58 UTC
I believe Tagoh already made the changes in im-chooser-0.5.2-3.fc8.
Comment 18 Akira TAGOH 2007-10-11 00:11:32 UTC
Exactly. it should be reverted in 0.5.2-3.fc8. which has the hard-coded language list. Jeremy, which version did you try?
Comment 19 Akira TAGOH 2007-10-11 00:12:42 UTC
back to ASSIGNED since we have the hard-coded list again.
Comment 20 Jens Petersen 2007-10-11 02:02:41 UTC
Removing from bug F8Blocker since the changes have been reverted.
Comment 21 Jeremy Katz 2007-10-11 20:44:10 UTC
Whoops, sorry. Missed the build and was just going on the fact that it was still open and on the blocker list. This does look fine trying with a rawhide live image from today.
Comment 22 Bug Zapper 2008-04-04 13:31:20 UTC
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Comment 23 Akira TAGOH 2008-04-11 07:02:06 UTC
We still have a hard-code lang list in xinput.sh and I'm keen to fix this. well, the plan is to have the kind of applet for every users who install im-chooser and taken over the control to bring up Input Method to it instead of from xinput.sh. and applet watches a hotkey to enable/disable IM. the initial status is "disable". so this could be an regression for users who use IM though, informing how to enable IM with a balloon message at first boot time would be a workaround for that.
Comment 24 Bug Zapper 2008-05-14 03:06:19 UTC
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 25 Tony Fu 2008-09-10 03:16:06 UTC
requested by Jens Petersen (#27995)
Comment 26 Akira TAGOH 2009-05-26 08:30:32 UTC
*** Bug 501649 has been marked as a duplicate of this bug. ***
Comment 27 Jens Petersen 2009-06-24 08:47:18 UTC
I think this can be closed, no? Or any more on this?
Comment 28 Akira TAGOH 2009-06-24 08:54:37 UTC
Heh. this is your report :) do you think your request is satisfied with current implementation?
Comment 29 Jens Petersen 2009-06-24 09:17:11 UTC
I am pretty happy with how things current stand.