Re: Rebuilding menus (menuNeedsUpdate:) and System Preferences keyboard shortcuts.
Re: Rebuilding menus (menuNeedsUpdate:) and System Preferences keyboard shortcuts.
- Subject: Re: Rebuilding menus (menuNeedsUpdate:) and System Preferences keyboard shortcuts.
- From: Peter Ammon <email@hidden>
- Date: Mon, 1 Dec 2008 13:57:24 -0800
On Dec 1, 2008, at 12:49 PM, Keith Blount wrote:
Hi,
My application has several menus that get built dynamically,
depending on user settings. For instance, there is a "Styles" menu,
which lists styles the user has defined, and a "Script Elements"
menu, which again, provides a list of user-defined options that
apply a certain format to a range of text.
However, it seems that dynamically-built menus have a problem when
it comes to keyboard shortcuts defined via the System Preferences -
as in, the keyboard shortcuts don't always work.
At first I thought the solution was obvious: I was building these
menus as needed, in the NSMenu delegate method, -menuNeedsUpdate:
This method only gets called when the user goes to look at the menu.
So, if these dynamic menus were only built in -menuNeedsUpdate:,
then clearly the keyboard shortcuts defined in System Preferences
for any items in such menus would note work until after the user had
opened the menu at least once (thus populating it in -
menuNeedsUpdate: and allowing the defined shortcut actually to apply
to something, because before this the menu wouldn't have existed).
If you implement menuHasKeyEquivalent:, then the menu does not get
populated for matching key equivalents; NSMenu assumes that your code
does not need it to be populated. This puts the onus of supporting
user key equivalents on the app itself, and since there's no easy way
for an app to implement this, implementing menuHasKeyEquivalent: is
not a good idea unless the menu has custom KE handling or should never
have a KE.
My solution was to build these menus whenever the user settings
changed. So, if the user added or deleted a style, the menu would
get rebuilt, as well as rebuilding it in -menuNeedsUpdate:. However,
this still doesn't seem reliable. When opening another window, the
keyboard shortcuts defined via System Preferences still don't
operate in the new window until after the menu has been opened - and
yet NSLogging shows that the menu is getting built before this and
even seems to have a keyboard shortcut attached... Very strange.
So, my question: what is the best way of building menus dynamically
whilst ensuring that any keyboard shortcuts defined in System
Preferences will catch them and apply to them?
I am implementing -menuHasKeyEquivalent:... and returning NO. It
seems that if I don't implement this method, then keyboard shortcuts
work for dynamically built methods... But not implementing this
method makes all the keyboard shortcuts in my app work very, very
slowly, so leaving it out isn't an option...
There's no reason why this should be slow. Have you tried profiling
it with Shark? Where is its spending its time?
Perhaps you are completely rebuilding the menu every call to
menuNeedsUpdate:. The menu state is not disturbed between calls to
menuNeedsUpdate:, so you can detect if the user has added or deleted a
style since the last update, and if not, you do not need to do
anything in menuNeedsUpdate:.
-Peter
_______________________________________________
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