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: Quincey Morris <email@hidden>
- Date: Sun, 22 Jul 2012 14:25:49 -0700
(BTW, your reply from which I'm quoting below wasn't CC'ed to the list, but it looks like it was intended for the list. I'll let you go ahead and repost if that was your intention.)
On Jul 22, 2012, at 11:56 , Motti Shneor wrote:
> 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.
Here's what the documentation for 'setMinSize:' says:
> The setContentMinSize: method takes precedence over this method.
I took this to mean that the window maintains separate 'minSize' and 'contentMinSize' properties, each of which can be set or not set, and if they're both set, 'contentMinSize' wins. However, I just tried it in an existing project, and this isn't what happens. (See below.)
You can "convert" between window frame and content rect using these class methods:
+ (NSRect)contentRectForFrameRect:(NSRect)windowFrame styleMask:(NSUInteger)windowStyle
+ (NSRect)frameRectForContentRect:(NSRect)windowContentRect styleMask:(NSUInteger)windowStyle
However, things are a bit messier than that, since these methods obviously don't take the toolbar into account. The NSToolbar programming guide says you can calculate the toolbar height by subtracting "the height of the window’s content view from the window’s height", and gives this sample code (in part):
windowFrame = [NSWindow contentRectForFrameRect:[window frame] styleMask:[window styleMask]];
toolbarHeight = NSHeight(windowFrame) - NSHeight([[window contentView] frame]);
Interestingly, this means that the window's content rect is *not* the same thing as the window's content view's frame rect. That's probably what's going wrong in your code -- looking back at what you posted, I think you're assuming that contentMinSize is the content view frame's min size, but it isn't.
Furthermore, there's an additional level of messiness, in general. The documentation's 2009-era statement about the toolbar height is (I think) now incorrect, because windows now also have a contentBorderThickness property, potentially at the top and bottom of the window, which needs to be taken into account.
So, here's what I found in testing, with an existing project that has a window minimum height that shows as 500 in IB, and which has a toolbar permanently visible, and which is given a contentBorderThickness of 30 for the bottom border in the window controller's windowDidLoad.
When I stop at a breakpoint after the window is displayed, contentMinSize.height is 500 and minSize.height is 578. That's a difference of 78.
If I set contentMinSize.height to 700 (i.e. +200), minSize.height changes to 778. Same difference of 78. However, if I set minSize.height to 778, then contentMinSize.height changes to 756 *and minSize.height actually changes to 834*. Still a difference of 78, so the two properties are still linked, but I have no idea where 756/834 came from. Did the contentMinSize property "take precedence"?
Er, QED, proof left as an exercise to the reader, gotta go, let's do lunch, my people will call your people. ;)
_______________________________________________
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