Description of problem: After trying adding "XIM=htt" to ~/.i18n to get gnome-im-switcher-applet to work, as said in Bug #113922, the im-switcher runs fine but now dead keys on a swedish keyboard layout doesn't work anymore. Version-Release number of selected component (if applicable): iiimf-gtk-11.4-46.1.svn1587 xorg-x11-6.7.0-5 How reproducible: Always Steps to Reproduce: 1. Add "XIM=htt" to ~/.i18n or global i18n-file 2. Log in and out from gnome. 3. Add gnome-im-switcher-applet to panel and play with that. 4. setxkbmap se Actual results: Dead keys don't work. ¨, ^ and ~ act as if they are dead but nothing is produced. ~ + space outputs ' ', ¨ + a outputs 'a'. Expected results: Dead keys should work. ~ + space output '~', ¨ + a output 'ä'. Additional info: I have input all these characters with 'setxkblayout se nodeadkeys' since I can't input them with the dead keys anymore. ¨, ^ and ~ are on the key right of ] on a swedish keyboard.
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. ***
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