On Dec 1, 2008, at 2:17 PM, Keith Blount wrote:

Hi,

Many thanks for the reply.


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.

I haven't found this a problem with anything except the dynamically- created items. Everything else works fine with keyboard shortcuts that are defined in the System Preferences.

Yes, NSMenu is a little schizophrenic about this. If you implement menuHasKeyEquivalent:, then we will not populate the menu for key equivalent matching; however, if you insert menu items into the menu (either in menuNeedsUpdate: triggered by opening, or at another time) then KEs that you assign to the menu item may still be respected.

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:.

The trouble is that the styles were just an example. The application is quite a big one, and there are a good number of menus that get dynamically created - several of which are very likely to have changed between calls to -menuNeedsUpdate:. For instance, my application has a "Create Link to Document" submenu, which provides a list of documents in the application's source list so that the user can create links between documents. Given that the onus of the app is on structuring and moving documents around, the order and structure of this submenu is likely to change a lot. If I checked for every instance of a change in state to these menus, I'd have an awful lot of state-checking going on. And even with this state- change checking, it would still be slower. From my understanding and tests it seems that if -menuHasKeyEquivalent... isn't implemented, then every time a key combo is hit, the app populates all the menus and looks through them for the command matching the key equivalent. This gets incredibly slow when menus are being built dynamically - and so in my app, even with state- change checking, there would be many occasions when certain menus need rebuilding and thus key presses would become slower.

Sorry, that was a bit long-winded. I hope that makes sense.

The problem seems to be when the dynamic menus get built, preventing system shortcuts from affecting them...


It's not quite as bad as "all the menus are populated for every key combo." What is supposed to happen is, the first time a key combo is hit, menus are populated starting from the right until a match is found. But it also remembers the KEs for each menu, and when a remembered KE is hit, it first populates the menu that it was last found in. The only time it will routinely populate every menu is if a key equivalent is not found, and users normally don't care about the performance of unmatched key equivalents. If you're seeing different behavior, it would be worthwhile to investigate why.

In any case, your description makes sense, but now I'm not sure what behavior you want. In order to know if a menu has a user key equivalent, we need to construct the menu, which means populating it; if the menu is slow to construct then determining user key equivalents is necessarily slow as well. Absent more information, I have two suggestions, both of which depend on speeding up menuNeedsUpdate:

1) When you construct the menu, you can ask each item for its user key equivalent, and cache that keyed by title. When populating a menu for key equivalent matching, you can elide items that you previously found to have no user key equivalent. 2) Depending on the reason for the slow menu construction, you may be able to do less work for calls to menuNeedsUpdate: triggered for user key equivalents, such as avoiding loading icons. I think checking to see if the call occurs between NSMenuDidBeginTracking and NSMenuDidEndTracking notifications should help there.

-Peter

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to