Why doesn't my NSWindow resize when I change auto layout constraints?

Question

I think I have arrived at a decent understanding of how auto layout works in Interface Builder (ha). I've got a .xib that says "No auto layout issues". Here's two screenshots of it, with nothing selected and with things selected so you can get a sense of the constraints at work:

Now I would like to, eg, decrease the vertical spacing between the "Total thumbnail size:" label and the "Use TIFF" radio button matrix. So I click on things to get that constraint selected, and I edit the "Constant" value of it to change it from 47 to, say, 30. When I do so, I expect that the window will shrink vertically by 17, so that all constraints continue to be obeyed. Instead, it shifts the vertical position of the "Size & format" label, breaking its vertical constraints in so doing, and then complains about "Content priority ambiguities" involving a bunch of items; here are screenshots of that state, showing the priority ambiguities:

It wants me to change vertical compression resistance priorities and/or vertical hugging priorities to allow it to compress/expand something away from its intrinsic size; but I don't want to do that. I want all of those items to retain their intrinsic size, and I want the window to resize. I can resize the window manually, by -17, and move the various items into their proper positions, and then it says "No auto layout issues" again; so there is really nothing difficult or ambiguous about this situation except that for some reason it refuses to resize the window as it ought to. So, my question is: how do I avoid it doing this, and have it just resize the window and move things properly on its own? I don't understand why it's so confused; it seems to me that there is a clear, unambiguous chain of vertical constraints from the top to the bottom of the window, and changing one of those constraints ought to simply force the window to resize. I've tried using "Update Frames" but it doesn't seem to help.

I think I have uploaded the .xib file, prior to the constraint change, to my Dropbox here: https://www.dropbox.com/s/vp90s1fh692i8pi/CopyThumbs.xib .

Answer 1

I grabbed your xib and played around with a few things... I can only find two items that would be causing problems.

But first, a couple tips (based on my experiences):

• Start by making your window larger than you'll need
  • with your layout, make it maybe 600 x 600
• As you add UI elements add only Vertical and Leading constraints (we can center the Cancel/Copy buttons later
  • of course, I also mean Horizontal inter-element constraints
• For wrapping multi-line labels (ie your "Choose how you want..." label), give it a specific Width constraint
  • 285 is a good value for your layout... you can adjust this later as desired
• Don't give a Bottom constraint yet

Your xib now looks like this (I left your Cancel button Leading as you had it >= 50 ):

Now you can tweak your vertical spacing constraints, without worrying about the window frame sizing.

Once you're happy with the layout, you only need one Trailing constraint (on your multi-line label) and one Bottom constraint (on the Cancel button).

Add those constraints, and your window frame should resize itself. If it doesn't, selecting "Update Frames" should fix it.

The two problem items that I mentioned... you have Content Hugging Priority on both "Matte thumbnails..." and "Frame thumbs..." set to 250 . Those should both be at their default of 750 .

Your Cancel/Copy buttons should horizontally center themselves, with your current constraints. I'd suggest, though, putting them in a StackView, and then constraining that StackView Top to the element above it, and Bottom to the Superview... and thenHorizontally Centered.

---

Edit

Note: I don't work for Apple... these comments are simply my anecdotal observations.

First, Interface Builder is (as we all know) not the same as run-time output. It's close, but it's certainly not identical.

Second, IB makes a lot of assumptions -- while at the same time, it has no idea what we're going to do next.

A perfect example from iOS development:

If, in IB, I add a UIScrollView to a view without adding any content to it, IB will endlessly complain about Content Size Ambiguity ... and won't even position the view to reflect the constraints.

That's because IB doesn't know that I'm going to add subviews (with proper constraints) at run-time. And the only way to get rid of the Red "Error" messages is to add a subview in IB which I would then have to immediately remove at run-time (ugh).

IB also tends to complain / warn about "Fixed width constraints may cause clipping" and, as you're experiencing, "Localization Issue: Trailing constraint is missing."

It doesn't matter if my label is static (text will never change) or if I have the constraints set exactly how I want them. IB is going to try its darnedest to convince me that I need to change things.

This is one of the reasons many people move away from using Storyboards / XIBs. For my job, we don't use any XIBs, and the only Storyboard we use is for the LaunchScreen (iOS).

I might lay things out in IB to start, and to get a good idea of how I want my layout to look, but then I write it all in code for the end result.

Not that I'm saying this approach is better... plenty of times when I think to myself "Hey, I can drag/drop UI elements, add constraints and IBOutlet / IBAction connections, and I'd be done already!"

Again, though, just my personal thoughts on the topic.