• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Yet another autolayout question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Yet another autolayout question


  • Subject: Re: Yet another autolayout question
  • From: Ken Thomases <email@hidden>
  • Date: Fri, 13 Nov 2015 04:00:00 -0600

On Nov 13, 2015, at 3:43 AM, Dragan Milić <email@hidden> wrote:
>
> Thanks for the suggestion, but unfortunately that didn’t help :-(

Hmm.  Oh well.

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.


> What I fail to understand is why splitView’s subviews holding priorities would matter at all, especially while dragging its slider. If I understand documentation correctly, holding priorities of splitView’s subviews matter only when the splitView is being resized (in affecting direction) as a whole, that is as a consequence or its superview/window being resized. Why would holding priorities matter when a slider is being dragged by a user?

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.

Regards,
Ken


_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden


  • Follow-Ups:
    • Re: Yet another autolayout question
      • From: Dragan Milić <email@hidden>
    • Re: Yet another autolayout question
      • From: Dragan Milić <email@hidden>
References: 
 >Yet another autolayout question (From: Dragan Milić <email@hidden>)
 >Re: Yet another autolayout question (From: Ken Thomases <email@hidden>)
 >Re: Yet another autolayout question (From: Dragan Milić <email@hidden>)

  • Prev by Date: Re: Yet another autolayout question
  • Next by Date: Re: Yet another autolayout question
  • Previous by thread: Re: Yet another autolayout question
  • Next by thread: Re: Yet another autolayout question
  • Index(es):
    • Date
    • Thread