Re: UI blocking
Re: UI blocking
- Subject: Re: UI blocking
- From: Mike Abdullah <email@hidden>
- Date: Mon, 17 May 2010 17:59:08 +0100
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 (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
_______________________________________________
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