Re: Setting key equivalent for menus depending on window
Re: Setting key equivalent for menus depending on window
- Subject: Re: Setting key equivalent for menus depending on window
- From: Kyle Sluder <email@hidden>
- Date: Sun, 20 Oct 2013 16:37:57 -0700
On Sun, Oct 20, 2013, at 01:14 PM, Charles Srstka wrote:
> I've played around with this a bit more, using the standard Xcode
> non-document app template, and its behavior is actually quite weird.
>
> 1. Typing a keyboard shortcut that's connected to one of the items
> currently in the menu works as you would expect. menuNeedsUpdate: gets
> called each time you type the shortcut. Typing ⌘-O repeatedly causes
> menuNeedsUpdate: to repeatedly fire, since the "Open" menu item has that
> shortcut (even though it's inactive).
>
> 2. However, shortcuts that are not connected to any menu item, like ⌘-E
> or ⌘-R,
In the default non-document template, ⌘E maps to Edit > Find > Use
Selection for Find.
> only cause menuNeedsUpdate: to fire the *first* time you type
> them. After you've typed one of them once, typing that shortcut again,
> *or any other invalid shortcut for that matter*, just causes the system
> to beep, and menuNeedsUpdate: is *not* fired.
This describes the behavior for key equivalents for disabled menu items
as well as key combinations that don't map to menu items.
>
> 3. Now here's where it gets weird: Typing ⌘-T of course brings up the
> Font panel like it always does, and causes menuNeedsUpdate: to fire each
> time it does so. *However*, if you type an invalid shortcut like ⌘-E or
> ⌘-R beforehand, subsequently typing ⌘-T will *not* cause menuNeedsUpdate:
> to fire, and it will never fire again for that shortcut until you
> actually click on a menu to cause it to draw.
This leads me to believe that NSMenu is populating the menu hierarchy
once and caching a mapping of key equivalents to menu items. Which is
unfortunate, and goes against the implication from the 10.6 AppKit
release notes that menus are fully repopulated once per event. So I
filed a bug: <rdar://problem/15274535> (NSMenu does not ask its delegate
to populate the menu for every key equivalent)
If you try to get around this by implementing
-menuHasKeyEquivalent:forEvent:target:action:, things get weirder still:
- This method is called for every potential key equivalent. This would
be useful, except:
- Even if you return NO, NSMenu still looks for a menu item with that
key equivalent and invokes its action, in direct violation of the
documentation for this method.
I cannot reconcile this behavior with the documentation or the intended
behavior of the frameworks at all, so I filed another bug:
<rdar://problem/15274476> (NSMenu performs key equivalent despite
delegate's insistence).
--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