Re: ambiguous layout for documentView in NSScrollView
Re: ambiguous layout for documentView in NSScrollView
- Subject: Re: ambiguous layout for documentView in NSScrollView
- From: Chuck Soper <email@hidden>
- Date: Sat, 16 Mar 2013 20:57:26 -0700
- Thread-topic: ambiguous layout for documentView in NSScrollView
On 3/16/13 6:59 PM, "Kyle Sluder" <email@hidden> wrote:
>On Sat, Mar 16, 2013, at 05:38 PM, Chuck Soper wrote:
>> I thought I'd create a new thread because I'm not sure I need to take
>> that
>> general approach for my specific case. My user interface works fine. The
>> problem is that my documentView is ambiguous, but I think I can ignore
>> that fact for my particular case. Here are the details:
>>
>> My documentView is a custom NSView subclass.
>>
>> From awakeFromNib in my documentView, I call:
>> [self setTranslatesAutoresizingMaskIntoConstraints:NO];
>
>This is the root of your problem. If you watch my auto layout talk,
>which I gave before devising the solution I presented in the other
>thread, I discuss how our then-current approach used this strategy and
>noted the persistent layout ambiguity it caused.
Is persistent layout ambiguity (for the documentView only) necessarily a
problem? My UI works fine. I don't see how having the documentView
ambiguous is causing a problem.
I'll review your previous email and try to listen to your auto layout talk.
Previously, I didn't call setTranslatesAutoresizingMaskIntoConstraints: on
my documentView. I just added a subview to documentView and called
setFrameSize: on the documentView. This worked great until I needed to
change the width of the documentView by dragging the mouse.
I'm starting to seriously regret trying to use auto layout with
NSScrollView. I already have a quite a bit of of code that uses auto
layout within the subviews of my documentView.
>>
>>
>> I override updateConstraints in my documentView, and set up the
>>following
>> constraints (built in a for loop for 1 to N subviews):
>> @"H:|[subview1][subview2][subview3]|"
>>
>>
>> Each subview has an "NSLayoutConstraint * widthConstraint;" ivar that
>> holds the absolute width. Visually, it looks like this:
>> @"H:[subview(==120)]"
>
>You have now fixed the width of your documentView at (120 * N) points
>wide.
Yes, that's correct. So, the documentView is 360 points wide for this
example.
>
>>
>>
>> I also added some minimum width and height constraints that look like
>> this:
>> @"H:[subview(>=80)]" and @"V:[subview(>=70)]"
>
>The horizontal constraint is unnecessary; the views are already at a
>fixed width.
Thanks. Good point.
>>
>>
>> To pin the height of the documentView to its NSScrollView, I use the
>> following constraint:
>> NSDictionary * scrollViewsDict =
>> NSDictionaryOfVariableBindings(documentView);
>>
>> [scrollView addConstraints: [NSLayoutConstraint
>> constraintsWithVisualFormat:
>> @"V:|[documentView]|" options: 0 metrics: nil views:
>> scrollViewsDict]];
>
>You have not shown any other vertical constraints for your subviews. If
>all you have are the ">= 70" constraints, there are infinitely many
>solutions to your document view height. That would be the source of your
>ambiguity.
I neglected to mentioned that in my documentView's updateConstraints
method that I add @"V:|[subview(>=70)]|" to self for each subview.
I thought the source of the ambiguity was related to not setting width
constraint for the documentView. I do set each subview with
@"H:[subview(==120)]" and specify the documentView layout with
@"H:|[subview1][subview2][subview3]|" but I'm not sure that's enough.
>>
>> Actions and behavior:
>>
>> - Resizing the window changes the height of the documentView but not the
>> width.
>> - The width of each subview can be changed by adjusting the constraint
>> constant, like this: subview1.widthConstraint.constant = 220.0;
>
>If you're manually updating the constants of these constraints, you
>either need to clamp the value at a minimum of 80, or you need to make
>the ">= 80" constraints a higher priority than the "==120" constraints.
>Otherwise the first time you make the equality constraints' constants
>less than 80, you will get an unsatisfiable constraints exception, and
>AppKit will break one of your constraints.
>
>--Kyle Sluder
Thanks for mentioning that. I actually check for the minimum width of 80
before setting subview.widthConstraint.constant when dragging the mouse. I
added that check when I got an unsatisfiable constraints exception. You're
correct. The the ">= 80" constraints may not be needed.
Chuck
_______________________________________________
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