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

Changing Keyboard Layouts Doesn't Bring Trigger Bindings Along With It #1482

Closed
timvisher opened this issue Apr 25, 2013 · 12 comments
Closed
Assignees

Comments

@timvisher
Copy link

As we know, I'm a Dvorak user. I'm not sure what changed recently (I think it was actually an update to OS X), but lately if I switch keyboard layouts from Dvorak to Qwerty or vice versa, my triggers don't respond to the right keypress. Instead, they correspond to the positional key of the trigger.

For example:

I bind ⌘⌥^G to Google Search. If I switch to Qwerty from Dvorak, I cannot press that keysequenc, but instead have to press ⌘⌥^U. U, positionally, is where G is located in Dvorak.

I have not been able to tie down the exact context that this happens in either. Initially, I thought that it was related to Quicksilver being started up while the system was in Qwerty or Dvorak, but doing ⌘^Q after having switched doesn't seem to fix things.

To make matters more interesting, the triggers, depending on what mode they're stuck in, will actually report themselves as being bound to the keycap of the key, rather than the logical key that I'm pressing.

FWIW, Moom.app also appears to be suffering from this problem.

Anything I can send along, just let me know!

Thanks as always for the second most impressive piece of software I've ever used.

@pjrobertson
Copy link
Member

What setting do you have in the 'Command' preferences under the keyboard
layout section? Do you have Quicksilver set to switch to a specific
keyboard when launched?

I'm surprised restarting Quicksilver doesn't change anything. That should
in theory release the keyboard bindings of the triggers then set them up
again on relaunch. Perhaps it's an OS X bug not correctly advertising the
keyboard layout.

Thanks as always for the second most impressive piece of software I've
ever used.

So what's No.1? :)

On 26 April 2013 02:52, Tim Visher [email protected] wrote:

As we know, I'm a Dvorak user. I'm not sure what changed recently (I think
it was actually an update to OS X), but lately if I switch keyboard layouts
from Dvorak to Qwerty or vice versa, my triggers don't respond to the right
keypress. Instead, they correspond to the positional key of the trigger.

For example:

I bind ⌘⌥^G to Google Search. If I switch to Qwerty from Dvorak, I cannot
press that keysequenc, but instead have to press ⌘⌥^U. U, positionally,
is where G is located in Dvorak.

I have not been able to tie down the exact context that this happens in
either. Initially, I thought that it was related to Quicksilver being
started up while the system was in Qwerty or Dvorak, but doing ⌘^Q after
having switched doesn't seem to fix things.

To make matters more interesting, the triggers, depending on what mode
they're stuck in, will actually report themselves as being bound to the
keycap of the key, rather than the logical key that I'm pressing.

FWIW, Moom.app also appears to be suffering from this problem.

Anything I can send along, just let me know!

Thanks as always for the second most impressive piece of software I've
ever used.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1482
.

@timvisher
Copy link
Author

On Thu, Apr 25, 2013 at 9:32 PM, Patrick Robertson
[email protected] wrote:

What setting do you have in the 'Command' preferences under the keyboard
layout section? Do you have Quicksilver set to switch to a specific
keyboard when launched?

None. Un-checked checkbox.

I hadn't even heard of that feature. It also isn't something I want to
use because it would prevent my wife (or others for that matter) from
using Quicksilver on my box.

I'm surprised restarting Quicksilver doesn't change anything. That should
in theory release the keyboard bindings of the triggers then set them up
again on relaunch. Perhaps it's an OS X bug not correctly advertising the
keyboard layout.

It wouldn't surprise me because it's also affecting Moom.app.

Thanks as always for the second most impressive piece of software I've
ever used.

So what's No.1? :)

Emacs, of course. ;)

@timvisher
Copy link
Author

It just happened again so I figured I'd paste a screenshot in here because it's sort of interesting:

I opened my laptop and things were in this state.

Prior to ⌘^Q

I ⌘^Qed and they were in this state (far as I can tell the same).

After ⌘^Q

Of note is that my Google search trigger is currently correct (⌘⌥^G) while my Select Finder Selection in command window trigger (⌘⌥G) is set to ⌘⌥I (I maps to G positionally on a Qwerty keyboard). So in this instance, the triggers sort of half updated.

Also of note is my Remember the Milk trigger. Ordinarily this should be ⌘⌥^R. On a Qwerty keyboard R maps to O. P is the key directly to the right of O on a Qwerty keyboard. P in Dvorak is positionally where R is on a Qwerty keyboard. So in this instance it appears that Quicksilver stored my original trigger (⌘⌥^R), mapped it through to the position of R in Qwerty, but then translated it back to Dvorak when displaying it in the trigger window. Also, I have to press ⌘⌥^P in Dvorak in order to trigger it, which maps to R, positionally, on a Qwerty keyboard.

Last thing to note, I think, is that I do believe I most often notice this behavior when I have slept my laptop and just woken up.

I'll try to notice when we achieve normality.

@tiennou
Copy link
Member

tiennou commented Apr 29, 2013

Got it the other way around : Switched from Azerty to Dvorak, tried a Trigger using the Dvorak layout, Trigger got started. Changed back to Azerty, trigger is still mapped to Dvorak. Now all my triggers are Dvorak-based ;-). I'll try to take a look at this...

@ghost ghost assigned tiennou Apr 29, 2013
@timvisher
Copy link
Author

Just noticed this problem again. Any progress or any way that I can help on
this?

I would also like to point out that this is conclusively happening with
Moom.app as well.

On Mon, Apr 29, 2013 at 5:51 PM, Etienne Samson [email protected]:

Got it the other way around : Switched from Azerty to Dvorak, tried a
Trigger using the Dvorak layout, Trigger got started. Changed back to
Azerty, trigger is still mapped to Dvorak. Now all my triggers are
Dvorak-based ;-). I'll try to take a look at this...


Reply to this email directly or view it on GitHubhttps://github.com//issues/1482#issuecomment-17196989
.

@tiennou
Copy link
Member

tiennou commented Aug 19, 2013

This should be fixed soon™. Just the time that #1147 gets reviewed.

BTW, what's in front of the "second most impressive piece of software I've ever used" ? ;-)

@robacarp
Copy link

Ran into a particularly nasty version of this yesterday. I use dvorak regularly, but switched the layout to qwerty for a friend. She opened the dialog, typed "notepad" and it switched to free text mode. Qwerty E is Dvorak . (period). We both repeated it several times before realizing what the problem is.

1.2.1 (4010)

@timvisher
Copy link
Author

And I've been hit again. :)

Just got my fancy new Code keyboard and set it to Dvorak mode because how awesome is that? and then realized none of my triggers were working.

How're things going with this?

@robacarp
Copy link

@timvisher I see you've commented on most of the keyboard layout bugs...did you ever get an answer to the possible resolution of this bug? I recently started using a hardware dvorak keyboard as well, but when I unplug and switch to the system keyboard I have to relaunch quicksilver. The problem feels to me like triggers are being bound at the hardware level instead of the character level, but I suppose that could be just the way the OSX macOS handles things. 😢

@timvisher
Copy link
Author

@robacarp There's no good answer in sight, afaict.

@skurfer
Copy link
Member

skurfer commented Nov 16, 2016

We were pretty close to merging #1147 which should fix this, but there are some small things to work out still.

@pjrobertson
Copy link
Member

Should be fixed by #2594

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

No branches or pull requests

5 participants