I have a stack view holding 2 images.
One image's width to be lower or equal to 140 and 1:1 ratio
Stack view top constraint 20 and trailing constraint 5
When I want to set the stack view leading constraint to 5 (looking at the safe area leading) it enlarges the safe area to a width of 1920 and I have no idea why it does that.
It might have something to do with that the total width of the stack view (including the constraints) is smaller than the width of the safe area so it's ignoring the images width constraint and enlarging it to the default size (1920)? Because, when I change the stack view's distribution to fill proportionally instead of fill equally it does obey to the image's width constraint and the safe view's width stays normal.
If I am thinking correctly, how can I find a workaround for this?
Thanks in advance.
EDIT: I was trying to think logically and I found a solution by changing the image's width to GREATER or equal to instead of SMALLER or equal to. I was following a devslopes guide and in that Xcode version (Beta XCode9) it did work, it just gave a warning it wasn't obeying that constraint anymore (I think it was saying that, I just saw the width being red). So it works now, if anyone has this problem following their guide, just do what I said and it will work.
Related
I am wondering how I can change the dimensions of a stack view to be a ratio, specifically 7:6. So far, I have constrained the Stack View with "Align Center X to: Superview" and "Height Equals: 400" and "Align Top to: Safe Area Equals: 100." How can I maintain a constant ratio between the width and the height across all devices? Thanks!
For User Interface, I am using Storyboard, not SwiftUI.
What I have right Now
I am not exactly sure why this doesn't work, but it is probably my understanding of aspect ratio. My main issue is how to use the (phone width - 20 points) to determine the height so that it is a ratio.
Expected result, but I don't want to manually set the height and width, rather a ratio
I don't want to manually set the height and width
Then you should remove the "Height Equals: 400" constraint that you currently have! After that the layout should be fixed. It should look like:
Just for completeness' sake, all the stack views should have distribution=fill equally, and alignment=fill.
The height=400 constraint is causing the constraints to conflict. If height = 400, then width would be about 467 to get an aspect ratio of 7:6, but the width of the super view isn't enough for that. But you also require the leading and trailing of the stack view to be pinned on the leading and trailing of its super view! These constraints can't be simultaneously satisfied.
Note that this layout doesn't look quite nice when in landscape, since the width would be very large and the available height is small. You might want to add variations to install/uninstall constraints based on size classes. In landscape mode, you could pin top and bottom rather than leading and trailing, for example.
I am implementing a container which algins its children in a row and does kind of a linebreak when there is no horizontal space left. Thus, the required height depends on the available width. For larger widths, more content fits in one line and less lines are needed leading to less height. For smaller widths, less content fits in one line and more height is needed.
I subclassed the container and implemented the needed logic. The minimum width of the container is set to the minimum width of the widest child which would display one extreme case where there are stacked lines, some of them with only a single child inside them.
The problem is as follows: The window displaying the container has a very large height, for some cases even larger than my monitor. I am able to resize the window except that I cannot decrease the width. It turns out that the documentation for height-for width geometry management says:
Next, the toplevel will use the minimum width to query for the minimum height contextual to that width using gtk_widget_get_preferred_height_for_width()[...]. The minimum height for the minimum width is normally used to set the minimum size constraint on the toplevel (unless gtk_window_set_geometry_hints() is explicitly used instead).
Thus, the behaviour is expected as the window uses the height for the minimum width as its minimum height leading to the previously mentioned extreme case. This seems to be counterintuitive as in my case and an example used in the documentation (textflow in labels) the height will be maximal when the width is minimal vice versa. Only when actually allocating the available space, gtk considers to assign smaller heights when a larger width allows that. Even when using high widths in the window's default size and size request only the minimum width of the container is considered to derive the required height of the window.
The documentation already somehow contains a workaround, namely the geometry hints. But this seems to be a verbose and static way of sizing the window when the default width of the window together with the height-for-width-function could theoretically be used to easily determine the size of everything. The size-allocation already works as intended, only the size-negotiation cancels the benefits the height-for-width function could bring here. Is there any nice way of implementing the functionality required to fix the window sizing?
It seems as there is no intended workaround for this problem the way I searched for. The gtk size negotiation goes from bottom to top when requesting sizes and top to bottom when allocating. Thus, my container has no way of knowing how much width its parent could assign to it.
I solved the problem by adding a property which defines the minimum of children per row. This can be used to increase the minimum width and therefore decrease the minimum height. I only use it for the minimum width calculation while actually ignoring it doing the real size allocation which only is a minor detail I will document.
This documentation will be part of the code example I will provide as an answer to my old post which was about implementing a FlowBox with the behaviour described above.
I made some custom tableview cells and while everything else with them works, the images are really big and I cant get them any smaller.
I did this and its still flooding: I added height and width constraints and a 10 constraint to the left of the ImageView, and selected these settings
I can suggest a few things you can try to achieve it. I have illustrated 1 & 2 on the attached image:
Suggestion 1 is to make sure there is no ambiguity or constraint collision. It seems you have set two constraints for the width of your image. You might be setting it to be 'greater than' the width you want it to be.
Suggestion 2 is to also provide a constraint between the image view and your label view for the heading in order to prevent an overlap.
Suggestion 3 is to make sure that your imageView has a setting of "Clips to bounds' checked on the inspector.
Suggestion 4 Change your content mode to Aspect Fill instead of Aspect Fit
Suggestion 5 Complete your constraints, make sure everything is blue. I don't see top and leading constraint. This will help remove any ambiguity.
Suggestion 6 Use the view debugger, see what constraint values are being used, and the debugger will also show you hierarchies and view layers, which will give you more idea of what is going on.
Your imageView seems to have no x and y constraints. I suggest you to give top and leading constraints for the beggining. You should never see red lines to have stable layouts.
I am trying to add a custom view in an nswindow in my osx app.
I need to give a minimum and maximum width values for the custom view which is located in the centre. The view's width should expand until a certain point (maximum width value) but should stop expanding if user continues to expand the window.
Thanks in advance.
You can do all of this with layout constraints.
First, we need to specify where the view should be relative to the window. For the sake of this tutorial, I'm going to assume you want it centered:
Next, we add our constraint for the minimum width:
To make this a minimum instead of an absolute width, click on the constraint and change it to "Greater Than or Equal" in the Attributes Inspector:
Now do the same thing, making another width constraint for the maximum. This time, set it to "Less Than or Equal":
Now the width constraints are set up. But we're not done. We've now set a minimum and a maximum, but the width is still ambiguous—there is no way for the layout constraint system to decide what exact width between 300 and 700 that it should actually be using at any given point. There are two steps to fix this. First, we need to make sure that the view will be entirely within the window and not run off the edges, so create some Greater Than or Equal constraints making sure it stays within its bounds:
(Also, make a trailing constraint which is set up identically).
Finally, we need one last set of constraints; we want some leading and trailing constraints, marked Equal, but with a lower priority:
(Also add a trailing constraint, identically configured)
What does this one do? Well, it tells us that, unless our other constraints (specifically the maximum width, in our case) make it impossible, we'd like the edges of the view to be the standard distance from the window edge. The reason we use 499 as the priority is because that the value of NSLayoutConstraint.Priority.windowSizeStayPut is 500. The documentation has this to say about .windowSizeStayPut:
It's generally not appropriate to make a constraint at exactly this priority. You want to be higher or lower. Constraints with higher priorities can adjust the window’s size. Constraints with lower priorities must be fulfilled using the current window size.
If we set our constraint to higher than 500, the system would restrict us from making the window too wide for these constraints to be valid. That's not what we want, since we want the edge spacing to expand in this case. So since we want to be able to break this constraint by resizing the window, we set it to slightly less than 500—so, 499. This means that the constraint system will try to put the view here, but if it can't do it because we made the window too wide, it will allow this constraint to break, although it'll still try to get as close as it can without breaking the other constraints. So your view will be at its maximum width, and centered in the window.
Voilà!
I am trying to set a UIImageView has no fixed size and width in the storyboard. I set the leading space to container to greater than or equal to 20, top space to the container to greater than or equal to 20 and trailing space to container to greater than or equal to 20 and vertical spacing to a UICollectionView, the UICollectionView satisfy the constraints. But the UIImageView don't work, it's telling me it's Position and size are ambiguous. How can I make it work? My Idea is no matter how large the image view, it will always keep 20 space to leading, top, trailing and bottom.
I have set the height and width to be greater than or equal to some value and their priority to 999, it's lower than the leading, top and trailing priority. and I have set the imageview to center horizontally. but i get height and vertical position are ambiguous for “Image view”.
Can you see what happens when you add height and width constraints to the UIImageView, but set their priorities to some low value, e.g. 1? It should help, but now UIImageView won't be centered. You can fix it by enclosing UIImageView in another view (empty UIView) and centering it in it both horizontally and vertically.
When you get this error:
Position and size are ambiguous for “view”
Probably following constraints are missing/incorrectly set:
Width constraint (size issue)
Height constraint (size issue)
Alignment constraints (position issue)
If you are using Stack Views, make sure the Photo Image View is inside the Stack View! (As in the Apple Tutorial)
If you want to give margin kind of thing into button through coding than please try these if it'll work
[button_Name setTitleEdgeInsets:UIEdgeInsetsMake(0.0, 12.0, 0.0, 0.0)];
I hope this will work..!!!
In cases where the height/width are not ambiguous at runtime, but ambiguous at storyboard time, e.g., setting an image dynamically, having a container view, etc, I try to add constraints with the placeholder checkmark checked to silence xcode.