Xcode User Interface Builder "Add Missing Constraints" adds random constraints

Question

Created Feb ’21

Replies 4

Boosts 0

Views 1.1k

Participants 2

Is the "Add Missing Constraints" function in the Xcode User Interface Builder known to work properly, or should this functionality be avoided?

Conceptually, constraints make perfect sense. Each element is declared as having a behaviour relative to other elements, allowing the layout to be calculated automatically. In my case I have a number of elements, and each element needs to be rendered below the previous one. So far makes sense.

In practice, adding constraints is very hit and miss. No matter how carefully I add the constraints by hand, I get warnings "height is ambiguous" or "vertical position is ambiguous", but none of these messages are ever specific enough to explain what's actually wrong.

Eventually you select the "Add Missing Constraints" option, and at this point chaos is unleashed. Constraints are added between elements that have no obvious relation to one another. The third element down immediately gains a constraint relative to the top of the window, for no obvious reason. Constraints suddenly have constants added, none of which make any sense. Elements are now off the screen, with no obvious explanation.

At this point the constraints are wrecked, and the UI has to be redeveloped from scratch.

My question is this: Is there a specific technique that should be used to handle constraints when building a UI? Is there a special order things should be done in? Should the UI be avoided and all constraints be declared programmatically?

The user interface is supposed to be the Mac's core strength. I can't see how any user interface gets developed with tools this unfinished. Can anyone shed any light of how to approach practical UI design on the Mac?

Boost

Answer 1

Claude31 OP

Feb ’21

Is the "Add Missing Constraints" function in the Xcode User Interface Builder known to work properly, or should this functionality be avoided?

I personally avoid it. Or more precisely I fire it to see what is proposed but then immediately undo as it often add extraneous constraints (they are not random, but the logic may be hard to understand).

I declare as many constraints as possible in IB, much easier than programmatically.
I may also create an IBOutlet for some constraints when I need to adapt (usually changing constant) in certain circumstances (such as for very small size screen).

"height is ambiguous" or "vertical position is ambiguous",

That is often because the reference element (to which the constraint is defined), is missing a vertical position.

Is there a specific technique that should be used to handle constraints when building a UI?

This is not a specific technic, just the way I proceed.
I try to select "reference" elements that I position in the top view.
Then other elements will be constrained relative to it.
It may also be useful to create subviews that will hold some related objects.
Then constraints are defined for the subview and objects inside are constrained with respect to their subview.
A last thing, when there are many constraints, I give them an ID (#01, #02) to ease debug.

Could you detail a case where you cannot make it work ?

0

Answer 2

minfrin OP

Feb ’21

I have tried to make sense of what "Add Missing Constraints" has done, but I can see no logical pattern to it.

One of the parts that makes the least sense is that some elements (for example an "OK" button) have an intrinsic size, and resizing the window should have no effect on the size of the OK button. Other elements, such as a box containing editable text, has no intrinsic size, but would (in theory) either take the size of the surrounding superview, or would take an explicit size set by me. What is confusing me hugely is that there is no obvious way to tell which elements set a size, and which elements take a size based on their surroundings.

In all cases we have a "view" section, which has an edited X, Y, width and height. Values exist in each case. Should these values be set by me (and if so, how do I know they're set by me), or should they be set by autolayout? How do I tell which is which?

I am developing what seems to be a reasonable simple window. A label, a resizable text box, another label, a popup, a label, and then a tab view containing various possible options, then a Cancel and OK button. Everything in this window has a fixed size, except the resizable text box, which in theory should be as large as all the remaining space in the window.

I read the docs over and over and they all make sense. I then try out what the docs say and nothing makes sense, and Xcode keeps crashing. I'm lost.

0

Answer 3

Claude31 OP

Feb ’21

Should these values be set by me (and if so, how do I know they're set by me), or should they be set by autolayout? How do I tell which is which?

May be there is some confusion here.
Autolayout does NOT set constraints, it just computes objects layout based on the constraints.
Which means it is up to you to set constraints as size.

0

Answer 4

minfrin OP

Mar ’21

May be there is some confusion here.
Autolayout does NOT set constraints, it just computes objects layout based on the constraints.
Which means it is up to you to set constraints as size.

I know that autolayout doesn't set constraints. What I am talking about are the X, Y, width and height values under the "view" option in the size inspector. These entries are editable, and have values, and I have no idea where these values come from or what the effect on autolayout is if I edit the values.

What makes no sense to me is that I have constraints that link (with equals) the bottom of each element to the top of the element above, and I have linked the top most element to the superview, and the bottom most element to the superview, but this is not enough to create an unambiguous layout.

0