Re: Implementing keyboard shortcuts for shifting focus
Re: Implementing keyboard shortcuts for shifting focus
- Subject: Re: Implementing keyboard shortcuts for shifting focus
- From: Kyle Sluder <email@hidden>
- Date: Thu, 21 Nov 2013 10:31:08 -0800
> On Nov 21, 2013, at 7:19 AM, Matthew LeRoy <email@hidden> wrote:
>
> My designers are calling for three keyboard shortcuts (Command+Option+G/O/N) that move focus to three particular areas of the document window. However there are no corresponding menu items for these commands in the application menu, so assigning key equivalents to those menu items and having it "just work" isn't an option.
For what it’s worth, most Mac apps that offer keyboard shortcuts for accessing pieces of UI use menu items for this. See the Window menu in iTunes, or the View menu in Xcode.
> I think two can be crossed off the list from the start. Inserting characters into text is obviously not what I'm after, and from what I can tell, despite the name sounding very appropriate to what I'm trying to accomplish, "keyboard interface control" events seem to only deal with shifting focus within the key-view loop using the Tab and Shift-Tab combinations.
This is correct. Think of “keyboard interface control” as “actions relative to the first responder,” like navigating forward and backwards through the tab order.
(In fact, keyboard interface control and text insertion follow the same code path up to -interpretKeyEvents:, which determines what kind of action an individual keypress should perform.)
> That leaves me with key equivalents, keyboard actions, and application specific processing.
>
> Overriding performKeyEquivalent: seemed like a good option -- just override it on the document window's NSWindow subclass, since these are really window-level operations I'm trying to implement -- but then I saw the note in the docs that "NSWindow subclasses are discouraged from overriding performKeyEquivalent:" (albeit without any explanation as to why). Still, I gave it a shot, and found that the NSEvent parameter was always nil, which is really quite useless.
Subclassing NSWindow is extremely rare. (For some values of “extremely”.) Cocoa tends to eschew subclassing for other design patterns when it comes to customization.
Check out the Handling Key Equivalents section again: https://developer.apple.com/library/mac/documentation/cocoa/conceptual/eventoverview/HandlingKeyEvents/HandlingKeyEvents.html
You are discouraged from overriding -[NSWindow performKeyEquivalent:] because its default implementation is more flexible: it sends -performKeyEquivalent: recursively down the window’s entire view hierarchy, stopping when a view returns YES (meaning “I handled it”).
In other words, unlike key events which are directed towards the first responder and bubble up until they fall off the responder chain, key equivalents are sent to the root of the view hierarchy and filter down until they are claimed.
Thus the subclassing should happen at the view level, not the window. As it turns out, some NSView subclasses already override this method. This is how NSButton implements the Return-invokes-default-button behavior, for example.
If you’re dead-set on avoiding menu items, you could subclass NSView and make instances of these views the parents of your pieces of UI. Their -performKeyEquivalent: methods would handle your keystrokes.
But please reconsider using menu items. Then your users can discover them naturally and customize them in System Preferences.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden