Bug 250226 - should start IM by default on desktop
should start IM by default on desktop
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: imsettings (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
bzcl34nup
: FutureFeature
: 501649 (view as bug list)
Depends On:
Blocks: 243563
  Show dependency treegraph
 
Reported: 2007-07-31 01:44 EDT by Jens Petersen
Modified: 2009-06-24 05:17 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-24 05:17:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jens Petersen 2007-07-31 01:44:16 EDT
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 01:57:58 EDT
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 06:49:47 EDT
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 10:56:53 EDT
should be fixed in 0.5.2-2.fc8.
Comment 4 Jeremy Katz 2007-09-22 10:02:47 EDT
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-23 21:32:10 EDT
(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 10:32:44 EDT
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 19:51:33 EDT
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-24 20:29:42 EDT
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-24 23:39:34 EDT
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 10:43:30 EDT
(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-25 21:06:50 EDT
> 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-25 21:55:56 EDT
(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-25 22:05:41 EDT
> 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-25 22:23:07 EDT
(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 10:10:35 EDT
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 15:22:18 EDT
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 19:34:58 EDT
I believe Tagoh already made the changes in im-chooser-0.5.2-3.fc8.
Comment 18 Akira TAGOH 2007-10-10 20:11:32 EDT
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-10 20:12:42 EDT
back to ASSIGNED since we have the hard-coded list again.
Comment 20 Jens Petersen 2007-10-10 22:02:41 EDT
Removing from bug F8Blocker since the changes have been reverted.
Comment 21 Jeremy Katz 2007-10-11 16:44:10 EDT
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 09:31:20 EDT
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 03:02:06 EDT
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-13 23:06:19 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 25 Tony Fu 2008-09-09 23:16:06 EDT
requested by Jens Petersen (#27995)
Comment 26 Akira TAGOH 2009-05-26 04:30:32 EDT
*** Bug 501649 has been marked as a duplicate of this bug. ***
Comment 27 Jens Petersen 2009-06-24 04:47:18 EDT
I think this can be closed, no?  Or any more on this?
Comment 28 Akira TAGOH 2009-06-24 04:54:37 EDT
Heh. this is your report :) do you think your request is satisfied with current implementation?
Comment 29 Jens Petersen 2009-06-24 05:17:11 EDT
I am pretty happy with how things current stand.

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