Thanks, > AppKit 10.6 release notes say that the core of the problem is that the > animator proxy would run the animation in NSDefaultRunLoopMode. Now > it's done in NSRunLoopCommonModes. > > I guess you could run the run loop once in NSDefaultRunLoopMode > whenever you're running in a different NSRunLoopCommonModes run loop > mode? That seems like a very bad idea, but it would do the job.
Not sure I understand your idea and why it is bad. Could you elaborate? > Perhaps the most robust solution is to avoid the animator proxies > altogether until such time that you only support Snow Leopard. We > have a nice graph at http://update.omnigroup.com that you can use to > see how our users are updating their machines. Click the "Major > Version" button on the left to get a view across our entire installed > base that has enabled this data collection feature. Do you mean I should avoid using blocking animations and only use non-blocking? Never tried to use animator proxies, only NSAnimation directly, so I don't know if the proxies are blocking or non-blocking. The problem with this approach is that once I develop a solution that works on Leopard, say, using non-blocking animations and manually blocking the user from any input while the animation is in progress, there will be no benefit for me to change it in any way in the future when all users will have Snow Leopard, because the non-blocking solution is much more tedious than the blocking one. Assuming that I will be satisfied with the smoothness of the non-blocking animations, of course. _______________________________________________ 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 arch...@mail-archive.com
