NSStackView has 2 additional priorities compared to a regular NSView, namely clippingResistancePriority and huggingPriority. The documentation provides a somewhat reasonable explanation what they're for and what they do.
But 4 priorities is a bit overkill.
Now, in said documentation they mention:
A stack view has no intrinsic content size and does not have a configurable content compression resistance. Calling the
setContentCompressionResistancePriority:forOrientation:method on a stack view has no effect.
However, contentHuggingPriority is left in the shadows.
It seems like NSStackView doesn't react to this one as well - or at least I wasn't able to make it do.
Could anybody please confirm or disprove this?
Yes, this is correct. The inherited content constraint priorities from NSView:
- (NSLayoutPriority)contentHuggingPriorityForOrientation:(NSLayoutConstraintOrientation)orientation NS_AVAILABLE_MAC(10_7);
- (NSLayoutPriority)contentCompressionResistancePriorityForOrientation:(NSLayoutConstraintOrientation)orientation NS_AVAILABLE_MAC(10_7);
only apply to the constraints created based on the view's intrinsicContentSize, which NSStackView does not have. So like you and the documentation mention, they have no effect.
(unless you subclass NSStackView and override intrinsicContentSize to give it some value...)