It's not a good idea to post your problems in the comments section of my blog. Even if you provide contact address or website. I can't help you there.

• Look at bugs.kde.org for reports about similar problems. If you can't find them create a new bug.
• Come to #kde-devel and ask for help (i'm mjansen)
• Send me an email to kde (at) michael-jansen.biz and ask for help

Commenting to or opening a bug is the preferred solution. And please try to be very specific about your problem.

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.

With kde 4.2 my first big kde contribution went live. The khotkeys redesign. It was unfinished and users complained. Most complains - or should i say the loudest? - were about the incomplete mouse gesture support. The lament didn't stop. Then Frank Roscher came around and offered a tool name easystroke as a replacement for khotkeys and the ease was restored. Partially.

When i got the khotkeys gesture support working again in trunk the same guy sent me a patch implementing easystrokes gestures algorithm in khotkeys. Nice surprise. Apparently easystrokes author not only offers it's software for free ... no he also provides a detailed explanation of the algorithm used. That's the spirit! Since easystrokes algorithm is superior to khotkeys old one it was a no brainer to accept the patch. He even added an migration from the old algorithm to the new.

So with 4.3 the mouse gesture support in kde is back. But the documentation for khotkeys is miserable. So it's not easy to guess how mouse gestures work. Perhaps someone out there is willing to write some documentation. I'm bad at doing that. As you will shortly notice.

Groups can have conditions. A condition is something along the line "There is a window named xyz", "The window with title xyz is active". No condition means always true. Have a look at the "Konqueror Gestures" for an example. All gestures in that group will only work if the condition is met. And the condition is that a konqueror window is active. What a surprise!

To start a gesture you must press a mouse button. Click on Settings to configure which. When pressing the mouse button khotkeys follows your moves. After you release the mouse button khotkeys will try to match your gesture against its database. If a match is found the associated action is executed. Again have a look at the Konqueror examples which work perfectly. For me. In case of troubles open a bug.

Mike

Multikey shortcuts in kde 4.1 where officially supported. But the implementation wasn't what most of us expected. KKeySequenceWidget - responsibly for capturing key sequence from the user - had some annoying bugs.

KKeySequenceWidget is this small widget most of you will know. With kde 4.1 it had some shortcomings. The developer / code was able to use shortcuts like "ctrl-r, ctrl-t" or "ctrl-r, shift-t. The user was unable to assign these because KKeySequenceWidget couldn't handle them.

When capturing shortcuts it only allowed pressing one or more modifiers and then sequentially some keys. If one modifier was released the capturing stopped immediately. A modifier is one of shift, meta, alt or ctrl. Even if you had to hold down the modifier(s) all the time during the capturing, the resulting shortcut only had the modifier(s) on the first key. After for example pressing ctrl-r, ctrl-s while capturing, the resulting shortcut was ctrl-r, s. So you had to release ctrl before pressing s. It was not possible to switch modifier during the capturing.

With kde 4.2 the capturing goes on as long as a modifier is pressed. If the last modifier is released a timer starts. if the user presses a key before the timer ends the key is added to the sequence and the timer restarts. If the user presses a modifier before the timer ends the timer is stopped again and the capturing goes on.

With that scheme it's possible to record the weirdest shortcuts. Go ahead and assign "ctrl-r, meta-s, k, alt-s".

I would like to have some feedback on the usability and intuitiveness of capturing key sequences. Currently the timer isn't visualized. I think it should. Anyone else an opinion?

The maximum number of keys is currently hard coded as 4. With KKeySequenceWidget::setMultiKeyShortcutsAllowed() it's possible to only allow one key shortcuts. This is needed for global shortcuts because it's not possible to have multikey global shortcuts currently.

But before you get to creative with your shortcuts keep the ambiguity problem in mind. I will talk about this problem in one of my next posts. But in short. It's not possible to have both "ctrl-a" and "ctrl-a, shift-s" at the same time. KShortcutsEditor knows that and will warn you.

Mike

My last two posts about global shortcuts got some comments i want to address now.

Whenever it comes to a discussion about the kde4 global shortcuts framework things heat up. Somehow people get really agitated if they learn how it works. Why? I don't know. It's a framework like any other. It has its ups, it has its downs. So lets have look where the problems are.

The reason i work on global and local shortcuts is because i care about them. I use heavily adapted desktop setups both under linux and windows. And that for years. Global shortcuts are an important part of these setups. Having to use the mouse makes me itchy.

Over this i time developed a global shortcuts setup that works for both on windows and linux. I tend to get angry if one of them doesn't work. Using them for more than five years makes me trying to use them unconsciously even if i know they don't work. Which frustrates me.

Just a short note that i commited a change to kdebase reenabling shortcut support in kmenuedit. It's now possible again to assign a global shortcut to an application in kmenuedit. It was possible for some time in kshortcuts but it looks like no one noticed.

Please tell me if you have problem with that feature.

The gui side in khotkeys is not yet finished but i'm working on it. If someone would like to help polish that contact me.