Version: unknown (using KDE 3.5.2, Gentoo) Compiler: gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) OS: Linux (i686) release 2.6.16-suspend2-r1-justbudget this used to work fine. I don't know when exactly it breaks. while upgrading to 3.5.2 or something recently went wrong with my config. but my feeling is its a bug. When i choose the french-canadian keyboard. I can type é character but not è or any other characters that requires the DEAD_KEY. when I press the dead key it does wait for a next key, but when I then press on the vowel, it is shown unmodified. the same keyboard still works in Firefox. but not in kword or konqueror. weird.
Can you run xev in a terminal (xterm or konsole), press the offending key and paste the KeyPress and KeyRelease events?
KeyPress event, serial 32, synthetic NO, window 0x3200001, root 0x4c, subw 0x0, time 82688950, (110,103), root:(919,128), state 0x0, keycode 48 (keysym 0xfe50, dead_grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x3200001, root 0x4c, subw 0x0, time 82689008, (110,103), root:(919,128), state 0x0, keycode 48 (keysym 0xfe50, dead_grave), same_screen YES, XLookupString gives 1 bytes: (60) "`"
It's been working fine for me. I cannot explain your problem. KeyPress event, serial 28, synthetic NO, window 0x1200001, root 0x75, subw 0x0, time 371751669, (512,386), root:(516,413), state 0x0, keycode 49 (keysym 0xfe50, dead_grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 31, synthetic NO, window 0x1200001, root 0x75, subw 0x0, time 371751824, (512,386), root:(516,413), state 0x0, keycode 49 (keysym 0xfe50, dead_grave), same_screen YES, XLookupString gives 1 bytes: (60) "`"
I have the same problem. This problem has been reported by many people in forums, etc. Here is the Ubuntu bug report with additional information: https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/69896 My situation: my system uses the English locale by default, but I type in French and Chinese too. Therefore, I use SCIM and I have configured multi-keyboard layouts for each language on my US keyboard. The bug only affects KDE applications: the dead_keys are printed as if they were a character on their own, like the grave accent in the Canadian keyboard or the circonflexe and trema in the French keyboard layout. Using konqueror right now, here is what I get when trying to type the accented characters using the dead keys: ^e ¨e ^i ¨i. Worth noting: in all the bug reports I have seen including this one, the bug appeared after a KDE update. In my case, everything was working as expected until I applied the Kubuntu 8.04 updates to upgrade to KDE 3.5.9.
as far as my experience goes. it seems like SCIM is killing deadkeys.
Killing dead keys: that's a nice way to put it :) Here is the related scim bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=1668290&group_id=108454&atid=650539 I use scim myself, but note that myself and many others (as noted in the threads above) do not experience any problem with non-KDE applications. Maybe there is an incompatibility between KDE and SCIM?
how many dude and gals are like me and need a french keyboard with dead keys plus and input method system to type japanese. all settings defaulted to US english for programming ;) god loves me.
Well, I am in the same situation as you are: I have defaults set in English (for programming and almost everything), but I do need to type in Chinese and French. Like you, the bug was triggered during a system upgrade, and affects only KDE applications...
Hello, Can you still reproduce the bug with the latest KDE 4 release? Thanks.
*** Bug 136546 has been marked as a duplicate of this bug. ***
Same problem with Brazilian ABNT keyboard, English locale (en_US.UTF-8). No dead keys in KDE and Qt applications, works fine in GTK applications. I use mostly an English environment, but have to type in Portuguese and Japanese, so the need of dead keys and SCIM.
scim kills deadkeys please find a solution for this.
For information, does it is also broken with pure Qt apps or not?
(In reply to comment #13) > For information, does it is also broken with pure Qt apps or not? > Yes. And trying to start the application with QT_IM_MODULE unset disables SCIM for the application, but *does not* restore the dead keys.
Additional information: there seems to be some odd interaction between SCIM, scim-bridge, scim-bridge-qt{3,4} and Qt{3,4}. I removed scim-bridge-qt from my system and set QT_IM_MODULE=scim. This fixed the problem, for Qt3/KDE3 apps only. For Qt4/KDE4 apps, scim-bridge-qt4 seems to be the only SCIM interface available, that has this problem with dead keys. It was possible to work around by installing an English/European input method in SCIM (which emulates dead keys). Still, it is cumbersome to run different sets of applications with different values of QT_IM_MODULE... For reference, I found some downstream bugs: https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/69896 https://bugs.launchpad.net/ubuntu/+source/scim/+bug/77168 https://bugs.launchpad.net/ubuntu/+source/scim/+bug/173894
So apparently it is not a KDE bug for rather a Qt bug or a scim-qt bug. Please report the bug on their bug tracker, i fear there is little that KDE can do at this stage.
http://trolltech.com/developer/task-tracker/index_html?method=entry&id=219928 [4.4.0] Bug: dead keys do not work. Apparently, the bug was set to fixed for Qt 4.4.0. Which version of Qt does KDE4 uses? The fix for KDE4 would have to be confirmed before closing this issue. Does this mean that the bug won't be fixed for KDE3?
SCIM bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=1668290&group_id=108454&atid=650539
What version of Qt is used depends on your distribution. If you're running KDE 4.3 (or almost-4.3, since 4.3 isn't out yet but RSN), then you are likely using Qt 4.5.x, so this problem should end up fixed.
Bad bugzilla, it didn't show my extra box... :P