Carl, which LE (Language Engine) are you using?

Japanese.

And I just realised another problem. If NumLock is pressed,
the arrowkeys stop working, along with CTRL-Space not working,
so you can't change input mode.

I'm not sure I can reproduce the arrowkeys thing, maybe it
just happened once right now, and changing between 'se' and
'se nodeadkeys' fixed that. But the CTRL-Space thing is
100% reproducible.

Arrowkeys stopped working again last night.

Any idea why?

If you have a chance, could you test with the newer
im-sdk in rawhide - unfortunately you probably
need to rebuild it for it to work on fc2....

No ideas at all why these problems exist.

And it's actually not 'im-sdk' that is giving me problems, it's
iiimf-gtk or the japanese le, but you can't select those components
in bugzilla.

Some fixes have been made to iiimf-le-canna very recently.
I suggest trying 12.0.1-5.svn1891 or later when they
appear in rawhide - should be a little after fc3 test2
is out.  Or it can be made available for testing sooner
if you wish.

Reproduced - this seems to be a frontend bug: perhaps
in the gtk iiim im module and httx or the iiimcf libs perhaps.

Anyway the problem doesn't seem to be specific to canna LE -
I see it with Hangul LE too.

Carl, are you experiencing the same problem when you are using other
LEs like Chinese ones?

It's not just in Japanese, English is fucked up as well.

I'll try removing Japanese tomorrow and logging in and out,
and see if that does anything.

But I was having these problems in RH9 as well, and then I
did remove everything but English and still had the problems.

My guess is that it's not in the LEs, but the frontend or httx.  

I've now tried with Japanese, Simplified Chinese and without anything
but English, and the bug is still there.

Here is the output from xev when pressing ALTGR-~

KeyPress event, serial 25, synthetic NO, window 0x3c00001,
    root 0x48, subw 0x0, time 832362429, (1111,934), root:(1116,956),
    state 0x10, keycode 113 (keysym 0xfe03, ISO_Level3_Shift),
same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False
 
KeyPress event, serial 28, synthetic NO, window 0x3c00001,
    root 0x48, subw 0x0, time 832362610, (1111,934), root:(1116,956),
    state 0x90, keycode 35 (keysym 0xfe53, dead_tilde), same_screen YES,
    XLookupString gives 1 bytes: (7e) "~"
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: True
 
KeyRelease event, serial 28, synthetic NO, window 0x3c00001,
    root 0x48, subw 0x0, time 832362748, (1111,934), root:(1116,956),
    state 0x90, keycode 35 (keysym 0xfe53, dead_tilde), same_screen YES,
    XLookupString gives 1 bytes: (7e) "~"
 
KeyRelease event, serial 28, synthetic NO, window 0x3c00001,
    root 0x48, subw 0x0, time 832363215, (1111,934), root:(1116,956),
    state 0x90, keycode 113 (keysym 0xfe03, ISO_Level3_Shift),
same_screen YES,
    XLookupString gives 0 bytes:
 

I reproduced this bug also with U.S. English keyboard layouts with
dead keys.

ISO_Level3_Shift seems to work fine but not the deadkeys as you observe.

Based on the conversion with Hideki on mailing list, UNIT should be
the one to input European characters. Carl-Johan, are you ok with UNIT?

I don't have UNIT as a language in my version.
Should I try and upgrade to fc3?

Well, I think you just need to install iiimf-le-unit, but
I not sure how complete the Latin LEs coverage is.  Testing
would be very welcome.  There are many improvements in iiimf
in fc3 though so I would encourage you to try to upgrade
to that anyway.

However Hideki also said that we probably need an intermediate
solution for the problem: ie allowing the deadkeys to work normally
when iiimf is in the off state.

yeah, try latest im-sdk, use unitle, when press dead keys, you will
see a candidate window of the accented characters.

Actually you're right, Yu, I hadn't tried using PageUp and PageDn
on the candidate window: it seems to have all the major chars for
both dead_acute and dead_grave at least.  I didn't try other types
of deadkey but assume they work too.

/me who would like to know how to input Danish vowels with a jp
keyboard with iiimf...  Probably a separate bug is needed for that.

I guess one could still argue though that supporting deadkeys
when iiimf is off would be a good thing though.

