I want to use an NSStackView as "floating" container for buttons. i.e. a horizontal NSStackView that acts as toolbar of sorts and contains a row of square buttons (with fixed size). In runtime, some buttons will be dynamically shown/hidden and I want this NSStackView to dynamically adjust its width according to the visible buttons (plus spacing, edges, etc).
So, this NSStackView would have:
Fixed height
Dynamic width based on its content
Its exact position in parent view is not known in design time
A row of NSButtons with fix sizes
I have a nib file that contains the NSStackView and its buttons, which I load in runtime:
Bundle.main.loadNibNamed("ToolbarView", owner: self, topLevelObjects: nil)
toolbarView.detachesHiddenViews = true
toolbarView.setFrameOrigin(NSPoint(x: 100, y: 100))
I am struggling to find the exact combination of properties and constraints to make this behavior work. When I hide some buttons, the NSStackView detaches them but doesn't shrink to fit the shown buttons total width. I tried all NSStackView NSStackViewDistribution options.
I suspect I'm missing some constrains to make this work but all the NSStackView examples I find anchor the NSStackView to it's superview and I can't do that because its position in parent view is set in runtime.
Is there any way to make this work or do I need to fall back to manually calculating width from the visible buttons (which kind of makes using NSStackView pointless)?
What is the value of translatesAutoresizingMaskIntoConstraints on the stack view after loading it from the nib? If true, what is the autoresizingMask? (the default it should be .none).
If that is the case, then there are autoresizing mask constraints that hold the stack view's frame origin and size in place (i.e whatever gets loaded from the nib).
The best way to deal with this is to set translatesAutoresizingMaskIntoConstraints to false and then use constraints to position it in its parent view at runtime.
In addition to the already-mentioned translatesAutoresizingMaskIntoConstraints and leading and top constraints, have you tried modifying the stack view's hugging priority? Use a value of 1000 (required) to absolutely prevent the stack view from extending beyond its contents:
stackView.setHuggingPriority(1000, for: .horizontal)
Related
I want to show a NSCollectionView inside a NSTableCellView. I have it setup correctly, and it works for the most part, but the collectionView's scrollview doesn't seem to resize properly against the NSTableCellView, even though I have auto-layout constraints setup for this.
Is there anything I can do to setup constraints in a way that the scrollview resizes against the NSTableCellView (which should also let the collectionView also resize itself)?
EDIT:
To elaborate, what I really want to do is have the collectionView expand and resize as the window is resized, and have it take up the same width as the tableViewCell, and depending on the number of items in the collection view, resize the height of the outlineView & hence determine the height of the outlineView's row. It works fine when the collectionView is part of an ordinary view, but I can't get it to resize itself inside a NSTableCellView.
Firstly, remove all of the constraints you've set for your collectionview/scrollview.
Now, you will need to make 4 constraints, one for each of the leading, trailing, top and bottom space from the scrollview to its superview. Make sure width and height are not constrained. I've done this in a recent app I've made and it worked rather well.
EDIT: Below in the comments we figured out the column wasn't resizing so the constraints were correctly set.
I'am using autolayout with NSSpliView, the setup is as following on the picture
The split view is in a window which can resize, when it resizes, the divider is changing proportional 50:50, how to change this, so that the height of the bottom view stays and the top view gets resized (but no more than 124px) but still have the freedom also to change it manually by dragging the split?
So just to recap you have three requirements,
Bottom view stays the same size on resize
Reduce the holding priority if the top view (select the NSSplitView to get the correct inspector)
Top view cannot resize more than 124px
Add a inequality constraint which sets the height of the view to less than or equal to 124px. You can do this in IB. It will also be a good idea to create a IBOutlet for this constraint in your custom view of controller class for the next step...
When the divider is moved the top view should be able to get smaller than 124px.
I not entirely sure but checkout the NSSplitView delegate method such as splitView:resizeSubviewsWithOldSize: or splitViewDidResizeSubviews:. When you resize with the divider the delegate method should override the height constraint to be the current resized size. So something like the following in the delegate method
self.heightConstant.constant = NSHeight(topView)
Or you could just remove the constraint and re-add it later when needed.
I'm having trouble getting a UIScrollView to respect the constraints I put in interface builder.
All I need to be able to do is set the content size of the scroll view from within IB.
The UIScrollView contains a single UIView.
Constraints on the UIScrollView:
Constraints on the UIView:
I've read through the documentation, and so have set things up as follows:
the UIScrollView has constraints pinning it to its superview, thus defining its size from outside
the UIView (content) has a fixed size (through width and height constraints)
the UIView is pinned to the UIScrollView, thus defining the content size
However, IB won't let me enter these constraints. If I change the 'Bottom Space' constraint between the view and the scroll view, shown in the image as -2196, to 0 (thus pinning the lower edge of the scroll view), then the 'Top Space' constraint resets to a non-zero value. The same happens in reverse. (I haven't yet tried in Xcode 5, which has a far saner approach to invalid constraints in that it doesn't just throw yours away when it feels like it.)
What am I missing?
Every time I've tried to do something even mildly sophisticated with constraints in Xcode 4's Interface Builder, I've eventually given up and either written the constraints in code or switched back to springs'n'struts and layoutSubviews (usually after crashing Xcode a few times).
That said, there is another approach to laying out a scroll view with content in IB. Just make the scroll view as big as its content size, and rely on the view controller (or some containing view controller) to resize the scroll view (or its superview) and let the constraints shrink down the scroll view's frame at runtime. The window's root view controller will always set its view's frame to the screen size, regardless of its size in the nib or storyboard, and that resizing flows down the view hierarchy.
I described this approach in more detail in this answer.
If your scroll view's content size is really supposed to be 2196 points tall, this probably won't work so well. I don't have anything better to suggest in that case.
I'm trying to get the hang of NSViewConstraints. I like them a lot; they make a lot more sense to me than the previous system.
I have a window, a 22 pixel-tall subview spanning the top of it, and a tabless, borderless NSTabView beneath it. The goal is to have the top subview never resize its height.
Without any constraints, auto formatting takes care of most of the work. The only trouble is resizing the window causes the upper subview to change its height. My seemingly logical response was to pin the height at 22. I left margin constraints alone, since the NSTabView was already handling resizing well.
By pinning the height of the upper subview, the window now refuses to resize vertically! I don't see any documentation anywhere saying this is expected or the logic behind it. I've messed with various constraint configurations to overcome it but nothing works.
Two questions:
Why is pinning the height of one subview freezing window height resizing? What is Xcode's logic?
What constraint setup will achieve the desired positioning?
I just tested creating a window as you describe, and pinning the height of the 22px view. This created one user constraint on the view for it's height.
However, it also created 2 constraints on the parent view (the window's content view), one for the Top Space to the 22px view, and a second for the Bottom Space to the 22px view. These constraints are what's preventing you from resizing your window. You should select the second constraint and delete it (but leave the first one in place as it's fine).
I have a NSView with a NSTableView inside of it.
If the view looks like this:
And the size & position properties for the Scollview (and tableview) look like this:
Then why when I resize the view, does it look like this:
Are my autosizing properties not set correctly? To my understanding they should be?
To make it clearer, you won’t see autoresizing behaviour whilst designing your view in Interface Builder unless the border of the subview coincides with the corresponding border of the superview and Live Autoresizing is enabled.
This behaviour exists because resizing the superview can be used to indicate that you want a certain margin between the subview area and the superview area — for instance, you might have a 100pt margin between the subview’s right border and the superview’s right border, and then increase that margin to, say, 200pt by dragging the superview handles.
Edit: On the other hand, if you want to resize the superview whilst keeping the margins according to the autoresizing mask, you can drag the superview handles whilst holding the alt/option key.
Use Cocoa Simulator (File -> Simulate Interface) in order to test your interface, including autoresizing behaviour.
The table with its scroll view will autoresize to your view's size only if you enter dimensions in by hand in Size info panel. They will not autoresize if you drag view's handles with mouse.