www.michael-jansen.biz

See Bug 190412 for an explanation. The problem is a little broader than the bug reports. See Bug 193085 for a more detailed explanation of the problem.

The problem was me fixing khotkeys without completely adapting it to the new global shortcuts framework in place for kde 4.x . I just didn't realize the consequences. Khotkeys in 3.x ungrabbed the shortcut if the condition was not met or the khotkeys was inactive. In other word whenever the focus was not on an konqueror window ctrl-w was freed. With 4.2 that important bit of functionality was lost. ctrl-w was grabbed all the time. My fault.

If you are on kde 4.2 and want to have your keys back then go to the input actions kcm (kcmshell4 keys) and remove all shortcuts associated with inactive hotkeys. Or go to the global shortcuts kcm (kcmshell4 keys) and disable all khotkeys shortcuts you don't like.

With 4.3 inactive global shortcuts are not grabbed anymore. I made the change last weekend. if you get your hands on the next snapshot and still have problem with that ping me.

That is some kind of unexpected comeback from a classic out of the pre kde 4.0 development time. I once managed to break the 'e' key for all when working on khotkeys. Me fixing khotkeys exposed a qt bug. Qt did parse the "Win+e" string from kde 3.x as 'e' because it didn't recognize the Win modifier. It is called Meta in qt. We fixed the symptom because we couldn't fix the cause and everything went smoothly for some time.

Then reports about that problem having a comeback started to creep in but i couldn't get my hand on someone experiencing it. Not everybody looks my way when having keyboard problems. The last days comawhite - a irc regular - had the problem and we could pinpoint the cause.

The problem this time appeared because of a different reason. comawhite is a gentoo user and his x11 setup didn't provide a modifier usable as the meta key. You can check that with xmodmap -pm. I get:

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):
 
shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40),  Meta_L (0x9c)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x73),  Super_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x8),  ISO_Level3_Shift (0x71),  ISO_Level3_Shift (0x7c)

For comawhite mod4 was as empty as mod3. Some kde code didn't care and still grabbed the shortcuts with meta in it globally. Meta was just dropped. So for 'Meta+E' only e was grabbed, for 'Meta+X' only x was grabbed. Makes up for a pretty messed up session. And you couldn't notice the reason because the code didn't trigger the action. So the key was just eaten.

I fixed the kde code and comawhite fixed his setup by adding

xmodmap -e "add mod4 Super_L"
xmodmap -e "keycode 115 = Super_L"

And qt having some problems with parsing QKeySequences from String. Since nokia opened the qt repository to external contribution i will try again to fix it. See my Qt Patches.

Update 20.05.2009

I just found out that there is another problem having this effect. See Bug 193150: can't type 'e' key. After starting amarok it get's even uglier. Best idea is to skip current snapshot and use the one from next week.

That's because on some keyboards Alt+PrintScrn is used as Sysreq. You can use xmodmap -pke | grep -i print to check if you are affected. If you get something along the lines of keycode 111 = Print Sys_Req Print Sys_Req Print Sys_Req there is no alt+printscrn for you.

Someone managed to put a really bad hack into kde hardcoding keycode 111 to the printscrn key so it worked if you changed the shortcut manually in the config file. That code managed to be there since 3.x. So much to the many eyeballs theory :-) : I removed that hack so it will stop working with 4.3 because it breaks keyboards where 111 is mapped to some other key.