> yeah, try latest im-sdk, use unitle, when press dead keys, you will
> see a candidate window of the accented characters.

Ahem, I have fc3 and installed rawhide version of iiimf (12.1-8). I
installed unit-le and restarted iiimf services but dead keys are still
dead (no resurrection ;-) When I select US keyboard with dead keys and
press a dead key nothing is printed and the next charecter is then
displayed not modified. Where am I wrong?

> I guess one could still argue though that supporting deadkeys
> when iiimf is off would be a good thing though.

Definitively. This is at least my case and I am not the only one.
I have a US keyboard, write in English 60% of my text, in French 39%
and japanese 1%. So I really need to use dead keys to write french
accents on my US keyboard. Let me know how I can help.

-------------------
P.S. What ISO_Level3_Shift is?

Giuseppe, the deadkeys only work with iiimf with the Latin LE
(Latin -> unitLE in the gimlet lang menu) when it is on.

However I can only get dead_acute and dead_grave to work with it
even though the Latin LE table in the source seems to contain
many more symbols.

ISO_Level3_Shift is normally bound to Alt_R (AltGR), the modifier
for getting the symbols written on the right side of the keys.

> Giuseppe, the deadkeys only work with iiimf with the Latin LE
> (Latin -> unitLE in the gimlet lang menu) when it is on.
> 

Ahhh, I did  not have noticed that now in the Gimlet submenu now Latin
had another submenu unitle. I selected it and now I have my accents.
However the reason why I did not notice it is that when I am in
Thunderbird (or Firefox) there is not such a submenu. I think that
this is normal, howver the consequence is that I cannot use dead-keys
(hence, accents) in my main mail-client (Thunderbird). It would be
wonderful if one could use dead-keys even without passing through iiimf.

In any case thanks a lot.

> However I can only get dead_acute and dead_grave to work with it
> even though the Latin LE table in the source seems to contain
> many more symbols.
> 

Yes the same here. This is mostly ok for French (apart from ^ over
several letters). More annoying is for Spanish since ~ over n is no
longer possible.


> ISO_Level3_Shift is normally bound to Alt_R (AltGR), the modifier
> for getting the symbols written on the right side of the keys.
> 

Thanks

Just an additional indication. I do not know whether this is
a bug or not, but when I select the greek input mode (I use it
for mathematical symbols) gimlet still indicates "En"

Comment 22: the current default gimlet lang selection behaviour
for new apps may be a little confusing, but I'd be surprised if
Latin -> unitLE isn't there once you've added it...
You may want to try gnome-im-properties...

Comment 23: For me it shows "El" for Greek.

Until this problem gets resolved, you can use this trick which I have
been using for the past 3 years... When I want to type in Japanese, I
start my applications with this script:

#!/bin/sh

export XMODIFIERS="@im=htt"
export LANG=ja_JP.UTF-8
export GTK_IM_MODULE="iiim"
httx &
sleep 1
$@

So, the other way around, if one unsets GTK_IM_MODULE and XMODIFIERS,
the launching application will not use the input modifier and will
work fine with dead keys.

> Comment 22: the current default gimlet lang selection behaviour
> for new apps may be a little confusing, but I'd be surprised if
> Latin -> unitLE isn't there once you've added it...
> You may want to try gnome-im-properties...
> Comment 23: For me it shows "El" for Greek.

This happened because I had just restarted the iiimf service and
noot rebooted the machine. After rebooting both problems vanished. 

Giuseppe, ok, it sounds like gimlet was out of sync then.
If you have a way to reproduce that, please file another bug.

Adding patch from trunk to fix deadkeys in Euro layout at least.

As using UNIT LE is the way suggested from upstream, how does UNIT
works for everyone?

All these fancy shmancy frameworks... I consider myself quite
proficient in linux use etc., but it took me the WHOLE day to figure
out how to write in polish and french (in addtion to my en_CA default
local). And as such I would like to help as best as I can with this bug...

#1 For polish I finally realized that there is no PL support in iiimf
and I just need to switch keyboard layout. That worked fine...
'COMPLAINT': how do we get PL into iiimf?

#2 For my french, US-intl keyboard + iiimf-le-unit seem to work 90%.
That is, as mentioned above, only dead_acute and dead_grave work.

