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: Chuck Soper <email@hidden>
- Date: Wed, 12 Dec 2012 16:20:34 -0800
- Thread-topic: split views, best practices for 10.8?
Your message helps a lot. Yesterday, I finally got it working. I had been
trying to load a custom view with constraints from a nib file into the
cell of an NSTableView which was inside an NSSplitView. By isolating the
constraints in my custom view, I discovered the errors I was making. That
is, I first got my custom view working in the contentView of the window,
then moved it within the NSSplitView, then moved it within an NSTableView
(in the NSSplitView).
I have what I need for now, but I wanted to let you know that I discovered
with my implementation that I must call
setTranslatesAutoresizingMaskIntoConstraints:NO for my programmatically
created subviews or I get lots of constraint exceptions. I also override
+ (BOOL)requiresConstraintBasedLayout to return YES. For my
NSTableCellView subclass I do not call
setTranslatesAutoresizingMaskIntoConstraints: or override
requiresConstraintBasedLayout. My custom view is a subview of my
NSTableCellView subclass.
One more question below...
On 12/11/12 11:08 AM, "Peter Ammon" <email@hidden> wrote:
>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.
When you say "controls that have traditionally positioned their subviews,
like NSTableView" is 'their subviews' referring to NSTableCellView but NOT
a programmatically created subview within NSTableCellView? For my case,
this was true.
I did read the "Adopting Auto Layout" section in the "Cocoa Auto Layout
Guide" but I think that I need to re-read the section. The info in the
"Adopting Auto Layout" section seems critical to developers writing new
10.8 applications, and the title and the fact that it's the last section
of the guide suggests that the info is only applicable to adopting Auto
Layout for existing apps.
>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.
Thanks! This info is helpful and valuable. I'll look more into adjusting
priorities.
>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.
I had tried this, and it's somewhat helpful. Resolving some constraints
can be challenging.
>>
>> 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
Most definitely!
Chuck
_______________________________________________
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