On Dec 20, 2012, at 11:50 AM, Kyle Sluder <k...@ksluder.com> wrote: > 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.
In the Finder's particular case, it may actually be blocked; I haven't put Finder under gdb to see how they're filling in the menu contents. The original goal for the presentation of this cursor was to show progress when a menu took a long time to draw, and specifically, when a WYSIWYG font menu was being presented and drawing each menu item in a different font could be quite slow. The menu drawing code tracks the mouse position during the drawing of the menu, and if the user moves the mouse in certain ways, the drawing of the menu will actually be stopped and control handled back over to the menu event tracking loop. I'm not sure that will work in the Finder case, though, depending on how the Finder is pulling its data. The original cursor presented here (from 10.0 through 10.7) was the old 8-bit animated watch cursor. In 10.8, we changed that cursor to use the busyButClickable cursor instead. -eric _______________________________________________ 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
