Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single-modifier activation fails after hitting ⌘⇥ #1713

Closed
skurfer opened this issue Dec 10, 2013 · 5 comments
Closed

Single-modifier activation fails after hitting ⌘⇥ #1713

skurfer opened this issue Dec 10, 2013 · 5 comments
Labels

Comments

@skurfer
Copy link
Member

@skurfer skurfer commented Dec 10, 2013

  • 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
Copy link
Member

@pjrobertson pjrobertson commented Dec 11, 2013

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
Copy link
Member

@pjrobertson pjrobertson commented Dec 11, 2013

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
Copy link
Member

@pjrobertson pjrobertson commented Dec 11, 2013

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
Copy link
Member

@pjrobertson pjrobertson commented Dec 11, 2013

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
Copy link
Member Author

@skurfer skurfer commented Dec 11, 2013

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants