Bug 250226

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.

Just for updates, do we need to think about Live CD issue separately? the issue
is a bit inconsistent between them.

should be fixed in 0.5.2-2.fc8.

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.

(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?

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 :(

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.

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?

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.

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

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

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

> 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 ?

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

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.

Ping?  We have just over a week until the Fedora 8 freeze and this behavior is
still broken.

I believe Tagoh already made the changes in im-chooser-0.5.2-3.fc8.

Exactly. it should be reverted in 0.5.2-3.fc8. which has the hard-coded language
list. Jeremy, which version did you try?

back to ASSIGNED since we have the hard-coded list again.

Removing from bug F8Blocker since the changes have been reverted.

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.

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.

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.

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

requested by Jens Petersen (#27995)

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

I think this can be closed, no?  Or any more on this?

Heh. this is your report :) do you think your request is satisfied with current implementation?

I am pretty happy with how things current stand.