Re: Implementing keyboard shortcuts for shifting focus
Re: Implementing keyboard shortcuts for shifting focus
- Subject: Re: Implementing keyboard shortcuts for shifting focus
- From: Quincey Morris <email@hidden>
- Date: Thu, 21 Nov 2013 09:56:53 -0800
On Nov 21, 2013, at 07:19 , 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.
I think you wrestled yourself to this conclusion too fast. With the proviso that I know nothing about your app or your intended users, I’d say there are *very* good reasons for making corresponding menu items.
— The biggest one, of course, is that the key equivalent solution becomes trivial.
— Your app is that much more robust, now and in the future, if you don’t have to invent an elaborate alternate solution.
— From a user perspective, the presence of menu items aids discovery. No matter how much you or your designers try to convince yourselves that discovery of an app-specific function is unnecessary, the fact remains that giving it menu room is the most egalitarian approach across all kinds of user mentalities.
— Putting functions on the menu enables them to be used with certain app automation tools (perhaps less important now in the days of sandboxing), and allows users to customize key equivalents (further) from system preferences.
> 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.
You are discouraged from doing that in NSWindow subclasses, but not NSView subclasses. I don’t know of anything preventing you from using a custom NSView subclass for the window’s content view, or you could use a custom view inserted just below the content view.
If the key event isn’t passed through as the ‘event’ parameter, then keep in mind that both NSWindow and NSApplication have ‘currentEvent’ methods, which may provide the information you want.
_______________________________________________
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