Re: Arrgh IB constraints
Re: Arrgh IB constraints
- Subject: Re: Arrgh IB constraints
- From: Rick Mann <email@hidden>
- Date: Sun, 08 Jul 2012 19:11:13 -0700
On Jul 8, 2012, at 19:01 , Charles Srstka wrote:
> You might have a case of ambiguity here (although the screenshot seems to suggest you don’t, which is odd). Ambiguity is why IB keeps liking to add stuff — you’ve got it so that the pane size is flexible, and the view sizes are flexible, but there’s no real indication of how things should start out. The physical sizes of stuff in IB is irrelevant to how things will display at runtime — the constraints are all that the system uses. So, try pinning the lower view’s height. That will let the system know how tall you want that view to be. However, so that it’ll still be resizable, set the height contraint’s priority to something relatively high, but less than 1000 (required). Maybe 750 or so. Then, the system will honor your height constraint when setting up initially, but will let your user break it without complaining after the fact.
Wow, really? I think it SHOULD use the actual sizes as specified in IB. There's a wealth of information there, and I can't think of a better way to specify what the default window should look like.
The idea of adding a height constraint really rubs me the wrong way, as I don't want to constrain it (other than to make it a >= constraint). By the way, how DO I add such a constraint? I tried to Pin the bottom pane's custom view, but all those options are disabled.
Oh, I was able to add a >= 22 px height constraint to the text view (but not its parent), but then the entire window at run time was a different height, and the constraint did not do what I expected: it pushed the bottom edge of the text field off the bottom edge of the window as soon as it got down to 22 pixels high. So, it constrained the height, but not the parent view's height.
>
>> I do get several complaints about constraints on launch:
>>
>> 2012-07-08 18:19:45.577 Console[49250:403] Unable to simultaneously satisfy constraints:
>> (
>> "<NSAutoresizingMaskLayoutConstraint:0x7fde9b83a160 h=--& v=--& H:[NSView:0x1029952d0(0)]>",
>> "<NSLayoutConstraint:0x1029960a0 H:[NSTextField:0x7fde9b81fc10]-(79)-| (Names: '|':NSView:0x1029952d0 )>",
>> "<NSLayoutConstraint:0x102995e80 H:|-(5)-[NSTextField:0x7fde9b81fc10] (Names: '|':NSView:0x1029952d0 )>"
>> )
>>
>> Will attempt to recover by breaking constraint
>> <NSLayoutConstraint:0x1029960a0 H:[NSTextField:0x7fde9b81fc10]-(79)-| (Names: '|':NSView:0x1029952d0 )>
>
> 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.
It doesn't show anything in the size inspector, just content hugging priority and content compression resistance priority. The outline view in one of the posted images shows more constraints, but not terribly descriptively.
--
Rick
_______________________________________________
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