Re: Arrgh IB constraints
Re: Arrgh IB constraints
- Subject: Re: Arrgh IB constraints
- From: Rick Mann <email@hidden>
- Date: Mon, 09 Jul 2012 09:54:52 -0700
Which videos? I've watched the first two on constraints, and don't recall any mention of nssplitview.
Sent from my iPhone
On Jul 9, 2012, at 8:33, Kevin Cathey <email@hidden> wrote:
>> BTW, if the NSSplitView hasn't been updated to use constraints in its own layout, then why does it and up changing the size at runtime? For that matter it seems like IB is expressly forbidding adding constraints to the NSSplitView's panes.
> There are known bugs with NSSplitView and auto layout on OS X 10.7 with both the runtime and with IB. Mainly, even if you say a particular pane should be >= 100 (for example), you can still drag the splitter right past the 100pt mark.
>
> See the WWDC videos from this year for more information…
>
>
> On Jul 8, 2012, at 9:01 PM, Rick Mann <email@hidden> wrote:
>
>> Thanks for all your help, Charles.
>>
>> So, I'm getting the exact same behavior your video shows. I definitely don't want the bottom pane to get any smaller, and I can enforce that the old way, but it seems pretty lame that they didn't update it to work with autolayout.
>>
>> I figured out why it was adding extra constraints to the top pane; I've got that down to four. There don't appear to be any problems there (other than an inability to specify a minimum height).
>>
>> It's the bottom that has so many issues.
>>
>> I just sent you the NIB file. I'm going to keep poking at it.
>>
>> BTW, if the NSSplitView hasn't been updated to use constraints in its own layout, then why does it and up changing the size at runtime? For that matter it seems like IB is expressly forbidding adding constraints to the NSSplitView's panes.
>>
>> --
>> Rick
>>
>>
>> On Jul 8, 2012, at 20:46 , Charles Srstka wrote:
>>
>>> On Jul 8, 2012, at 10:23 PM, Rick Mann wrote:
>>>
>>>> On Jul 8, 2012, at 19:01 , Charles Srstka wrote:
>>>>
>>>>> Argh, now this stuff is frustrating. I really, really wish those autoresizing masks would stay out of it when autolayout is on. I’m assuming this is the lower text view; could you post a screenshot of all the constraints for that view? They should be listed nicely in the Size inspector in IB.
>>>>
>>>> Do I need to turn off the translatesAutoresizingMaskIntoConstraints on all my views? It's annoying, because IB doesn't actually me specify autoresizing masks, and I'm using autolayout in the nib file.
>>>
>>> I don’t think so, since I just decided to try to recreate your nib file at home and see if I could reproduce the problem. I think I *have* found the source of some of your “broken constraint” messages; I had forgotten something about split views; seems my initial instinct was wrong, and it doesn’t seem to use constraints to determine the position of the splitter. Moreover, it doesn’t let constraints keep the user from resizing the bottom pane smaller than your minimum size for that view, and when you do it, you get a crapton of broken constraint warnings (both these things are probably due to NSSplitView being created well before the advent of constraints and not being completely savvy regarding them). So you actually want to make the priority of the “Bottom Space” constraints 999 instead of 1000. This allows the layout system to actually move these views below the bounds of its superview if it has to. You also want to make a “Greater than or Equal” constraint from the button to the top edge of the superview, so that the constraint system pushes it off the bottom rather than the top. This video will sort of demonstrate:
>>>
>>> http://www.charlessoft.com/extraneous_stuff/constraints.m4v
>>>
>>> Next, I’m going to try to see if I can figure out a way to screw this xib file up and make it exhibit the behavior you’re describing. I’m a bit suspicious of all those constraints for the top pane, which should really be only four, one for each edge of the text view. Could you expand that pane a bit more so I can see the descriptions of all those constraints a little better?
>>>
>>> Charles
>>
>>
>> _______________________________________________
>>
>> 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