When typing in the text area of KDE applications, the keyboard (with dead keys) work fine, but if you access the (classic) menu bar in the application window, dead keys may stop working fine. Exceptions: - With widget Window Menubar no problem. - In Rekonk, with menu system like Chrome, no problem. Testing: Tested in different computers. Tested in Debian, kubuntu (13.04, 12.10, 12.04), OpenSuse. Tested with desktop effects enabled and disabled Tested in Kate, Dolphin, Kontact, Amarok, Agregator... Tested in KDE 4.10, 4.9, 4.8 and... 4.4.5 Tested with free and privative drivers Tested with Spanish, Portuguese and English keyboard layouts Tested in installed system and live-cd. Tested navigating menus with mouse and keyboard Tested with IBus and XIM input method I apologize for my English. Reproducible: Always Steps to Reproduce: 1. Check that you are using a keyboard layout with dead keys, if not, install and use one. System Settings > Input devices > keyboard > Layout > Configure layouts e.g. English (US, international with dead keys) 2. Open a kde app, (e.g. kate) 3. Write something to check that dead keys work well. In English, e.g. press "´" and "A" results in "á" 4º Access of the menu bar in the application window and scroll through the options for 30 seconds or more. 5. Back to the editing area and write something to check that dead keys work well. In English, e.g. press "´" and "A" results in "á" Actual Results: output with ibus= "" (nothing) output with xim= "´a" (Dead keys are alive) Expected Results: Press key "´" and "A", expected output= "á" If dead keys fail, change the focus (e.g. another window) and return to kate, dead keys work again.
I have this issue too at least with KDE 4.8.4 in Debian Testing, KDE 4.8.5 in Ubuntu 12.04, KDE 4.8.5 in FEdora 16 and KDE 4.9.0 release 550 in OpenSuse 12.1. Just to confirm this bug, here are the steps I took to reproduce this behavior: You need to set up a keyboard distribution which includes dead keys, no matter if is English, Latinamerican, Spanish,etc.. 1) Open a Qt/KDE application (this app can be Dolphin, Konqueror, Kate, Kmail, Amarok, etc (even Clementine). 2) Use the dead keys to write text in the text boxes whenever the application have one, write some letters with accents like à á è é ì í ó ò ú ù. 3) Navigate through menus and submenus with the mouse or the keyboard. 4) Try to write again vowels with accents, Vuala! you should notice two behaviors; with Xim as input method: the output is this `a `e `i, with iBus as input method there is no output. Both input methods were set with qt-config. 5) You may change to another window (or open a new one) and then you will have the correct behavior again. As an additional information: I couldn't reproduce this behavior within Rekonq, as the problem only happens when I use a Qt/KDE application with a traditional menubar and not when I have widgets like widget-menubar or bespin Xbar that separates the (traditional) menubar from the main windows.
I can reproduce this bug, for example in Kate (KDE 4.10.2 - Kubuntu 13.04 64 bits) When you open Kate and write everything works fine and the keyboard configuration is the one you have chosen in KDE (Systemsettings). But for some reason when you click on a button and navigate right through the application menu bar, the input method configuration changes to what you have selected in qt config file "~/.config/Trolltech.conf" (in [DefaultInputMethod=] variable). If you minimize Kate and then returns the focus, the keyboard input method works correctly again. The same as with Kate happens to the programs mentioned by the other users.
I confirm the method expounded by YAFU for KDE 4.9.5, on the default "fr" layout for AZERTY in KDE. But my Trolltech.conf doesn't contain "DefaultInputMethod", so that may not be it. Nevertheless YAFU could be onto something because I had mistakenly installed a "nodeadkeys" layout in the past (which is still the one active in the TTY sessions). So it may not be the Qt default but something "deeper"...
Another way (better) to cause the failure. Open Kate Click "File" Scan down the File menu Scan up back to "File" Move to "Edit" Scan down "Edit" and leave the menu on the side click in the text area. In other words, this: http://i.imgur.com/sGUDyiC.png thanks to Ofnuts.
Another way (with keyboard) to confirm the bug. 1- Open Kate editor 2- write something to check that dead keys work 3- Press alt+F (to open File menu) 4- Press right arrow key (to open Edit menu) 5- Press esc (to closse menu) 6- write something to check that dead keys work The following are NOT causing the error. 1- Open Kate editor 2- write something to check that dead keys work 3- Press alt+F (to open File menu 4- Press esc (to closse File menu) 5- Press alt+E (to open Edit menu) 6- Press esc (to closse menu) 7- write something to check that dead keys work
I confirm the bug also in openSUSE 12.3 with KDE 10.4.2
It seems to be a bug in Qt, as it's reproducible in qt-only applications (I used qt-config to test). It should be reported in https://bugreports.qt-project.org/ , but I think it would be a good idea to test it in a Qt5 application to see if it also happens in Qt5 before reporting the bug to know if this bug does only affect Qt4 or Qt5 is also affected.
*** This bug has been confirmed by popular vote. ***
*** Bug 317746 has been marked as a duplicate of this bug. ***
I have the issue with the accents in Firefox and Chrome, but not in LibreOffice or Calligra. Cannot verify in Kate.