On pet 13.11.2015., at 11.00, Ken Thomases wrote: > Your screencast of the failing case shows that you have some additional views > (boxes, it looks like) in the hierarchy, and you haven't explained fully the > constraints involved.
I put those boxes just to give me some visual indication of how subviews are being resized. Their occupy their superviews completely, with a simple set of constraints: * box.leading = superview.leading * box.trailing = superview.trailing * box.top = superview.top * box.bottom = superview.bottom So, I believe they don’t matter in this case. > No, you misunderstand. > > The holding priority is how "strongly" the slider keeps its position, in > general. If you put a view into one pane and set its width and height at, > say, priority 750, and add constraints to keep its edges all around equal to > its superview's, then the user would be unable to drag the divider at all. > > Suppose the split view allowed the user to drag the divider. What happens > when the user lets go? The holding priority is less than the priorities of > the view's size constraints, so the view would push or pull the divider and > return to its desired size. Since the divider won't stay where the user put > it, it's best to not allow the user to drag it. > > In all probability, the drag is actually implemented by adjusting a > constraint whose priority is the holding priority, so it stops as dictated by > that priority. Ah okay, I didn’t realise that, but as I think of it, it does sound logical. However, even then I don’t understand why my particular case is failing. Let’s forget about the vertical splitView at the moment, and see what happens in the right of the window. Also, let’s say the superview of the playerView is high enough, so the previewView is on its intrinsic size. The holding priority of the top subview (containing the playerView) is 240 and for the bottom subview 260. The playerView content resistance priority in both directions is 230. As I drag the slider up, the vertical margins between the playerView and its superview are getting smaller, since the (required) constraints are set for them to be 20 or bigger. Once that limit is reached and they are required, they can’t go any smaller, so the size of the playerView comes into play. Since its compression resistance priority (230) is lower than that splitView's subview holding priority (as you’ve said, some invisible constraint implementing the drag with priority 240), I would expect the previewView to start shrinking. While doing so, maintaining its aspect ratio should not be a problem, since horizontal margins (their constraints) are set to be 20 or bigger. -- Dragan _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