I've got FC3 installed here, with no non-stable RPMS. Is there a
workaround to the limited dead-key functionality in iiimf-le-unit...
and can contribute in any way to have a simply-working langauge input
switcher "widget"?

Thanks, (sorry for the rant, it's been a looong day beating on this)
Mike

... before I leave this alone for good (for the day). A couple more
things to add:

- Ctrl-Space/Shift-Space does not work consistently. read: it appears
that I first have to make a change in gimlet, and then after the
initial setting of le the keyborad shortcuts work to switch from the
default to the chosen le

- how do I delete the Latin->default, as this le is quite ?useless?
and I would like Latin->unitle to be the default iiimf input engine

That's _IT_ for the day (for real this time),
Stubborn Mike

Mike,

In response to comment 30:

#1 Right as you state keyboard layouts and iiimf are not yet
integrated.  I'm not familiar with Polish layout, but do you
actually need a full Polish layout or would you be happy with
just being able to input Polish characters with some LE in
iiimf?

#2 The other deadkeys should be working properly in 12.1-10
and later in rawhide (fc/development) - if you could test
that it would be appreciated.  (I think it should install/
work ok in fc3).

For comment 31:
It sounds like the first and second comment are the same?
You don't like Latin->default LE.  It is there primarily
for English users who only want to use really occasionally.

Could you file a separate bug about that: "can't remove
Latin->default LE"?  Thanks.

Jens,

#1 You are right, after reading up on LE I realized that I have to use
a layout ONLY becuase an LE for polish just isn't available yet. If I
were  to look at this, would the idea be to just implement it into
le-unit? For now a layout w/ default LE works fine, i.e. use right-alt
for the funky accented characters ;) here is a sample Ä, Ä, Å, Ä, Å, ó
... in fact my _real_ name is MichaŠSówka :D

#2 I will install the rawhide packages and will report as soon as I
can rip myself away from my thesis work for long enough...

#3 Right again... I see You agree that it's a missing feature to be
able to remove a input method for a given language... will make sure
to follow up.

Doing what I can,
Mike

#29: unit_le from version 12.1/release 10.FC3 does *not* work correctly at all,
either for inputting accented Latin, either for Greek. See bug 149105.

Created attachment 111227 [details]
script for launching gedit (and only gedit) with Japanese input

This script can be used to launch a gedit (or any other program) with the
Japanese input method, without having to set us the whole desktop for Japanese
(and thus avoiding the global effect of removing Compose / dead keys).

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

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

Sorry for long delay, well, can you try the latest IIIMF packages in rawhide?
perhaps 12.1.1-15.svn2509 would makes it better for UNIT.  Please let us know
what's the problem in the latest.

Thanks,

I am observing the problems described above for IIIMF-LE-CANNA and Czech
keyboard layout. I have tried the IIIMF-LE-UNIT language engine, but the result
is not satisfactory - only when I switch to Latin-Unitle do the dead keys work,
but then other strange things happen - such as when I type in a normal letter
after an accented one, it gets displayed twice.

As somebody above noted, the entire process of figuring things out with IIIMF is
terribly unintuitive and cumbersome - on this particular instance, could perhaps
an extra option be added to the Gnome Panel applet that would make it possible
to simply disable IIIMF for a given window ? After all, the keyboard layouts are
time tried and work well for most things ...

Using FC4 with the latest updates BTW.

Thank you for your feedback, Petr.

(In reply to comment #43)
> I am observing the problems described above for IIIMF-LE-CANNA and Czech
> keyboard layout. I have tried the IIIMF-LE-UNIT language engine, but the result
> is not satisfactory - only when I switch to Latin-Unitle do the dead keys work,
> but then other strange things happen - such as when I type in a normal letter
> after an accented one, it gets displayed twice.

I think it's Bug#162646 I've filed and will be fixed in next build -- it's now
being built -- could you please test this issue with the fixed packages again?

Thanks,

Ok, I've confirmed now that XKB doesn't work on IIIMF enabled. let me have a
look into it then.  However the latest UNIT LE looks good to me though, but anyway.

This problem should be fixed in 12.1-13.EL.2.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-683.html