Re: NSPopupButton to display fonts in the fonts themselves
Re: NSPopupButton to display fonts in the fonts themselves
- Subject: Re: NSPopupButton to display fonts in the fonts themselves
- From: Peter Ammon <email@hidden>
- Date: Thu, 9 Jul 2009 15:11:49 -0700
On Jul 8, 2009, at 8:02 PM, Graham Cox wrote:
On 09/07/2009, at 11:06 AM, Peter Ammon wrote:
- (BOOL)menu:(NSMenu *)menu updateItem:(NSMenuItem *)item atIndex:
(NSInteger)index shouldCancel:(BOOL)shouldCancel
is actually invoked on some sort of background thread/queue, so
implementing these methods (the above + numberOfItemsInMenu:) in
your menu delegate would allow you to update each item with the
attributed title fairly simply and it wouldn't drag your main
thread's performance down.
--Graham
What this method does is check at regular intervals for events that
would cancel tracking. If one is detected, it passes YES for
shouldCancel. So if your design is "if the user clicks on the
menu, sit and spin until it's built," then you could use this API
to detect cancellation, to stop spinning.
However, "sit and spin" isn't a very good user experience, and
Leopard allows you to append items to a menu in the menu bar while
it is open. So for menus that may take a while to build, consider
appending the items as they come in (like the Airport status item),
or showing a "Building..." item until you're ready to add the
complete set of items.
OK... this clarification has confused me a little though.
Can this delegate method be used as suggested or not? In other
words, if I use it to change each item's plain title to a more
complex attributed title, will that cause a performance problem?
What I expect to see is that I pop open the menu and see plain
titles, gradually being replaced one by one with the attributed
titles but menu tracking proceeds normally.
No, the menu:updateItem:atIndex:shouldCancel: API does not support
that. Every item gets updated before the menu is shown. It is
entirely synchronous.
If you want to set the attributed titles while the menu is opened, you
can do it by installing a timer from the delegate callbacks, like
menuWillOpen:, or NSMenuWillBeginTrackingNotification.
But if my code inside this method takes significant time, will that
make tracking sluggish? Also, if menu tracking ends, are the
remainder of the items passed to this method or does it stop there?
Every item gets passed to the callback, until the items are exhausted
or the callback returns NO.
If so, I. Savant's original plan would probably be better so that
the titles can be processed in the background even if the menu isn't
shown (though in that case it could be wasted work if the user
*never* opens the menu).
menuWillOpen: is probably the best place to create a timer to start
installing the attributed titles. This will ensure that they only get
installed if the menu is going to be displayed.
Hope this helps,
-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