Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 131217

Summary: [gimlet] lang menu empty before running app
Product: [Fedora] Fedora Reporter: Lawrence Lim <llim>
Component: iiimfAssignee: Jens Petersen <petersen>
Status: CLOSED DEFERRED QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: eng-i18n-bugs, fedora-ja-list, gc, timh, tools-bugs, wtogami
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-13 02:11:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 125997, 150221, 157869    
Attachments:
Description Flags
An example of empty menu mentioned in the description. none

Description Lawrence Lim 2004-08-30 04:18:06 UTC
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. :-)

Comment 1 Lawrence Lim 2004-08-30 05:23:03 UTC
Created attachment 103229 [details]
An example of empty menu mentioned in the description.

Comment 2 Jens Petersen 2004-08-31 04:11:31 UTC
*** Bug 131221 has been marked as a duplicate of this bug. ***

Comment 3 Leon Ho 2004-10-08 03:45:18 UTC
*** Bug 134311 has been marked as a duplicate of this bug. ***

Comment 4 Giuseppe Castagna 2004-11-09 22:23:04 UTC
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----

Comment 5 Jens Petersen 2004-11-10 01:47:03 UTC
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".

Comment 6 Giuseppe Castagna 2004-11-12 20:46:49 UTC
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---

Comment 7 Giuseppe Castagna 2004-11-14 23:06:12 UTC
>
> 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
 



Comment 8 Leon Ho 2004-11-15 04:18:35 UTC
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!

Comment 9 Jens Petersen 2004-11-15 04:35:02 UTC
For comment 6: there is now an IIIMF faq for Fedora Core:

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

Comment 10 Jens Petersen 2004-11-15 06:20:17 UTC
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".

Comment 11 Giuseppe Castagna 2004-11-15 10:51:01 UTC
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.

Comment 12 Giuseppe Castagna 2004-11-15 11:27:52 UTC
> 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.



Comment 13 Giuseppe Castagna 2004-11-15 11:40:16 UTC
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.

Comment 14 Jens Petersen 2004-11-16 05:24:55 UTC
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. :)

Comment 15 Lawrence Lim 2005-04-26 04:31:40 UTC
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.

Comment 16 Jens Petersen 2005-05-16 06:04:10 UTC
The icon part is fixed in iiimf-12.2.