Re: 10.7 Full-Screen transition animation corrupts my UI - how to avoid?
Re: 10.7 Full-Screen transition animation corrupts my UI - how to avoid?
- Subject: Re: 10.7 Full-Screen transition animation corrupts my UI - how to avoid?
- From: Motti Shneor <email@hidden>
- Date: Sun, 22 Jul 2012 21:56:53 +0300
- Resent-date: Mon, 23 Jul 2012 21:07:15 +0300
- Resent-from: Motti Shneor <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: Cocoa-Dev List <email@hidden>
Thanks, guys, for all the help.
Of course the implementation below is meaningless, and also isn't the right thing to do --- It should have returned min/max size if at all.
I only put it to see if I get there in the debugger (set a breakpoint on the strange lower-than-minimal situation).
- (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize {
NSSize min = [sender minSize];
NSSize max = [sender maxSize];
if (frameSize.width > max.width ||
frameSize.height > max.height ||
frameSize.width < min.width ||
frameSize.height < min.height)
return sender.frame.size;
else
return frameSize;
}
The application UI is dynamic and quite complicated. It's built from plugin-like modules, each with its own code and .xib with its min/max sizes. After I load all my modules I lay-out my main window with these sub-views, and calculate the overall min/max content size for the window. I then setContentMinSize: and setContentMaxSize: This mechanism works fine. Calculations are right, and have been thoroughly tested.
There is no way I missed setting the window delegate, because
1. I set it for sure (double-checked the code and .xib, and my NSWindowController is also the delegate for its window).
2. many other window-delegate calls are being called without a problem.
3. This very implementation DOES GET CALLED, except for in the transition to FullScreen!
I can send in any log that will shed light of this behavior, but spending the last 2 months rolling my own "auto-layout" mechanism, believe me I know when window-size is getting wrong.
The snippet I used, is where the problem affects the user --- there is some split-view with several internal "panels" (sub-views) and one of them is automatically collapsed (because the split-view becomes too small for all the panels in their min-size). I have min/max sizes all the way down. So it's really weird for a user to have one panel auto-collapse, when enlarging the window to full-screen.
On 22 ביול 2012, at 20:22, Quincey Morris wrote:
> On Jul 22, 2012, at 02:00 , Motti Shneor wrote:
>
>> - (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize {
>> NSSize min = [sender minSize];
>> NSSize max = [sender maxSize];
>> if (frameSize.width > max.width ||
>> frameSize.height > max.height ||
>> frameSize.width < min.width ||
>> frameSize.height < min.height)
>> return sender.frame.size;
>> else
>> return frameSize;
>> }
>
> AFAICT this implementation doesn't do anything. As was mentioned in another thread yesterday or the day before, and in the class documentation, the min/max constraints have already been applied when this method is called, so re-testing the constraints is pointless.
>
You're right. This was only debug-code to let me see if this delegate gets called with lower-than-minimum size, and if its implementation could save me in transition-time to full-screen. Unfortunately, it doesn't
> Of course, that doesn't explain how the window gets smaller than it should be.
>
> (Also, it seems wrong to return sender.frame.size, since that would prevent the window from actually getting pinned to the limits enforced by this method, if there were any.)
>
See above.
> (Also, if you're using min/maxContentSize as shown in your other code sample, you should check that everywhere rather than min/maxSize in some places. The documentation says the min/maxContentSize constraint "overrides" min/maxSize, not "sets" it.)
As explained above, I have a whole mechanism for that. Every module calculates its own min/max size from its own constraints and its sub-module constraints, and "reports" it up. This is done recursively, and the window's contents view is just at the top.
>
>> 2012-07-22 11:44:01.178 AT&T Connect[19369:407] Window min content size:{1001, 579} current size {1001, 517}
>>
>> As you can see, my window is forced to get to 517 pixels height, despite my imposed minSize of 579 pixels, and in spite of the implementation you suggested.
>
> It would be slightly more reassuring to log all of the window's size, with min and max, as well as the content size, with min and max, as they are this moment in execution.
>
> Incidentally, NSWindow's 'setFrame:display:' is documented to ignore the min/max sizes. Is there any place you're calling this yourself?
Nope. Never. My windows are plain NSWindow instances until now, but I could create a subclass, for the sake of pinning down a "setFrame:display:" with lower-than-min size, just to prove it happens.
One thing you say raises a question, though. How can minContentSize: "override" the "minSize" ? these are two different sizes, isn't it?. I'm using setContentMinSize because I don't know how to calculate the "minSize" which also depends on the presence of tool-bar, title-bar and other window parts that can change with versions of the OS. Am I wrong here? should I directly call setMinSize/setMaxSize on my windows?
I assumed that the window's minSize is calculated from its contentMinSize, plus the other parts of the window.
Motti Shneor
_______________________________________________
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