Red Hat Bugzilla – Bug 131217
[gimlet] lang menu empty before running app
Last modified: 2014-03-25 20:50:53 EDT
Description of problem:
When system starts and there is no application running, clicking on
the GIMLET shows only ASCII and Add LE options. In addition, after
selecting Add LE option, the menu for user to add and remove LE is
empty. However, GIMLET works fine after opening any new application.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Select CJK locale and GNOME environment at gdm
2.Click on GIMLET (will show no LE)
3.Select add new LE option in GIMLET (empty menu will pop)
1) GIMLET display no LE available for use
2) Selecting add new LE produce empty menu
1) GIMLET display the LE selected by user earlier
2) Menu should be populated with the LE installed
To make it work properly, open any new application and click on GIMLET.
Cant attach screenshot as it would cause the GIMLET to work properly. :-)
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.
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
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.
> 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
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
ln -s /etc/X11/xinit/xinput.d/iiimf ~/.xinput.d/default
then I DO NOT have this bug but no accented character either
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:
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"
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:
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
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.