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

Capalized key to select action fails in 10.8 #1030

Closed
iwhisperer opened this issue Aug 2, 2012 · 9 comments
Closed

Capalized key to select action fails in 10.8 #1030

iwhisperer opened this issue Aug 2, 2012 · 9 comments

Comments

@iwhisperer
Copy link

@iwhisperer iwhisperer commented Aug 2, 2012

Since Mountain Lion upgrade, 'allow capitalized key to select action' has not functioned e.g. 'T' set for 'move to trash'. Using 'set as default' contextual menu option has no effect.
ß69 (3932)

@skurfer
Copy link
Member

@skurfer skurfer commented Aug 2, 2012

To elaborate: Only the first keystroke fails when holding ⇧. (By which I mean it gets sent to the first pane instead.) Subsequent keystrokes are sent to the second pane as expected.

@philostein
Copy link
Contributor

@philostein philostein commented Aug 26, 2012

So, ⇧letter is supposed to just select the letter's default object and move the focus to pane 2 without changing the action?
⌘⇧letter executes the action as defined by pressing the letter in pane 2.

That makes sense. Just have to change my ingrained behaviour. :)

@skurfer
Copy link
Member

@skurfer skurfer commented Aug 26, 2012

Assuming you have "Allow capitalized keys to select the action" enabled…

No, holding down ⇧ and typing in the first pane should be equivalent to tabbing to the second pane and typing those same letters. So it should start changing the action from the first letter. It just keeps focus on the first pane and prevents you from having to tab. (Why anyone thinks holding one keystroke (⇧) is easier than just hitting one keystroke (⇥), I have no idea, but that's how it's supposed to work.)

⇧⌘[letter] should simply be a quicker way to do ⇥ [letter] ↩. I think that's what you were saying for that one.

@philostein
Copy link
Contributor

@philostein philostein commented Aug 26, 2012

Assuming you have "Allow capitalized keys to select the action" enabled…

Yes. :)

No, holding down ⇧ and typing in the first pane should be equivalent to tabbing to the second pane and typing those >same letters. So it should start changing the action from the first letter. It just keeps focus on the first pane and prevents >you from having to tab. (Why anyone thinks holding one keystroke (⇧) is easier than just hitting one keystroke (⇥), I >have no idea, but that's how it's supposed to work.)

That's what used to happen in ß68. Now, ⇧[letter] does: [change object] then ⇥

⇧⌘[letter] should simply be a quicker way to do ⇥ [letter] . I think that's what you were saying for that one.

Yes, that still works.

I don't mind the new behaviour TBH, it's simple to define an action with a letter in pane 2, then subsequently run the command using ⌘⇧letter.

@skurfer
Copy link
Member

@skurfer skurfer commented Aug 27, 2012

Don't understand that last comment. :-) The behavior for ⇧⌘[letter] is unchanged. It's the behavior for just ⇧ that's broken.

@philostein
Copy link
Contributor

@philostein philostein commented Aug 27, 2012

Yes, that's why the broken ⇧ isn't a big deal. Actions found with 1 letter can be run with ⇧⌘letter. Actions found with 2 letters now means tabbing to pane 2 and typing 2 letters. As you said, hardly more effort than the (broken) hold ⇧ and type the 2 letters. I can't remember ever doing the latter, anyway.

@skurfer
Copy link
Member

@skurfer skurfer commented Sep 27, 2012

This appears to be a bug in 10.8. The interpretKeyEvents: method should call insertText: on the same object, but in the "transcript" below, you can see that the first capitalized letter is sent to a different object (the first pane, in fact).

0x107b5c9a0 interpretKeyEvents: r
0x107b5c9a0 insertText: r
0x107b5c9a0 interpretKeyEvents: ⌫
0x107b5d360 interpretKeyEvents: S
0x107b5c9a0 insertText: S
0x107b5d360 interpretKeyEvents: G
0x107b5d360 insertText: G
0x107b5d360 interpretKeyEvents: ⎋

I had @pjrobertson try this on 10.7, and the messages are sent to the right place. I'll report it to Apple.

@skurfer
Copy link
Member

@skurfer skurfer commented Oct 9, 2012

Opened bug 12463358 with Apple.

pjrobertson added a commit to pjrobertson/Quicksilver that referenced this issue Nov 11, 2012
…uicksilver#1030

This fixes a bug by Apple, but also makes the feature more obvious.
Other fixes:

* Allow ⌘ (and ⇧) to show alternate actions (focus the 2nd pane) if the capslock key is on
* Don't let the 1st pane resign first responder if it's empty (more reliable than doing stuff in `acceptsFirstResponder`)
@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Sep 2, 2013

Just looked at this on 10.9 and still problematic. @skurfer any news on the radar report? Might be easier to see now that Apple have finally updated Radar... I wonder if it still requires "Safari 1.0 or higher" :P

I looked into it further and it seems that even though the first responder is correctly being changed the input manager doesn't pick it up. I changed the insertText: method to always send the text to the first responder and it seemed to work, but it isn't technically right since there might be cases where you want to send text to not the first responder.

Perhaps the correct solution would be to change handleShiftedKeyEvent: to call insertText: directly instead of keyDown:. I'm not sure if anything else could ever be send to handleShiftedKeyEvent: that isn't meant to be typed. Maybe a space? (if you press ⇧␣). But other things like ⇧ would already be handled so this might be the only exception (which we could account for)

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

4 participants