On Thu, Dec 20, 2012, at 11:30 AM, Eric Schlegel wrote: > You're actually seeing the cursor in Finder (and other apps) when opening > a menu that requires a significant amount of time to open or render > (which the "Open…" menu item often does). Menus in OS X apps (both Carbon > and Cocoa) are still implemented using the Carbon Menu Manager, which > accesses this cursor via the Carbon API SetAnimatedThemeCursor. > > I don't believe there's currently any NSCursor API for accessing this > cursor; a Radar would be appropriate.
The cursor isn't listed in the HIG: https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/UEGuidelines/UEGuidelines.html#//apple_ref/doc/uid/TP40002720-SW4 That leads me to believe the correct Radar to file might be to remove the Menu Manager's use of this icon. (Maybe by reimplementing the menu system in Cocoa so event tracking works again? :P) Then again, the HIG nowadays is just as much of an ex post facto justification of design decisions as it is a guideline. But I'm actually curious if the menu manager works in the way the cursor implies. If the Finder is taking a long time to build the menu, doesn't that mean the process is blocked? I don't see any way for NSMenu to call back to its delegate to fill the menu on a background thread/queue. --Kyle Sluder _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
