Single-modifier activation fails after hitting ⌘⇥

[skurfer]

• It only fails once. The single modifier will work as expected until the next time you switch with ⌘⇥
• The modifier will continue to work as expected if you switch applications using a mouse, trackpad, or Quicksilver.
• There’s an exception to this: If the chosen modifier is ⌘, it will work after hitting ⌘⇥. I assume this is because that key is being watched “more closely” in that scenario.

[pjrobertson]

Confirmed. I'll look into it.

Just to confirm: this is a v1.2.0 'critical' bug, and the pull should be against release?

[pjrobertson]

Seems like a bug in OS X :)

The event for the first key down (of ⌘) is sent, but never for any of the key ups, so basically QS doesn't know a key up has been made and that messes it up.
Not really sure what we can do here, since there's no way of knowing if the user is pressing ⌘⇥ - all we get is the very first ⌘ down and that's it.

Report it to Apple? :)

[pjrobertson]

We could also request key up events from the OS X system and then we should be able to detect this, but that'd mean we'd have to monitor every single key up event :/

[pjrobertson]

Maybe it's a design feature. See the last paragraph of this (search for command)
Observing NSApplicationDidResignActiveNotification won't work because QS isn't active in the first place

[skurfer]

Just to confirm: this is a v1.2.0 'critical' bug, and the pull should be against release?

I’ve just been rebasing release when master changes. I see no reason not to keep sending everything to master for the foreseeable future.

As for how serious this problem is, I don’t know. All things considered, modifier-only is still more reliable than it used to be, right? I never used it until I started testing your change. I have to admit I’m pretty addicted to just tapping Caps Lock (which is another ⌃ key for me) to call up QS. Since using that, this bug has been a very minor annoyance that I barely notice. Most times, I assumed I hadn’t hit the key hard enough. Now I guess I know better and maybe it’l be more annoying, but is it worth ripping out the changes?

As for a possible fix, you’ve looked much harder at this than I have, but here are a couple of ideas:

1. Since we see key down events, when we get a key down for the activating modifier, could we check somehow to see that ⌘⇥ is not currently down, even though we never saw its key up? Why is ⌘ immune?
2. Both QSController and QSInterfaceController have an appChanged: method that runs when switching apps. Would it be possible to do something there that “resets” the state of the event listener?

Unrelated to key events: Do we need both appChanged: methods? They seem to do the same thing. The one in QSInterfaceController seems much cleaner. It matches on the bundle ID (instead of the name) and it can just hide the interface, instead of having to post another notification. Can we just drop the one in QSController?