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): im-sdk-12.0.1-1.svn1891 How reproducible: Always 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) Actual results: 1) GIMLET display no LE available for use 2) Selecting add new LE produce empty menu Expected results: 1) GIMLET display the LE selected by user earlier 2) Menu should be populated with the LE installed Additional info: 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. ---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.