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à!
Related
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.
label width is not increasing according to content in table view cell
Please check the attached image for detail
You need to put below constraints to the UILabel instead of leading Constraints.
Why this happens so ?
As the leading is not defined flexible, It will choose the constant value and therefore it will by default will leave space equal or greater from leading.
If we set leading with safe area it will increase width as the text expand till it reaches the safe area line.
Hope this works !!!!
Make constraint >= 20(some constant) to Safe Area and it should work fine.
I am working with xcode and I can't seem to get my custom cell to budge. I have the constraints set up and even reset them a couple of times but they continue to look a lot different when I run my simulator.
Here is a screenshot of my constraints:
Here is an screen shot of my simulator:
I have tried deleting the labels and imageView and then adding it again and reset the constraints a few times. Anyone else getting these problems?
You are defining too many constraints. It is key for you to always use THE LEAST number of constraints as possible.
From what I can see you are giving the labels '5' and 'Orders need to be viewed' constraints to the leading edge of the cell. If you are also setting a second leading constraint to the image (hard to tell from the image, code would be easier to debug) this contradiction would break your constraints.
What you want is to have the image leading edge to the cell and give it a height and width and a top constraint only.
Give the '5' label 'horizontal spacing' ( ctrl drag ) to both the image and the second label.
Provide a height and width for it and a top constraint.
IMPORTANT
since you have defined a horizontal spacing from the '5' to the other label, you do not need to provide another leading constraint to the last label.
simply give it a height, width, top constraint and trailing edge to cell
That should be all you need !
If this is too confusing let me know and I can share some snippets for more visualization
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.
The scene has a container view inside of a superview, and I've constrained it with respect to the boundaries and 2 text boxes. Instead of "Numeric Value Please", I only see Nu... appearing on there. The console does not give me any constraint related warnings, and I don't understand why the blue view is able to fit in, but the controller is not.
Here are Alert Controller's constraints: http://i.stack.imgur.com/2xhZh.png. It's just constrained to the center.
Another picture of main view's constraints: http://i.stack.imgur.com/2qARq.png
The constraint to the right is too large (125), pushing the right edge of the container to the left.
You should just have: constraint from top (superview), constraint to left (the text field), height (optional), and slightly higher compression resistance. To prevent the text from going off to the right you can also have a >= constraint to the right (superview).
To break the text into two lines, set number of lines to 2 and choose "Word Wrap" + make sure you have a right side constraint and you are not constraining the height (too much).
Another remark: do you really need a "container" view? Why not just a plain UIView? Or does the label have its own controller? That seems like a somewhat convoluted design I think.