Re: split views, best practices for 10.8?
Re: split views, best practices for 10.8?
- Subject: Re: split views, best practices for 10.8?
- From: Peter Ammon <email@hidden>
- Date: Tue, 11 Dec 2012 11:08:03 -0800
On Dec 8, 2012, at 4:19 PM, Chuck Soper <email@hidden> wrote:
> Hi Peter,
>
> On 11/27/12 6:33 PM, "Chuck Soper" <email@hidden> wrote:
>> On 11/27/12 2:11 PM, "Peter Ammon" <email@hidden> wrote:
>>
>>> Hi Chuck,
>>>
>>> Autolayout works well with NSSplitView in 10.8.
>>
>> Perfect. Thanks for that confirmation.
>
> Does that mean that in 10.8 (and not 10.7) that it's fine to call
> setTranslatesAutoresizingMaskIntoConstraints:NO for subviews of
> NSSplitView?
For controls that have traditionally positioned their subviews, like NSTableView, NSSplitView, NSTabView, you can think of them as owning the translatesAutoresizingMaskIntoConstraints properties of its subviews, and it will set it appropriately depending on whether the view uses autolayout or not.
In 10.8, NSSplitView will set it to NO for its subviews if it is in the modern autolayout mode, because it positions its subviews using autolayout. If you set it to NO yourself, it's harmless in 10.8 but will cause problems in 10.7. Leaving it alone is fine.
> And, that NSSplitView won't add constraints that conflict with my subviews?
It adds constraints that make sense for a split view. For example, in a two pane split view, NSSplitView adds constraints that align the first view's left edge is to the split view's left edge, the last view's right edge to the split view's right edge, and that make a gap in between the views. So if you tried to add constraints that would force one of the views outside of the split view, or that would change the order, then you'll get conflicts. This is a good thing, because the most likely reason you would add a constraint like that is by mistake.
However, you can and should add constraints that complement and enhance NSSplitView's layout. For example, you could add a minimum or maximum width constraint on one of its subviews; then when the user drags a split or resizes the window, it won't make that view too big or too small. You can also align a button outside the split view to one of the views inside it. Plus/minus buttons often work this way.
And don't overlook the power of adjusting priorities. If you wanted to prevent a split view from clipping a text field, say, you could just raise the text field's content compression resistance priority to above that of the split view's holding priority. You can do that directly in IB.
By the way, if you're interested in what the constraints are, you can just log them out: NSLog(@"%@", [splitView constraints]). Though of course these constraints are considered internal implementation details, so you should not depend on their existence, order, etc.
>
> The "Cocoa Auto Layout Guide" says not to call
> setTranslatesAutoresizingMaskIntoConstraints:NO for subviews of
> NSSplitView, but I think that's for 10.7 and the statement is no longer
> true for 10.8. Is that correct?
It's harmless to call in 10.8, because as I said above NSSplitView will call it.
>
>
> I had been attempting to use constraints in a subview of NSTableCellView
> (and call setTranslatesAutoresizingMaskIntoConstraints:NO). I was getting
> lots of "Unable to simultaneously satisfy constraints" exceptions.
> NSTableView was adding NSAutoresizingMaskLayoutConstraint instances that
> were conflicting with my subviews. After I read the "Adopting Auto Layout"
> section in "Cocoa Auto Layout Guide" this makes sense. The reason I had
> not read the "Adopting Auto Layout" section was because I was writing a
> new app for 10.8 and thought the section was specifically for adopting
> existing code for auto layout.
Ah. As you discovered, NSTableView positions its subviews using setFrame:, so it's best to not adjust translatesAutoresizingMaskIntoConstraints on subviews of NSTableView.
Hope that helps!
-Peter
_______________________________________________
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