Hi, Here comes yet another autolayout question. Before continuing any further I want to mention that I tried to find an answer searching this mail list archive, but I couldn’t find anything helpful.
So, there’s this huge application I’m working on, which is all springs & struts UI developed during over a decade. But the time has come to finally start converting it to autolayout, not only since it’s the future of OS X /iOS layout management, but because it really feels more logical (once you get use to it) and in my case it will remove tons (literally) of code that captures different views frame changes and rearranges subviews. What I want to achieve currently is a simple media player view (and instance of AVPlayerView) within some superview hierarchy. I want this playerView to behave as follows: * it must be horizontally centred inside its superview * it must be vertically centred inside its superview * it must maintain its aspect ratio (which is determined by the natural size of the video track being played) * as the superview shrinks, the playerView must shrink also * as the superview expands, the playerView must expand only until it reaches the natural size of the video track being played (to avoid blurriness it people try to go beyond that size) This above is quite hard to accomplish in all possible scenarios if a view doesn’t define its intrinsic content size (like AVPlayerView doesn’t), but if it does the things get pretty simple. So, I subclassed AVPlayerView to define its intrinsic content size (as the size of the video track being played) and the constraints are set as follows: * playerView.center.X = superview.center.X * playerView.center.Y = superview.center.Y * playerView.leading >= superview.leading * playerView.top >= superview.top * playerView.width : playerView.height = intrinsicContentSize.width : intrinsic.ContentSize.height In addition, to achieve desired shrinking/expanding behaviour, both content compression resistance and hugging priorities are set to low values (=250). It all works flawlessly when the playerView's superview is contained inside the window contentView, like shown in this video: https://www.dropbox.com/s/cs7i7n1badq9dla/Window.mov?dl=0 However, in a more complicated superview hierarchy I can’t make the superview of the playerView shrink until all other views in the window are shrunk, like the compression resistance of the playerView wasn’t set low enough. I know this is hard to explain in vocally and therefore I prepared another video with UI layout similar to that the redesigned application will have, with a couple of NSSplitView instances involved. Please take a look at this video: https://www.dropbox.com/s/aqktmc9831j40rq/SplitView.mov?dl=0 (1) As you can see, I can’t shrink the superview of the playerView by dragging splitViews’ sliders after the limit of playerView’s intrinsic content size (movie size) I reached. It behaves like the compression resistance priority is high, although it’s set low. (2) Similarly, when resizing a window the playerView’s superview won’t shrink unless all other subviews of splitViews are completely shrunk in respective resizing direction and only then it starts behaving as it should. Also not in this case that I set holding priorities of splitViews in such a way so that when the window resizes, the superview of the playerView is the one to start expanding/shrinking and it does so until the playerView’s intrinsic size is reached (just like when dragging sliders), then it stops, other subviews (with higher holding priority) start shrinking and only once they’re completely shrunk the playerView let go of its intrinsic content size. I tried to set the content compression priority very low (=1), but no difference in behaviour. I also played with different level on holding proprieties of splitViews’ subview, that didn’t help either. I suppose some NSSplitView behaviour is involved here, but I don’t know which one and I’m not able to figure it out. (As a side note, NSSplitView was quite a pain with springs & struts, it seems to continue being so with autolayout). Any help in demystifying this behaviour is very appreciated. -- 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]
