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: Keith Blount <email@hidden>
- Date: Tue, 2 Dec 2008 08:47:59 -0800 (PST)
Many thanks again for your reply, much appreciated, and for your suggestions. Actually, I think I might be able to improve things with a better use of -menuHasKeyEquivalent..., if I understand correctly.
> 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.
This fits with the behaviour I'm seeing. The trouble is that, depending on the size of the project, some of the menus can be very big, so the first time the user hits each key equivalent, there can be an unacceptable delay as these menus get re-populated. These particular menus do have icons, so your second suggestion might help here. However, thinking about this some more based on the information you have given, I've realised that my initial example of the styles and script elements menus most likely isn't the problem at all. The problem is the larger menus that get built based on the contents of the project, (for things such as, Link to Document > [list of documents as menu items], Append Selected Text to Document > [list of documents as menu items] and so on). Whilst it is likely that the user would apply key equivalents to the menu items for styles and script elements, it is highly unlikely that the user would ever apply a key equivalent for one of
the items in these large menus that list the documents in the project. So if I could use -menuHasKeyEquivalent... to tell the program not to look for key equivalents in certain menus - these bigger menus - but to carry on as if the delegate method wasn't implemented for the other menus and populate them as normal, then I think things would be fine.
The trouble is - unless I'm doing something wrong, which is likely - that -menuHasKeyEquivalent... doesn't seem to work like this; it seems to be an all or nothing deal. I can return NO, in which case none of the menus get populated. But if I return YES, the application crashes - it seems that I have to fill in the pointers passed into the method. But what I really want to do is return "NO" for the larger menus that will have no key equivalents, but for the other menus have it act as though the delegate method isn't implemented - which "YES" doesn't seem to do. Is there a way to do this without having a different delegate for the menus that get populated with the project contents (i.e. implementing -menuHasKeyEquivalent... to return NO for the delegate of those menus and not implementing it for the delegate of the other menus)? Having a separate delegate object just to perform this one task seems a bit of an awkward workaround, which is why I think I
must be using -menuHasKeyEquivalent... incorrectly.
Apologies again for more long-windedness!
Thanks again and all the best,
Keith
>
> 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 (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