Bear in mind most of the animations in the OS predate Core Animation, so tend to behave a little differently.
Even so, take something like the Genie effect. It's possible to kill the animation midway and have a distorted, but usable window. On 17 May 2010, at 17:28, Tobias Jordan wrote: > You are right Uli, I'd definitely like to let the user decide what to do but > when taking a look at Apple's OS X animations I have to say it's always > completely blocking the UI so I thought that's a default behavior. I don't > know yet whether I'll need to disable the MainMenu or not, it depends on the > animation duration but it shouldn't be more than a second. > > Thanks for taking the time to reply to my issue! > > — Tobias > > On May 17, 2010, at 6:21 PM, Uli Kusterer wrote: > >> On May 17, 2010, at 6:08 PM, Tobias Jordan wrote: >>> Thanks for your nice ideas guys, both solutions, subclassing NSApplication >>> (overwriting -sendEvent:) and calling >>> -nextEventMatchingMask:untilDate:inMode:dequeue: in a loop work. Now the >>> only thing that's missing is disabling the application's menu since it's >>> still clickable during animation. Is there a way to disable a whole >>> MainMenu or maybe all items in it? >> >> Can't you just not not ask for mouseDown events in your event mask while >> running your event loop? My guess would be that that would keep any menus >> from opening. >> >> Anyway, this sounds like a very weird use case. Why do you want to disable >> everything during an animation? Usually animations should be short enough >> that this shouldn't be a problem, and if the user wants to do something, why >> keep them from multi-tasking? Animations are intended as indicators, and if >> a user doesn't want to watch an indicator, that should be their choice to >> make. >> >> Anyway, to try and disable the menu bar, I guess you could try to use the >> responder chain. After all, that's how they usually get enabled. Make your >> object an NSResponder and insert it in the chain so it's the only one that >> gets asked, somehow? Or have it claim to implement any action (Make >> respondsToSelector: always return YES?) and then return NO from each >> validateMenuItem: call? Never done that, so don't know if that's really >> needed. There may be a better way, see the docs for NSResponder and >> NSApplication methods and see if any of them makes sense. I think there was >> a noResponderForAction: method (or something like that), maybe that is for >> that purpose? Also, if you put up a modal NSPanel using NSApplication's >> runModal... methods, that'll disable the menus. Maybe that could be (ab)used. >> >> -- Uli Kusterer >> "The Witnesses of TeachText are everywhere..." >> >> >> > > _______________________________________________ > > 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/cocoadev%40mikeabdullah.net > > This email sent to cocoa...@mikeabdullah.net _______________________________________________ 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
