On Jul 8, 2012, at 19:32 , Charles Srstka wrote: > You have to get used to the new way of thinking about things. No height > constraint is literally telling the system, “I don’t care how high you make > this view. Make it 1 px high, make it 1,000,000 px high, it’s all the same to > me.”
So, I don't care, other than to say, "don't make it smaller than x" (that is, a >= height constraint). But aside from that I want it to satisfy the other constraint, which is to make it as big as the parent view, minus some margin. Given that the parent view can resize, an equal height constraint is not appropriate. But for the initial layout, assuming the constraints are not in conflict, the sizes specified in IB are an excellent starting point (BTW, IB should not allow you to add constraints that don't match the layout as it stands in IB). So, the way I see it, if I don't specify a constraint, it should still lay out the initial views based on the sizes (and positions) specified in IB, and then from there follow the constraints when resizing. This would not prevent it from getting too small, and is much more elegant than adding a constraint specifying a particular hight, which then requires mucking with priorities. > With no height constraint, the system doesn’t know how it should look at > startup, and therefore that picture with the bottom pane being half the > window’s height is just as legit as the bottom text view being one line high. On the contrary, it has a perfectly reasonable size at startup. Assuming, of course, that IB didn't allow me to add conflicting constraints. -- Rick _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
