In IB, I configure an NSView that's presented as a popover view programmatically, but internal content may vary thus causing internal size change.
Currently, if the size of any element changes, auto layout doesn't adjust the size of the popover, I actually had the opposite issues a few days ago where I didn't want subviews to change window size, I solved it by changing subviews compression resistance, I thought augmenting compression resistance might solve the issue, but it didn't.
How to let subviews resize their parent view ?
Thank you
Related
I load a scene in sceneKit and a window is automatically created. That window is resizable. Can I gain some control over the resizing process, so as to force it to preserve a certain aspect ratio as it grows or shrinks? For that matter, can I control the size and shape of the window as it is first created?
I preferably wish to do this programmatically, not using the Storyboard, but I'm open to either.
There's a lot going on in this question.
You can control the aspect ratio of an NSWindow by settings its aspectRatio.
Typically, though, you don't want to do that. You usually care about the aspect ratio of some view (a SCNView, perhaps), not the window. Use layout constraints to fix the aspect ratio of your views, and the window they're contained in will naturally have a correct aspect ratio, too.
Also: Storyboards aren't the opposite of programmatic. Interface Builder is. You can do Storyboards entirely programmatically, too.
I have an NSSplitView with content in both NSViews. The left NSView has 2 constraints – Equal Widths and Equal Heights. The right NSView has something simple, say an NSTextField, which is centered via constraints Center X Alignment and Center Y Alighment. This is what I hoped it would look like as I resize the window and/or the NSSplitView divider:
This is what's happening:
I've tried a great deal of configuration changes, I've tried using an NSSplitViewController vs just dropping an NSSplitView into an NSViewController to adjust more parameters programmatically, but I'm not having any luck. Whenever resizing the window, the left view always takes over the excess space. The same happens with the divider (it can be resized, but letting go of the mouse button causes it to snap right back). It seems there's something fundamental that I'm missing here.
The text field's content hugging priority is probably higher than the split view item's holding priority. Fix that and the view should probably work the way you expect.
Also, if, when you resize the view, the left view is resizing with the window while the right view stays the same size, then that suggests that the left view's holding priority may be higher than the right's. You should make the side that you want to stay the same size have the higher holding priority.
That said, I'm not sure what you mean about the constraints you've set on the subviews. "The left NSView has 2 constraints – Equal Widths and Equal Heights." What do you mean here? Its width is equal to what? Its height is equal to what? Do you mean it has an aspect ratio constraint? Frankly, I can't think of what constraints of those kinds would make sense for a view within a split view.
I have an NSView inside my main view that is preventing my window/main view from resizing correctly. Even when I go fullscreen, My main view can't fill the screen (there's some black space at the right). I know that the cause is that particular view (or something inside) as when I delete it my app behaves normally. What would cause an NSView to "control" growing of its window?
Here are the constraints on that view:
UPDATE: I've found an NSTextField inside which had hugging proiorty set to 750. I've taken it down to 250, now it DOES grow, but I can't shrink it down from "some" size. I'm calling it "some" size because it has nothing special: it's a bit less than my native fullscreen width, and it's different than my IB width.
In general, constraints with priorities higher than NSLayoutPriorityWindowSizeStayPut (500) can force the size of a window. That includes the implicit constraints generated by intrinsic content size, if a view has such, which have the priorities set for content hugging and compression resistance.
So, if you have a text field whose horizontal content hugging priority is, say, 750 and there's a chain of constraints that connect its leading and trailing edges to the window's content view's edges (or, similarly, relate the text field's width to the content view's width), then the window won't be able to grow large enough to "stretch" that text field.
Likewise, if the text field's horizontal compression resistance is high, the window won't be able to shrink to the point where the text field would have to be compressed.
Is it possible to use Auto Layout to position a window on the screen?
I'd like to set up constraints to position a window relative to an NSStatusItem. I'd like the window to be centered below the NSStatusItem, but also not be partially offscreen. So, I'd need weak constraints for centering relative to the NSStatusItem and strong constraints for maintaining a minimum distance from the screen edges.
How can I accomplish this?
Auto Layout doesn't work to position windows. The layout engine works per-window to lay out views within that window.
Luckily, this particular layout problem doesn't look too difficult to accomplish the old way. Figure the frame of the window below the NSStatusItem assuming it fits. Then check to see if that frame intersects with the screen edge. If it does, nudge it to the left until it doesn't.
I put a bunch of objects into a UIScrollView and I no have a problem: When I try to "scroll" to some off-screen objects, they appear so long as I am holding my finger down after dragging it, but when I let you, the UIScrollView snaps back to the original position.
Is there a way to prevent this? No off-screen gray area is appaering when this happens, BTW.
Thanks.
You have to set the scroll view's contentSize to include your objects, so it knows how large the scrollable area is — how far to scroll freely before it hits the edge and bounces back.
Try adding a Content Size Fitter component to the Scroll View's Content object and set its scroll direction (Horizontal Fit or Vertical Fit) to Preferred Size.