2016-09-02 25 views
0

NSStackView與常規NSView相比有2個附加優先級,即clippingResistancePriorityhuggingPriority.該文檔提供了一個合理的解釋,說明它們的用途以及它們的作用。NSStackView和內容擁抱優先級

但4個優先事項有點矯枉過正。

現在,在上述文檔他們提到:

堆棧視圖沒有內在的內容大小和不具有可配置的內容壓縮性。在堆棧視圖中調用setContentCompressionResistancePriority:forOrientation:方法不起作用。

但是,contentHuggingPriority留在陰影中。 看起來好像NSStackView也不會對此做出反應 - 或者至少我無法做到這一點。

有人可以證實或反駁嗎?

回答

1

是的,這是正確的。從一個NSView繼承的內容約束的優先級:

- (NSLayoutPriority)contentHuggingPriorityForOrientation:(NSLayoutConstraintOrientation)orientation NS_AVAILABLE_MAC(10_7); - (NSLayoutPriority)contentCompressionResistancePriorityForOrientation:(NSLayoutConstraintOrientation)orientation NS_AVAILABLE_MAC(10_7);

僅適用於基於視圖的intrinsicContentSize,其中NSStackView沒有帶來的限制。所以就像你和文件提到的一樣,它們沒有任何作用。 (除非您將NSStackView子類並覆蓋intrinsicContentSize以使其具有某些值...)

+0

謝謝。嘿,當我們處理它時,也許你可以幫助澄清'NSStackView'的其他問題?像這樣的文檔:「要允許視圖裁剪,設置一個低於NSLayoutPriorityRequired的默認值的裁切阻力,並將所有堆棧視圖視圖的可見性優先級設置爲」NSStackViewVisibilityPriorityMustHold「。這根本不是真的。對於我來說,當裁剪阻力<500時,堆疊視圖只會開始裁剪和隱藏子視圖。也許你對這樣的事情以及在哪裏(除了wwdc,呃)有了一些見解,他們可以澄清? –

+0

剪切阻力優先級在窗口中約束的其餘優先級中起作用。所以你是對的,它不是完全正確的,它所需要的只是<必需的,但是當它變得可能被剪輯並且僅取決於堆棧視圖與其他約束的優先級相互作用時就是這一點。由於DragThatCanResizeWindow優先級爲510,而WindowSizeStayPut爲500,因此500#聽起來就像您的堆棧視圖的大小與窗口大小相同。 – Taylor

+0

自動佈局指南稍微有些優先級(但不是macOS特有的):https ://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/AnatomyofaConstraint.html#//apple_ref/doc/uid/TP40010853-CH9-SW19。各種NSLayoutPriority常量也有標題註釋來描述它們的值和語義 – Taylor