Created attachment 103229 [details]
An example of empty menu mentioned in the description.

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

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

I have just upgraded to FC3. The problem for me is similar but more
serious. I always work under US environment, but I'd like to write in
japonaise from time to time. Now Gimlet always propose me an empty
list of languages (as in the screenshot), even if I started an
application. But if before loggin in I select a Japanese session, then
I have exactly the same behavior as the one described above: empty
list until I do not start an application.

---Beppe----

Giuseppe, it sounds like you do not have iiimf enabled
when you log into a en_US session (you can check by looking
at the IM menu on the Button-3 menu in say gnome-terminal or
gedit).

To enable iiimf for en_US do:

$ mkdir -p ~/.xinput.d
$ ln -s /etc/X11/xinit/xinput.d/iiimf ~/.xinput.d/en_US

if you want it for all locale: replace "en_US" above by "default".

Thanks a lot, it worked (sorry for the delay but I had forgotten to
click the Add Me to Cc List box).
I swear, I googled a lot before posting the bug, but where could find
the information you so kindly indicated me?

In any case, thanks a lot. Im quite happy with the result.


---Beppe---

>
> In any case, thanks a lot. Im quite happy with the result.
>

Ugh, I spoke too fast. If I use IIIMF (thanks to Jens's suggestion) 
then the International US keyboard (that is the one in which you can
obtain accented characters by composing keys) no longer works. Sorry
I'm italian, leaving in France, with spanish friends, working in
English and learning Japonese. So I need most of the time plain ASCII
(I have qwerty keyboards) but from time to time accents on letters 
(très frequemment, ahimé, whence the International keyboard) and 
hiragana (seldom).

Let me summarize
If I ...
 ln -s /etc/X11/xinit/xinput.d/iiimf ~/.xinput.d/en_US 
then I have the bug of this report but intnl keyboard does not 
display accents

If I
ln -s /etc/X11/xinit/xinput.d/iiimf ~/.xinput.d/default
then I DO NOT have this bug but no accented character either

If I 
ln -s /etc/X11/xinit/xinput.d/iiimf ~/.xinput.d/whatever_funny
my intl keyboard works again but no hiragana.

Any suggestion? In any case, thanks
 

Is it same as bug 130851? If not it would be great if you can submit
another bug on it so that we will not miss any information that may
differ from this original bug. Thanks!

For comment 6: there is now an IIIMF faq for Fedora Core:

<http://fedora.redhat.com/projects/i18n/iiimf-faq.html>.

As to comment 7: what locale are you normally in?
If it is en_US.UTF-8, then you should not see any
difference between the iiimf behaviour with ".xinput.d/default"
or ".xinput.d/en_US".

As for comment 10: I am indeed in en_US.UTF-8. I will check again
whether I did some wrong manipulation that made be believe that the
behavious was different for default and en_US. Here you are 
the relevant information of my environment:

SUPPORTED=en_GB.UTF-8:en_GB:en:en_US.UTF-8:en_US:en:fr_FR.UTF-8:\
fr_FR:fr:it_IT.UTF-8:it_IT:it:ja_JP.UTF-8:ja_JP:ja:es_AR.UTF-8:\
es_AR:es:es_ES.UTF-8:es_ES:es
XMODIFIERS=@im=htt
LANG=en_US.UTF-8


Thanks for the FAQ, I bookmarked it.

> As for comment 10: I am indeed in en_US.UTF-8. I will check again
> whether I did some wrong manipulation that made be believe that the
> behavious was different for default and en_US. Here you are 
>the relevant information of my environment:

Sorry my fault. Indeed if the locale is en_US.UTF-8 then there is no
difference with default. *BUT* I noticed the difference I signalled
above when the locale is it_IT.UTF-8. Indeed when

ln -s /etc/X11/xinit/xinput.d/iiimf ~/.xinput.d/default

and the locale is it_IT.UTF-8 the bug of this report (that is the
empty icon and menu before starting an application) disappears. So, at
least in my limited experience, this bug happens only in en_US.UTF-8.

As for comment 8, yes indeed I have the same behavior, but I was not
able to check the behavior with the scroll lock since I cannot
activate scroll lock on my laptop keyboard (IBM TP X40):

When I use IIIMF dead keys no longer work, the keys are dead but the
following characters are not modified, and this both in En and in Ja.
If I change the input method (e.g. by selecting default in the Input
method menu), then the keys work again. I verified this problem with
the following keyboards layouts

U.S. English International (with dead keys)
U.S. English w/ dead keys

(BTW anyone knows the difference betweens these two layouts? I did not
spot any).

I think that adding a new bug report is useless (but please feel free
to tell me the contrary). I will add in the bug 130851 that it also
happens with US Keyboard with dead keys.

Thanks for comment 12: I hadn't realised gimlet was hanging
for locales without a LE (language engine).

I filed bug 139470 for this issue: luckily there is an easy fix. :)

With iiimf-gnome-im-switcher-12.2-0.1.svn2578, instead of displaying empty
GIMLET, it correctly display the locale of my machine when I log in. Not sure if
it is related to bug 154359 though.

The icon part is fixed in iiimf-12.2.