Premise
I have a superview C that simply contains two subviews A and B. ASCII art:
+-----------+
| view A |
| view B |
+-----------+
Here's what I want:
A's top must be pinned to C's top. A's height is not pinned to anything; it actually changes depending on its contents: it's a scrollview-less NSTextView.
B's top must always be 10 pixels from A's bottom. B's bottom must always be pinned to C's bottom.
The entire view C should be split between A and B, and the division between A and B must be decided by A's current height (which is decided by NSTextView), and B should fill any remaining space not taken by A.
In other words: A stays at the top. B fills out the rest of the superview. As A grows, B is pushed downwards.
The problem
Interface Builder always creates undeletable constraint that pins B's top to C's top. This means that B will always be positioned at a specific Y position. If I give B a height constraint, this doesn't happen, but that is not what I want.
I have tried implementing the superview's updateConstraints to delete this IB-generated constraint. That sort of works but when I do this, B's top is never adjusted and seems to be set arbitrarily. It doesn't matter what I set the constraint priority to, B ends up positioned either at the bottom of C, or at the top, or somewhere far off screen. Also, A seems to grow to fill the entirety of C.
Here is the auto-created constraint I can't get rid of:
Additional details
I should add that C is a cell view in a view-based NSTableView. I calculate the required height to fit A and B in tableView:heightOfRow, and expect the contraints to lay everything out.
Answer for posterity: Having a configuration like a described is apparently not possible with constraints. My solution so far, which works:
Create a constraint on A that sets a specific height. (In IB, I set a dummy height.)
Create a constraint on B that sets a specific top.
Don't specify a vertical spacing between A and B. (At least in my case this triggered weird behaviour in NSTableView.)
In your controller or view code, compute out A's height and set it using the constraint.constant property.
Also in your controller or view code, compute out B's top (using A's height) and set it using the constraint.constant property.
Related
I have created a tableviewcell. In it is a Image. I want to display the image over the full width of the column.
For that I have added constraints all set to zero for:
- Leading space
- Trailing space
- Top space
- Bottom space
I have also defined an Aspect Ratio constraint 8:6 to get the correct aspect ratio for the image.
In Interface Builder I get the "red arrow" error that "Need constraints for: X position of width".
When I run the code (it is compilable) it is displayed nicely. However I get runtime constraints warnings:
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:0x60800008cfd0 UILayoutGuide:0x6080001a5080'UIViewSafeAreaLayoutGuide'.bottom == UIImageView:0x7fc9fa90fa10.bottom + 8 (active)>",
"<NSLayoutConstraint:0x60800008d2a0 UIImageView:0x7fc9fa90fa10.centerY == UILayoutGuide:0x6080001a5080'UIViewSafeAreaLayoutGuide'.centerY (active)>",
"<NSLayoutConstraint:0x60800008d2f0 UIImageView:0x7fc9fa90fa10.top == UILayoutGuide:0x6080001a5080'UIViewSafeAreaLayoutGuide'.top + 7 (active)>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x60800008d2a0 UIImageView:0x7fc9fa90fa10.centerY == UILayoutGuide:0x6080001a5080'UIViewSafeAreaLayoutGuide'.centerY (active)>
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.
I do not see what I'm doing wrong, can someone point me in the right direction?
The problem is that whenever your cell size does not have a ratio of 8:6 your constraints will conflict.
There are several ways to fix this, but I think the easiest is to replace the leading and trailing constraints with a center horizontally constraint. The image will now be centered, its height is set by the cell's height, and its width will be set by the aspect constraint. The only thing to watch out for is if the cell becomes narrower than 8:6, in which case the image will extend outside the left/right edges.
I am trying to create an interface where two labels share a space, similar to an html table with two columns would: there is a distance between the two and when the window is resized they both resize and stay the same size, keeping the distance between them and filling up the available space.
e.g. | 10px to edge | label1 (50%) | 5px spacing | label2 (50%) | 10px to edge |
If the window is resized the margins and the spacing should stay the same while the two labels should evenly distribute the available space between themselves.
After multiple attempts (e.g. putting them in a custom view takes care of the margins) I cannot figure out the correct layout constraints to make this happen.
I had the same problem until I read your problem. Because I read your problem, I gave myself another try:
You can resolve it by going into the storyboard. Then, you select both labels. After that, you add the following constraints:
Now the labels resize correctly. The trick here is to edit the constraints of both labels together. Otherwise the Equal Widths choice isn't available.
I am having trouble preventing the text inputs from overlapping the footer button.
The footer has been anchored to the bottom of the screen. All the elements up top (logo, title label, and 2 input boxes) all have relative constraints. I try to add a constraint between that last input and the footer button but it pushes the footer off the screen on the smaller iphone.
What do I do??
https://github.com/civilordergone/taskfort_ios
Your issue seems to be in landscape only (I ran your code), where you have, for example, 320 points of vertical space, and an image (128pt), a text label (120pt), two text fields (30 each, for 60pt in total) and a 30pt button at the bottom. Already that's 338pt used, and we haven't accounted for the vertical spacing between your objects.
There simply isn't enough vertical space for all of these items to be vertically positioned while retaining their heights, so something has to be flexible: something has to be able to be vertically shrunk/compressed. Your logo and app name (Taskfort) are two candidates.
Here are some of the changes and/or points of consideration:
An ImageView with a height and a width equality constraint will always be that size, but for your layout, it has to be able to be compressed. I removed the height & width constraints and added an Aspect Ratio constraint, so the logo keeps its aspect ratio, but can now scale. I added a relationship constraint between the logo's left side and the left side of the Taskfort label.
The image has a relationship to the top of the screen, saying it must be equal or greater (not less than) to 0. This just means "the image can't be pushed off the top", which "less than" would allow it to be. (For example, if the image is pushed off the top by -40 points, that's still "less than 20").
The image has to be allowed to be vertically compressed. There is a property for "Vertical Compression Resistance" that was 250, and is now 249. By setting it to 249, we're saying "If something has to give way, vertically, this object can be compressed." Since we defined an aspect ratio constraint, if it does get compressed vertically, it'll be reduced horizontally by a proportionate amount so as to maintain the proportions of the logo.
To prevent the text fields from overlapping, their relationships are set to "equal or greater than". Same for the Username text field to the label.
The challenge was in defining the relationship between Password and the Create Password button at the bottom. I added a constraint that says their vertical distance must be greater than or equal to 20. This has a priority of 1000 (by default), so at all times, you get 20pt or greater between those two. Without this, your password field and your button overlap.
While step 5's constraint solves the overlap problem, it creates a new one in portrait orientation, where the password is now 20pt from the button, instead of being lovely white space. To fix that, we add a second constraint between the password field and the button, and specify that the vertical distance is to be 228pt between them both. Now that creates a constraint conflict because you now have two constraints that are both trying to define the vertical relationship between the button and the text field. The 20-pt one is required, it has to be there. But the other one is just a "nice to have, if we can fit it".
So you set the priority of the new one (the 228pt) to be low, such as a Priority of 250. Then the layout engine will use the required one (must be 20 pt or greater) and then it sees the other one ("make them 228") and it tries to do that. If it can't, such as in landscape, then it doesn't do it and doesn't complain, because you have the other constraint already that provides positioning information. If you're in portrait and you have enough space such that it can also apply the low priority constraint, then it'll do that too, and your portrait layout now gets a bigger gap between top and bottom.
When testing these layouts, use the Assist Editor in Preview split-screen mode so you can see the affects of your changes without needing to run the simulator. Here's a guide on that.
Sounds like you're using an equality constraint, such as "the distance between lastInput.bottom and footer.top equals 20". Instead, try an inequality operator, such as "the distance between lastInput.bottom and footer.top is equal or less than 20".
The attributes inspector for a constraint can let you change an equality to an inequality. Alternatively, you can double-click the constraint line (the UI in the storyboard editor) to get a quick pop-up for that.
I’m trying to put together what seems to be a simple case of two NSTextFields with dynamic width and fixed spacing in between. I cannot figure out an effective way to do so though.
I’m looking to get something like this:
The blue boxes are the NSTextFields. When more text is entered into one, it should grow and thus make the other one shrink, maintaining the lead space, trailing space and the spacing in between the fields. The first one should take the priority if both of the fields have too much text. Each field will also clearly have a maximum and a minimum possible width it can reach.
How would I go around handling this, preferably utilising IB autolayout as much as possible?
It seems to me that all of constraints you mentioned directly translate into interface builder --
First view has width >= something.
First view has width <= something
Same for Second view.
Space between views is fixed.
Second view wants to be as small as possible (have its width at 0) but this has lower lower priority than the previous constraints and lower priority than inner content size constraints.
The code I had to add to my view controller, after applying the constraints as per the ilya’s answer:
In controlTextDidChange (_controlWidthConstraint refers to the fixed width constraint of the input; it’s probably 0 by default for the second input):
// Get the new width that fits
float oldWidth = textControl.frame.size.width;
[input sizeToFit];
float controlWidth = textControl.frame.size.width;
// Don’t let the sizeToFit method modify the frame though
NSRect controlRect = textControl.frame;
controlRect.size.width = oldWidth;
textControl.frame = controlRect;
_controlWidthConstraint.constant = controlWidth;
The key lies in invalidating the intrinsicContentSize for the text field when text is input.
You can check a sample project here, to get you on the right track.
I wish to have objects positioned relative to the size of the superview instead of absolutely.
For example, I do not want to say that an element is "50px from the top", I want to say it is "1/3 of the way down".
Is there any way to do this using auto layout? If not, what is the best way?
Cheers
Add an Outlet to the height constraint of superivew and an outlet constraint to the topspace. In code set the constant of topspace constraint to a value equal to 0.33 * height constraint of superview.
If you use IB, just place the element where you want it and set it to maintain its Top Space to Superview. This will hold the element at that distance from the top for both 4 and 3.5 inch devices.