My xib layout likes under drawing
I have set the constraints from "a" to "b" to ..."e" besides the height constant of "c" so that can determine the height of the cell.
Sometimes the "c" will hidden because some reasons, I changed the height constant to zero and actual height by the label's content when it is visible.
--------------------------------------
UILabel(name-singleline) a
UILabel(title-Multi line) b
UIView(hidden or not) c (default height constant = 80)
-UILabel(content Multi line) d
UILabel(singleline) e
--------------------------------------
But there is a autolayout warning make me crazy
(
"<NSLayoutConstraint:0x15756760 V:[UILabel:0x15756650'XXXX'(15)]>",
"<NSLayoutConstraint:0x15757130 V:[UIView:0x15756ee0(80)]>",
"<NSLayoutConstraint:0x15758060 V:|-(21)-[UILabel:0x15756650'XXXX'] (Names: '|':UITableViewCellContentView:0x157563a0 )>",
"<NSLayoutConstraint:0x15758120 V:[UILabel:0x15756650'XXXX']-(14)-[Project.GWWLabel:0x157573d0'YYYY']>",
"<NSLayoutConstraint:0x157581e0 V:[Project.GWWLabel:0x157573d0'YYYY']-(3)-[UIView:0x15756ee0]>",
"<NSLayoutConstraint:0x15758210 V:[UIView:0x15756ee0]-(8)-[UILabel:0x157569e0'ZZZZ']>",
"<NSLayoutConstraint:0x15758270 V:[UILabel:0x157569e0'ZZZZ']-(18)-| (Names: '|':UITableViewCellContentView:0x157563a0 )>",
"<NSLayoutConstraint:0x1575d760 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x157563a0(139.5)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x15757130 V:[UIView:0x15756ee0(80)]>
I'm also deeply interested in understanding why this happens
Try this:
make the priority of height constrain 750 as shown below
it will work when you change height constant
The first golden rule of auto layout (specially when working on TableView's cells) is to be able to draw a line from top to bottom and from left to right and be able to determine the size of each element. To manage this you will need to be sure that each view has at least one constraint per side (unless it size could be inferred)
Also sometimes when testing the UI on different screen size the constraints might break. In does cases you should change the priority of the constraints or content hugging / compression resistance of the views to allow auto layout to break does constraints and change the constants to adapt the screen size. (Most of the cases it will only change in a few points, if it changes more you might need to change your constraints)
Is also important to mention that "Hidden views, even though they don't draw, still participate in Auto Layout and usually retain their frames, leaving other related views in their places." check this post
You may want to check this post or this one if you use swift
Related
I'm trying to place a UITableViewCell containing a single UIImageView in a UITableView using dynamic cell heights with AutoLayout (i.e. tableView.rowHeight = UITableViewAutomaticDimension).
The images I will be displaying have a specific ratio (1000:667), but there are other cells besides the image cells. I've built my constraint logic for this cell to respect the Aspect Ratio of the UIImageView.
Therefore, to avoid malformation or parts of the image not being shown (clip subviews) the aspect ratio constraint should determine the cell's height depending on the device screen width.
The cell was built in a Nib file with the following constraints:
Apparently this works, since the cell's height is set accordingly on runtime depending on the device (simulator) used.
The problem is I get lots of breaking constraint error logs (below). Any ideas why iOS/the table view complaints about this constraints?
Suggestions on different approaches to displaying a UITableViewCell that respects the aspect ratio would be appreciated too.
Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(
"<NSLayoutConstraint:0x7ff5097a7910 UIImageView:0x7ff5097393a0.width == 1.49925*UIImageView:0x7ff5097393a0.height>",
"<NSLayoutConstraint:0x7ff509739550 V:|-(0)-[UIImageView:0x7ff5097393a0] (Names: '|':UITableViewCellContentView:0x7ff5097a8e10 )>",
"<NSLayoutConstraint:0x7ff5097aa180 UIImageView:0x7ff5097393a0.centerY == UITableViewCellContentView:0x7ff5097a8e10.centerY>",
"<NSLayoutConstraint:0x7ff5097a8c70 H:|-(0)-[UIImageView:0x7ff5097393a0] (Names: '|':UITableViewCellContentView:0x7ff5097a8e10 )>",
"<NSLayoutConstraint:0x7ff5097a8cc0 H:[UIImageView:0x7ff5097393a0]-(0)-| (Names: '|':UITableViewCellContentView:0x7ff5097a8e10 )>",
"<NSLayoutConstraint:0x7ff5097b6440 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x7ff5097a8e10(276)]>",
"<NSLayoutConstraint:0x7ff5097b4930 'UIView-Encapsulated-Layout-Width' H:[UITableViewCellContentView:0x7ff5097a8e10(414)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7ff5097a7910 UIImageView:0x7ff5097393a0.width == 1.49925*UIImageView:0x7ff5097393a0.height>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
This one cause b'cos u gave unnecessary autolayouts (height, width and center y) conflits.
eg. you gave height then top and bottom, height is fixed still you gave top and bottom alignment... that's unnecessary...
you can try this suggestions.
1)center y + Trailing + Leading + Height.
2)Top + Bottom + Trailing + Leading.
3)height + width + center y + Leading
and many more
I hope you understand...
Fdo, the logs that you have posted clearly explains what is going wrong in there :)
What is the issue?
You have aspect ratio being set on imageView. As a result imageView will try to resize itself on assigning the image, while maintaining the aspect ratio that you have specified. So ImageView's height and width can/may vary depending on the image that you are assigning.
You have applied trailing and leading space constraint from imageView to the cell's contentView. That means no matter what happens you want the image view to cover the entire width of the cell. You are conflicting with your own constraint. Just above you said imageView is free to change its frame now you are saying it should cover whole width of cell how is that even possible buddy?
Similarly, you applied top and bottom constraint on image view to the cell's contentView. Now why is that not breaking then? Simple because cells height is dynamically being calculated based on the image you pass to imageView. So obviously the imageView's size after resizing will be equal to the height of cell. So no issue with cell height.
How to solve ?
Simple remove trailing and leading space constraint on imageView to cell's contentView and instead apply horizontally centre constraint on imageView that will give imageViews x position as well and will not mess with the width of imageView. Hence no constraints breaks and everything will work like charm
Extra piece of advice
When you have specified that imageView will have top and bottom constraint to cells content view which means that imageView height will always be equal to the cell's height, dude does it seriously make any sense to say that imageView will be at vertically centre of cell? Because anyway your imageView will cover the whole cell top to bottom.Any way it won't break anything but passing constraints more than what is actually needed is not the best thing to do as it might result in other consequences in future.
Hope it helps.
For autolayouting any view, only thing required to be satisfied is all views should get width, height,and x and y positions.
Now from your question, it looks that out of 6 constraints that you provided, only last 4 constaints are self sufficient to complete the requirements, so first 2 constraints are not required. Just remove them. All things will be fine.
The warning messages you are seeing is due to more than 2 constraints that you provided confuses system to take which out of them.
I have a custom UITableViewCell. The cell has three labels. The left most 'Amount' Label has the following constraint.
On the right side of the cell I have another label, 'Label Dollar Amount'. It has the following constraints:
The third label is right below 'Label Dollar Amount' is the 'Label Max Amount'. The constraints are as follows:
Nothing is done on the code. The table row height is calculated using UITableViewAutomaticDimension. The estimatedRowHeight is set to 100.
When the view is in landscape and the tableview is scrolled down, this particular cell is being dequeued since its out of the visible view. When the orientation is changed to portrait for the same state, the cell is expected to be visible.
I receive the following error:
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
NSLayoutConstraint:0x1607a770 H:[UILabel:0x160c1990'Amount'(150)],
NSLayoutConstraint:0x160c2b30 H:|-(18)-[UILabel:0x160c1990'Amount'] (Names: '|':UITableViewCellContentView:0x160c18c0 ),
NSLayoutConstraint:0x160c2b90 H:[UILabel:0x160c1990'Amount']-(0)-[UILabel:0x160c1c40'$45.61'],
NSLayoutConstraint:0x160c2bf0 UILabel:0x160c1ac0'(Max: $1,000.00)'.leading == UILabel:0x160c1c40'$45.61'.leading,
NSLayoutConstraint:0x160c2c80 H:[UILabel:0x160c1ac0'(Max: $1,000.00)']-(12)-| (Names: '|':UITableViewCellContentView:0x160c18c0 ),
NSLayoutConstraint:0x14e179e0 'UIView-Encapsulated-Layout-Width' H:[UITableViewCellContentView:0x160c18c0(72)]
)
Will attempt to recover by breaking constraint
NSLayoutConstraint:0x1607a770 H:[UILabel:0x160c1990'Amount'(150)]`
Note: Priorities are set to 1000 (Required) for all possible constraints seen here.
If I change the priority of the width constraint on Amount label to 999 it works. But the label disappears for longer text. Since zero spacing in the trailing constraint has a hight priority. Any suggestion on what could have gone wrong?
The table is setting a fixed width of 72 points on your cell view. This may just be temporary while it adjusts to the new orientation or layout, but you need to accommodate it:
NSLayoutConstraint:0x14e179e0 'UIView-Encapsulated-Layout-Width' H:[UITableViewCellContentView:0x160c18c0(72)]
So, you need to decide what should happen in your layout when its superview is only 72 points wide.
Currently, you have the following (edited a bit to make things clearer):
H:|-(18)-[UILabel:0x160c1990'Amount'] (Names: '|':UITableViewCellContentView:0x160c18c0 ),
H:[UILabel:0x160c1990'Amount'(150)],
H:[UILabel:0x160c1990'Amount']-(0)-[UILabel:0x160c1c40'$45.61'],
UILabel:0x160c1ac0'(Max: $1,000.00)'.leading == UILabel:0x160c1c40'$45.61'.leading,
H:[UILabel:0x160c1ac0'(Max: $1,000.00)']-(12)-| (Names: '|':UITableViewCellContentView:0x160c18c0 ),
Or:
H:|-(18)-[Amount(150)][Max]-(12)-|
So, even if every view which could be collapsed to 0 width were, you would still require 18 + 150 + 12 == 180 points of width between the edges of the superview. That conflicts with the 72 points available.
How would you like that to be resolved? One possibility is to reduce the priority of the width constraint on the Amount label, as you mention. Or you could even eliminate this constraint entirely and rely on the intrinsic width and the compression resistance priority. You say "the label disappears for longer text. Since zero spacing in the trailing constraint has a hight priority." I'm not entirely sure what you mean. Perhaps with longer text, the label is wrapping and words are on a second line which isn't visible? If so, you can set it to truncate (although that should be the default). If even truncation isn't acceptable, then what should happen?
You can try setting adjustsFontSizeToFitWidth and minimumScaleFactor to allow the text in the label to shrink, but eventually you still hit the limit (if the text is long enough and the cell width is narrow enough), so you still need to decide what you want to happen.
Another approach is to reduce the priority of the trailing constraint between Label Max Amount and the superview, so that that label moves off the right side. You may also need to reduce the priority of the trailing constraint of Label Dollar Amount, too, since it imposes the same requirement on the layout.
But, of course, that means that some of your content is off-screen. There's just no getting around the fact that you have to decide what should be lost when the width is too small to fit everything.
Once you decide what should happen, you set the priorities to achieve that. For example, if you want the Max Amount to truncate first, set its compression resistance lowest. If you want Dollar amount to truncate next, set its compression second lowest. If you want the Amount label to truncate after that, set its width constraint (or compression resistance, if you get rid of the width constraint) third lowest. And if you want things to be pushed off the right edge as a last resort, set the priority of the trailing-to-superview constraints to 999.
I have an issue with autolayout, the console is reporting problems with an image view I have in a cell:
RefreshCatalogue[31754:16177989] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x7fa98103b740 V:[UIImageView:0x7fa9810375d0]-(0)-| (Names: '|':UIView:0x7fa9810371d0 )>",
"<NSLayoutConstraint:0x7fa98103b7e0 V:|-(0)-[UIImageView:0x7fa9810375d0] (Names: '|':UIView:0x7fa9810371d0 )>",
"<NSLayoutConstraint:0x7fa98103b8d0 UIImageView:0x7fa9810375d0.centerY == UIImageView:0x7fa981037490.centerY>",
"<NSLayoutConstraint:0x7fa98103ba60 UIImageView:0x7fa981037490.top == UIView:0x7fa9810371d0.topMargin + 71>",
"<NSAutoresizingMaskLayoutConstraint:0x7fa980d44a10 h=--& v=--& V:[UIView:0x7fa9810371d0(50)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7fa98103b8d0 UIImageView:0x7fa9810375d0.centerY == UIImageView:0x7fa981037490.centerY>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
The problem is that if I do:
[self.collectionView reloadItemsAtIndexPaths:#[indexPath]];
Nothing shows even tho the image view seems to have correct frame, the image property is set.
If I reload the entire collection view with:
[self.collectionView reloadData];
The error is still there but the image shows. The code is open here shall anyone be interested in taking a look:
https://github.com/Ridiculous-Innovations/RefreshCatalogue
Also, all the constraints in the story board seem to be in blue. Any idea what might be causing the issue?
Edit: Needless to say that all the elements, including the image view are on the right place (I did debug frames and set random colours) but the image didn't display till refresh ... sometimes the cells don't display at all
You have issue with UIImageView:0x7fa981037490.top == UIView:0x7fa9810371d0.topMargin + 71 and parent frame with 0 height (so imageview height must be negative, but this is not allowed), like right after calling dequeueReusableCell method.
Possible workaround for this case is change priority from 1000 to 999 on the most bottom constraint in nested view (Vertical Space - catalogueHeaderCell - Image View and Vertical Space - catalogueCell - Info View).
In second cell some constraints are disabled. that means that constraints are removed for Any Height Any Width. so when you run app in iphone than that constraints conflict with your current constraints.
so remove that highlighted disable constraints.
Try this it helps me in removing those constraint break in console.
yourCustomCell.contentView.frame = yourCustomCell.bounds;
Views:
UIView:0x7fa9810371d0, let's name it container
UIImageView:0x7fa9810375d0, let's name it image1
UIImageView:0x7fa981037490, let's name it image2.
Not let's inspect the constraints
Container height is 50, specified by autoresizing. The height is probably not specified by your collection view. Most likely this is the size of the cell when it gets created before it gets resized to the size specified by your collection view layout.
image2 is 71 points under the topMargin of container, so it is at least 21 points under bottom edge of the container.
image1 bottom is aligned with the bottom of the container, so it is above the bottom edge of the container.
Now your last constraint centers image1 and image2 vertically so there is obviously a collision.
It's a bit hard to know what you are trying to do but I suppose you should position only image1 relative to the container and the only vertical constraint for image2 should be the ones that centers them vertically.
Too see the errors in Interface Builder, change your cell height to 50, you will see everything broken up. There are just some unnecessary constraints which cause conflict on resizing.
There are also some constraints that are not installed for the current size class. It's possible that you are running the app on a simulator that is of a different size class and has them installed. That means there are even some additional collisions.
check your imageView centerY constrain
delete this constrain...
this problem is occur because of constrain ambiguity. while adding auto layout you have to apply proper auto layout constrain to imageView.
After deleting centreY constrain if there is ambiguity then xcode will again show you same error, again you have to delete ambiguous constrain.
Well the warning message gives a clue to what is wrong.
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7fa98103b8d0 UIImageView:0x7fa9810375d0.centerY == UIImageView:0x7fa981037490.centerY>
So to analyse you have two view based objects. One is set to centre its self from top to bottom to the other view (0x7fa9810375d0 to 0x7fa981037490 - these are the views id's)
But also view id 0x7fa981037490 has another constraint,
<NSLayoutConstraint:0x7fa98103ba60 UIImageView:0x7fa981037490.top == UIView:0x7fa9810371d0.topMargin + 71>
Which looks like the top of 0x7fa981037490 is being aligned to the top of view 0x7fa9810371d0 plus 71 points.
I haven't downloaded your project but I'd bet that's where the problem lies. Best guess is the centre.y constraints cannot be satisfied because the align top moves the ImageView into a place that breaks it. Try to look at what you have set in constraints visually in your head. You have aligned to ImageViews and aligned one of those to the edge of another view. How will that break? (is what you should be asking yourself)
Try removing a constraint one at a time and build and run. If the warning goes, thats the one that needs fixing. Yes the view might look weird and you can use Command + Z to undo the deletion of the constraints one by one.
Give it a go. Let me know
I have a problem with auto layout on IOS8, the simplest case I can recreate is a simple tableView. I setup a static cell and then simply add a label.
My aim is to have the label largely fill the space, so I have three constraints on the label...
Centre it vertically within the superview (I think this is fine)
Set the label trailing margin to 30 (relative to superview)
Set the label leading margin to 30 (relative to superview)
It's all absolutely fine and works perfectly with no major problems or warning (it does warn about zero height, but I don't think that so much of an issue for this)
Now ... if I add a disclosure indicator it all falls apart. It still looks ok, but I get the following:
2014-10-30 15:51:46.358 ContraintIssue[25572:1586028] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand,
refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x7fd3f3d23390 UITableViewCellContentView:0x7fd3f3d226f0.trailingMargin == UILabel:0x7fd3f3d227e0'Label'.trailing + 30>",
"<NSLayoutConstraint:0x7fd3f3d235f0 UILabel:0x7fd3f3d227e0'Label'.leading == UITableViewCellContentView:0x7fd3f3d226f0.leadingMargin + 30>",
"<NSLayoutConstraint:0x7fd3f53b73b0 'fittingSizeHTarget' H:[UITableViewCellContentView:0x7fd3f3d226f0(38)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7fd3f3d23390 UITableViewCellContentView:0x7fd3f3d226f0.trailingMargin == UILabel:0x7fd3f3d227e0'Label'.trailing + 30>
I don't understand why adding an indicator would cause such a problem, it's nothing to do with the scale of the numbers, I've experimented quite a bit.
Any ideas?
The real world example a cell that has a label (the label) and then either another label or a text view that contains a value that can be set by following the disclosure. So the first label is a fixed size, the second ideally needs to be the max that it can be, but truncate the text if needed.
(See the 'ringtone' or 'vibration setting' within adding a contact for an example of what I'm trying to achieve)
Many thanks,
Lee.
I just had the same problem. I want to layout an image-view on the left hand with a label on its right which fills the space between the image-view and the right (or trailing) border of superview (which is the cell's content-view). Accessory view is set to disclosure indicator as well.
As in your case the conflicting constraints where all H-based and one I found in the logs where fittingSizeHTarget. I didn't found out what this means nor where this was coming from, but I found your post here.
The following did the trick for me:
Lower the priority of your label's trailing-to-superview constraint. (I chose 990).
I assume, that the layout system (with the disclosure indicator visible) for what ever reason can't satisfy all the constraints anymore, so it breaks one. But if you lower the priority, it still tries to satisfy the constraint, but doesn't break it as the conflicting constraint(s) have higher priority.
Hope this solves your problem as well.
Please pay attention to what Stephen says in the comment section of the upvoted answer. The upvoted answer is somewhat correct, but it's important to understand why it should only be used in certain scenarios.
Priorities are usually used in context where element A has a constraint saying height is equal or less/more than 300, and element B has one says height is equal or less/more than 500. Then autolayout can satisfy both conditions based on their priorities.
In this particular example, both constraints are set to specific value and lowering priority essentially tells to ignore that constraint if it's impossible to satisfy (there's no "partially ignore it"). However UILabel has an exception - default UILabel behaviour is to resize itself to fit the content unless it's constrained by additional margins (autosize constraint hides under fittingSizeHTarget name) and this behaviour sometimes shows false warnings. In reality this constraint will be ignored in the runtime, but before it becomes disabled internally it will file a warning. Therefore, even though we tell to ignore one of our constraints by lowering its priority (the one we set priority to 900), since autosize constraint will be ignored in runtime, our 900 priority will be applied and satisfied.
Raimunda's answer above explaining about the intrinsic size that happens on labels, buttons, etc being where this fittingSizeHTarget log is coming from was spot on. While you can leave it and let the system deal with it, it's a risky hack, because you're relying on the system to break an unwanted constraint...which it may not do in future releases. And in some cases, as in a view example I recently dealt with, lowering the priority of the trailing constraint to the outside safe area didn't prevent the label from overrunning (it did, however, fix the log warning lol).
For content issues like this, use the Content Hugging Priority and Content Compression Resistance Priority values. If you know that your label, for example, will want to increase in vertical height but constrain to a horizontal value, then make the vertical content hugging priority (Content hugging = the view resisting being made bigger) lower than the horizontal.
The Compression resistance is the opposite of this.
Then set your outside trailing constraint to a greater than or equal and you're good to go.
In the stack view below, the label titled Fake 4 actually overran and wanted to become two lines. That caused a conflict involving fittingSizeHTarget (the intrinsic content size wanted to stay on one line and overrun the view width). The key here was lowering the Horizontal Compression Resistance priority to lower than ALL of the other content priorities. This allowed me to lower the priority of the >= constraint on the trailing value, and everything behaves as expected.
Anyway, tweaking this stuff is annoying as heck, but those Hugging/Compression values, combined with some form of >= / <= are usually the answer.
Hope this helps.
i've a problem in resizing a UIView with Autolayout and constraints.
I'd like to change the origin (less than or equal of original) and the width (greater than or equal of original) but I got this: Inequality Constraint Ambiguity
Do you have idea for solve this?
thanks
I tried to make more than 1 vertical spacing constraint shrink for 3.5" displays, so I had to make 2 constraints between components that I wanted to shrink on smaller screen. One constraint was inequality (greater or equal) where I specified minimum required size, with 1000 priority, other constraint was equality constraint with specific size that is suitable for 4" screen, but with lower priority of 250.
This way Xcode stopped complaining and layout repositioned properly on smaller screen.
Your view is horizontally ambiguous. You do not have enough horizontal constraint information for the system to come up with just one solution for your view heirarchy. In this instance, it can't determine what the view size or left margin needs to be based on the current constraint information.
You need to add a less-than-required-priority (<1000) constraint either to your view's width giving it a defined width or add an equality constraint to your left margin constraint. By making the new constraint a <1000 priority, it will enable the new constraint to properly mix with your existing inequality constraints (which are required constraints). Here is another question that is similar to yours relating to inequalities.
The view will size differently depending on if you add the new constraint to the view's width or the view's left margin. This all depends on how you want your layout to behave in response to changes.
This does not make sense to the compiler (and logically) because there is no way to know whether the program should change x or width. Making one of the two static will solve your problem.
First you have to know what you want to do with constraints, please remove greater-than-equal-to constraint that does not make scene with less-than-equal-to constraint. buz view need define width constraint. either apply priority to which constraint play role first (greater-than-equal-to constraint or less-than-equal-to constraint).