Arrgh IB constraints

  • Is there anything that describes how I'm supposed to use IB to set layout constraints? It keeps putting stuff in there, and then not behaving properly at run time. I can't delete half the constraints until I add other ones, and even then it adds constraints that don't need to be there.

    I almost always want to mimic the old behavior, of fixed margins and flexible growth for a view, but that seems very hard to do.

    --
    Rick
  • On Jul 8, 2012, at 6:12 PM, Rick Mann wrote:

    > Is there anything that describes how I'm supposed to use IB to set layout constraints? It keeps putting stuff in there, and then not behaving properly at run time. I can't delete half the constraints until I add other ones, and even then it adds constraints that don't need to be there.

    I've been struggling with this too. I think it will just take me a while (and lots of practice on small, test projects) to get to the point where I can say "I think I understand this".

    Having said that… there are some Apple WWDC 2012 videos online that are a good starting point. Go to the Apple Developer site, find the WWDC 2012 videos, and search for "Layout". There are at least three talks.

    Todd
  • On Jul 8, 2012, at 18:21 , Todd Heberlein wrote:

    >
    > On Jul 8, 2012, at 6:12 PM, Rick Mann wrote:
    >
    >> Is there anything that describes how I'm supposed to use IB to set layout constraints? It keeps putting stuff in there, and then not behaving properly at run time. I can't delete half the constraints until I add other ones, and even then it adds constraints that don't need to be there.
    >
    > I've been struggling with this too. I think it will just take me a while (and lots of practice on small, test projects) to get to the point where I can say "I think I understand this".
    >
    > Having said that… there are some Apple WWDC 2012 videos online that are a good starting point. Go to the Apple Developer site, find the WWDC 2012 videos, and search for "Layout". There are at least three talks.

    Thanks, Todd, I'll give that a try.

    I don't have a problem understanding the concepts of constraints, at least at the most basic use (I definitely don't understand the priority system). But what flummoxes me is the way IB inserts constraints willy-nilly, and doesn't make it easy to set basic constraints. Not to mention that if you pin one edge of a view to its superview (for example), it then selects that new constraint, making it tedious to then pin the remaining three edges.

    It also doesn't do a good job of showing you what a particular constraint is really constraining (which views and attributes that are involved).

    --
    Rick
  • On Jul 8, 2012, at 8:21 PM, Todd Heberlein wrote:

    > On Jul 8, 2012, at 6:12 PM, Rick Mann wrote:
    >
    >> Is there anything that describes how I'm supposed to use IB to set layout constraints? It keeps putting stuff in there, and then not behaving properly at run time. I can't delete half the constraints until I add other ones, and even then it adds constraints that don't need to be there.
    >
    > I've been struggling with this too. I think it will just take me a while (and lots of practice on small, test projects) to get to the point where I can say "I think I understand this".
    >
    > Having said that… there are some Apple WWDC 2012 videos online that are a good starting point. Go to the Apple Developer site, find the WWDC 2012 videos, and search for "Layout". There are at least three talks.

    I went through a bunch of “argh” with constraints a while ago, but I think I’ve figured out a lot about it. The technology is actually great; it’s that it’s extremely poorly documented.

    What’s your exact problem? If it’s one of the same things I was banging my head against earlier, I might be able to help.

    Charles
  • On Jul 8, 2012, at 18:26 , Charles Srstka wrote:

    > What’s your exact problem? If it’s one of the same things I was banging my head against earlier, I might be able to help.

    In this case, I'm working with a two-pane horizontal split view (resizes in the vertical direction). I already know there's a bug in which IB does not enforce the same constraint as the run-time (this was confirmed a few weeks ago by an Apple person on the list).

    But now I have it looking like I want it to in IB, but at run time it changes the layout when first creating the window.

    The top pane (heh, I mis-typed this as "pain") has an NSTextView (which is inside an NSScrollView).

    The bottom pane has an NSTextField inset a few pixels, and a button on the right. The bottom pane is much smaller than the top pane, just big enough to hold a one-line NSTextField. In that configuration, the button is vertically centered in the pane, and horizontally centered between the NSTextField and the right edge.

    When the split view is resized, I want the NSTextField (NSScrollView) in the top pane to just grow and shrink, filling the entire pane. I want the NSTextField in the bottom to grow and shrink, maintaining the same few-pixel inset around the top, left, and bottom edges. I want the button to stay pinned to the bottom.

    If the window is resized horizontally, both text views should grow with it (that is, they should be pinned left and right). The button should be pinned right and bottom. If the window is resized vertically, the entire bottom pane should remain at whatever size it's at, and the top pane should grow or shrink.

    Both panes should have a minimum height, and a minimum width (the window can have the minimum width).

    Layout in IB:

    http://www.flickr.com/photos/jetforme/7532142304/

    At runtime:

    http://www.flickr.com/photos/jetforme/7532142250/

    Currently, although it looks correct in IB, at run time the split view position changes so that both panes appear to be equal height. The runtime constraints currently behave correctly, except that vertical resizing of the window resizes both panes proportionally.

    I do get several complaints about constraints on launch:

    2012-07-08 18:19:45.577 Console[49250:403] Unable to simultaneously satisfy constraints:
    (
        "<NSAutoresizingMaskLayoutConstraint:0x7fde9b83a160 h=--& v=--& H:[NSView:0x1029952d0(0)]>",
        "<NSLayoutConstraint:0x1029960a0 H:[NSTextField:0x7fde9b81fc10]-(79)-|  (Names: '|':NSView:0x1029952d0 )>",
        "<NSLayoutConstraint:0x102995e80 H:|-(5)-[NSTextField:0x7fde9b81fc10]  (Names: '|':NSView:0x1029952d0 )>"
    )

    Will attempt to recover by breaking constraint
    <NSLayoutConstraint:0x1029960a0 H:[NSTextField:0x7fde9b81fc10]-(79)-|  (Names: '|':NSView:0x1029952d0 )>

    Set the NSUserDefault NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints to YES to have -[NSWindow visualizeConstraints:] automatically called when this happens.  And/or, break on objc_exception_throw to catch this in the debugger.
    2012-07-08 18:19:45.579 Console[49250:403] Unable to simultaneously satisfy constraints:
    (
        "<NSAutoresizingMaskLayoutConstraint:0x7fde9b83a080 h=--& v=--& V:[NSView:0x1029952d0(0)]>",
        "<NSLayoutConstraint:0x102996310 V:[NSTextField:0x7fde9b81fc10]-(3)-|  (Names: '|':NSView:0x1029952d0 )>",
        "<NSLayoutConstraint:0x102996210 V:|-(3)-[NSTextField:0x7fde9b81fc10]  (Names: '|':NSView:0x1029952d0 )>"
    )

    Will attempt to recover by breaking constraint
    <NSLayoutConstraint:0x102996310 V:[NSTextField:0x7fde9b81fc10]-(3)-|  (Names: '|':NSView:0x1029952d0 )>

    Set the NSUserDefault NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints to YES to have -[NSWindow visualizeConstraints:] automatically called when this happens.  And/or, break on objc_exception_throw to catch this in the debugger.
  • On Jul 8, 2012, at 8:43 PM, Rick Mann wrote:

    > 2012-07-08 18:19:45.577 Console[49250:403] Unable to simultaneously satisfy constraints:
    > (
    > "<NSAutoresizingMaskLayoutConstraint:0x7fde9b83a160 h=--& v=--& H:[NSView:0x1029952d0(0)]>",
    > "<NSLayoutConstraint:0x1029960a0 H:[NSTextField:0x7fde9b81fc10]-(79)-|  (Names: '|':NSView:0x1029952d0 )>",
    > "<NSLayoutConstraint:0x102995e80 H:|-(5)-[NSTextField:0x7fde9b81fc10]  (Names: '|':NSView:0x1029952d0 )>"
    > )

    Actually for this, try giving the view a width constraint, but make it a “Greater Than Or Equal” constraint instead of a straight one. Then, if the system makes another width constraint for you, give that one a lower priority. You probably want to have a Greater Than Or Equal height constraint too, so that the view doesn’t get squished to the point of invisibility.

    Charles
  • On Jul 8, 2012, at 19:01 , Charles Srstka wrote:

    > You might have a case of ambiguity here (although the screenshot seems to suggest you don’t, which is odd). Ambiguity is why IB keeps liking to add stuff — you’ve got it so that the pane size is flexible, and the view sizes are flexible, but there’s no real indication of how things should start out. The physical sizes of stuff in IB is irrelevant to how things will display at runtime — the constraints are all that the system uses. So, try pinning the lower view’s height. That will let the system know how tall you want that view to be. However, so that it’ll still be resizable, set the height contraint’s priority to something relatively high, but less than 1000 (required). Maybe 750 or so. Then, the system will honor your height constraint when setting up initially, but will let your user break it without complaining after the fact.

    Wow, really? I think it SHOULD use the actual sizes as specified in IB. There's a wealth of information there, and I can't think of a better way to specify what the default window should look like.

    The idea of adding a height constraint really rubs me the wrong way, as I don't want to constrain it (other than to make it a >= constraint). By the way, how DO I add such a constraint? I tried to Pin the bottom pane's custom view, but all those options are disabled.

    Oh, I was able to add a >= 22 px height constraint to the text view (but not its parent), but then the entire window at run time was a different height, and the constraint did not do what I expected: it pushed the bottom edge of the text field off the bottom edge of the window as soon as it got down to 22 pixels high. So, it constrained the height, but not the parent view's height.

    >
    >> I do get several complaints about constraints on launch:
    >>
    >> 2012-07-08 18:19:45.577 Console[49250:403] Unable to simultaneously satisfy constraints:
    >> (
    >> "<NSAutoresizingMaskLayoutConstraint:0x7fde9b83a160 h=--& v=--& H:[NSView:0x1029952d0(0)]>",
    >> "<NSLayoutConstraint:0x1029960a0 H:[NSTextField:0x7fde9b81fc10]-(79)-|  (Names: '|':NSView:0x1029952d0 )>",
    >> "<NSLayoutConstraint:0x102995e80 H:|-(5)-[NSTextField:0x7fde9b81fc10]  (Names: '|':NSView:0x1029952d0 )>"
    >> )
    >>
    >> Will attempt to recover by breaking constraint
    >> <NSLayoutConstraint:0x1029960a0 H:[NSTextField:0x7fde9b81fc10]-(79)-|  (Names: '|':NSView:0x1029952d0 )>
    >
    > Argh, now this stuff is frustrating. I really, really wish those autoresizing masks would stay out of it when autolayout is on. I’m assuming this is the lower text view; could you post a screenshot of all the constraints for that view? They should be listed nicely in the Size inspector in IB.

    It doesn't show anything in the size inspector, just content hugging priority and content compression resistance priority. The outline view in one of the posted images shows more constraints, but not terribly descriptively.

    --
    Rick
  • On Jul 8, 2012, at 9:11 PM, Rick Mann wrote:

    > Wow, really? I think it SHOULD use the actual sizes as specified in IB. There's a wealth of information there, and I can't think of a better way to specify what the default window should look like.

    Well, it tries to sync the constraints with what you’re seeing in IB. That’s why IB keeps adding stuff. ;-)

    > The idea of adding a height constraint really rubs me the wrong way, as I don't want to constrain it (other than to make it a >= constraint). By the way, how DO I add such a constraint? I tried to Pin the bottom pane's custom view, but all those options are disabled.

    Select the text view, then go to Editor -> Pin -> Height. You don’t need to worry about the pane, because if the text view’s height is pinned and it’s also pinned to the edges, that’ll constrain the size of its superview too.

    > Oh, I was able to add a >= 22 px height constraint to the text view (but not its parent), but then the entire window at run time was a different height, and the constraint did not do what I expected: it pushed the bottom edge of the text field off the bottom edge of the window as soon as it got down to 22 pixels high. So, it constrained the height, but not the parent view's height.

    Did a “broken constraint” message get logged that time?

    > It doesn't show anything in the size inspector, just content hugging priority and content compression resistance priority. The outline view in one of the posted images shows more constraints, but not terribly descriptively.

    Oops, you are correct that they don’t show there in the currently shipping version of Xcode. Please forget that I said anything regarding that (Apple, please don’t kill me). Apologies!

    Instead, click the little right-facing triangle thing at the lower left-hand corner of the IB pane and it’ll show you a list of all objects, which you can use to single out the constraints.

    Charles
  • On Jul 8, 2012, at 9:11 PM, Rick Mann wrote:

    > Wow, really? I think it SHOULD use the actual sizes as specified in IB. There's a wealth of information there, and I can't think of a better way to specify what the default window should look like.

    As an addendum to my previous e-mail, another thing I’ve learned is never to call setFrame: when constraints are being used. It has no effect most of the time, as the views’ frames will all get overwritten by constraints in short order.

    > The idea of adding a height constraint really rubs me the wrong way, as I don't want to constrain it (other than to make it a >= constraint).

    You have to get used to the new way of thinking about things. No height constraint is literally telling the system, “I don’t care how high you make this view. Make it 1 px high, make it 1,000,000 px high, it’s all the same to me.”

    With no height constraint, the system doesn’t know how it should look at startup, and therefore that picture with the bottom pane being half the window’s height is just as legit as the bottom text view being one line high.

    Charles
  • On Jul 8, 2012, at 19:32 , Charles Srstka wrote:

    > You have to get used to the new way of thinking about things. No height constraint is literally telling the system, “I don’t care how high you make this view. Make it 1 px high, make it 1,000,000 px high, it’s all the same to me.”

    So, I don't care, other than to say, "don't make it smaller than x" (that is, a >= height constraint). But aside from that I want it to satisfy the other constraint, which is to make it as big as the parent view, minus some margin.

    Given that the parent view can resize, an equal height constraint is not appropriate. But for the initial layout, assuming the constraints are not in conflict, the sizes specified in IB are an excellent starting point (BTW, IB should not allow you to add constraints that don't match the layout as it stands in IB).

    So, the way I see it, if I don't specify a constraint, it should still lay out the initial views based on the sizes (and positions) specified in IB, and then from there follow the constraints when resizing. This would not prevent it from getting too small, and is much more elegant than adding a constraint specifying a particular hight, which then requires mucking with priorities.

    > With no height constraint, the system doesn’t know how it should look at startup, and therefore that picture with the bottom pane being half the window’s height is just as legit as the bottom text view being one line high.

    On the contrary, it has a perfectly reasonable size at startup. Assuming, of course, that IB didn't allow me to add conflicting constraints.

    --
    Rick
  • On Jul 8, 2012, at 9:48 PM, Rick Mann wrote:

    >> With no height constraint, the system doesn’t know how it should look at startup, and therefore that picture with the bottom pane being half the window’s height is just as legit as the bottom text view being one line high.
    >
    > On the contrary, it has a perfectly reasonable size at startup. Assuming, of course, that IB didn't allow me to add conflicting constraints.

    Well, not really; what if you’re running a German localization, and the title of the “Send” button gets swapped out to “Senden”? Now the button won’t be wide enough for its title.

    Cocoa Auto Layout does exactly what it says on the tin; it Automatically does the Layout. This means that the view frames don’t matter. Those get overwritten when the system automatically calculates a new layout for everything based on the constraints.

    Would you mind maybe posting the .xib file that’s giving you trouble? I could monkey around with it a bit and see if I could figure out anything that way.

    Charles
  • On Jul 8, 2012, at 20:56 , Charles Srstka wrote:

    > On Jul 8, 2012, at 9:48 PM, Rick Mann wrote:
    >
    >>> With no height constraint, the system doesn’t know how it should look at startup, and therefore that picture with the bottom pane being half the window’s height is just as legit as the bottom text view being one line high.
    >>
    >> On the contrary, it has a perfectly reasonable size at startup. Assuming, of course, that IB didn't allow me to add conflicting constraints.
    >
    > Well, not really; what if you’re running a German localization, and the title of the “Send” button gets swapped out to “Senden”? Now the button won’t be wide enough for its title.

    Again, I'd argue it works just fine. Start with the view as specified in IB. Then change the title, then try to adjust the size. In this example, buttons have an intrinsic size that the system uses, based on the content.

    But my situation is the text view and split view pane, which (AFAIK) don't have intrinsic sizes. So, a good starting point is the size specified in IB.

    NIB coming under separate cover.

    >
    > Cocoa Auto Layout does exactly what it says on the tin; it Automatically does the Layout. This means that the view frames don’t matter. Those get overwritten when the system automatically calculates a new layout for everything based on the constraints.
    >
    > Would you mind maybe posting the .xib file that’s giving you trouble? I could monkey around with it a bit and see if I could figure out anything that way.
    >
    > Charles
    >
  • Thanks for all your help, Charles.

    So, I'm getting the exact same behavior your video shows. I definitely don't want the bottom pane to get any smaller, and I can enforce that the old way, but it seems pretty lame that they didn't update it to work with autolayout.

    I figured out why it was adding extra constraints to the top pane; I've got that down to four. There don't appear to be any problems there (other than an inability to specify a minimum height).

    It's the bottom that has so many issues.

    I just sent you the NIB file. I'm going to keep poking at it.

    BTW, if the NSSplitView hasn't been updated to use constraints in its own layout, then why does it and up changing the size at runtime? For that matter it seems like IB is expressly forbidding adding constraints to the NSSplitView's panes.

    --
    Rick

    On Jul 8, 2012, at 20:46 , Charles Srstka wrote:

    > On Jul 8, 2012, at 10:23 PM, Rick Mann wrote:
    >
    >> On Jul 8, 2012, at 19:01 , Charles Srstka wrote:
    >>
    >>> Argh, now this stuff is frustrating. I really, really wish those autoresizing masks would stay out of it when autolayout is on. I’m assuming this is the lower text view; could you post a screenshot of all the constraints for that view? They should be listed nicely in the Size inspector in IB.
    >>
    >> Do I need to turn off the translatesAutoresizingMaskIntoConstraints on all my views? It's annoying, because IB doesn't actually me specify autoresizing masks, and I'm using autolayout in the nib file.
    >
    > I don’t think so, since I just decided to try to recreate your nib file at home and see if I could reproduce the problem. I think I *have* found the source of some of your “broken constraint” messages; I had forgotten something about split views; seems my initial instinct was wrong, and it doesn’t seem to use constraints to determine the position of the splitter. Moreover, it doesn’t let constraints keep the user from resizing the bottom pane smaller than your minimum size for that view, and when you do it, you get a crapton of broken constraint warnings (both these things are probably due to NSSplitView being created well before the advent of constraints and not being completely savvy regarding them). So you actually want to make the priority of the “Bottom Space” constraints 999 instead of 1000. This allows the layout system to actually move these views below the bounds of its superview if it has to. You also want to make a “Greater than or Equal” constraint from the button to the top edge of the superview, so that the constraint system pushes it off the bottom rather than the top. This video will sort of demonstrate:
    >
    > http://www.charlessoft.com/extraneous_stuff/constraints.m4v
    >
    > Next, I’m going to try to see if I can figure out a way to screw this xib file up and make it exhibit the behavior you’re describing. I’m a bit suspicious of all those constraints for the top pane, which should really be only four, one for each edge of the text view. Could you expand that pane a bit more so I can see the descriptions of all those constraints a little better?
    >
    > Charles
  • > BTW, if the NSSplitView hasn't been updated to use constraints in its own layout, then why does it and up changing the size at runtime? For that matter it seems like IB is expressly forbidding adding constraints to the NSSplitView's panes.
    There are known bugs with NSSplitView and auto layout on OS X 10.7 with both the runtime and with IB.  Mainly, even if you say a particular pane should be >= 100 (for example), you can still drag the splitter right past the 100pt mark.

    See the WWDC videos from this year for more information…

    On Jul 8, 2012, at 9:01 PM, Rick Mann <rmann...> wrote:

    > Thanks for all your help, Charles.
    >
    > So, I'm getting the exact same behavior your video shows. I definitely don't want the bottom pane to get any smaller, and I can enforce that the old way, but it seems pretty lame that they didn't update it to work with autolayout.
    >
    > I figured out why it was adding extra constraints to the top pane; I've got that down to four. There don't appear to be any problems there (other than an inability to specify a minimum height).
    >
    > It's the bottom that has so many issues.
    >
    > I just sent you the NIB file. I'm going to keep poking at it.
    >
    > BTW, if the NSSplitView hasn't been updated to use constraints in its own layout, then why does it and up changing the size at runtime? For that matter it seems like IB is expressly forbidding adding constraints to the NSSplitView's panes.
    >
    > --
    > Rick
    >
    >
    > On Jul 8, 2012, at 20:46 , Charles Srstka wrote:
    >
    >> On Jul 8, 2012, at 10:23 PM, Rick Mann wrote:
    >>
    >>> On Jul 8, 2012, at 19:01 , Charles Srstka wrote:
    >>>
    >>>> Argh, now this stuff is frustrating. I really, really wish those autoresizing masks would stay out of it when autolayout is on. I’m assuming this is the lower text view; could you post a screenshot of all the constraints for that view? They should be listed nicely in the Size inspector in IB.
    >>>
    >>> Do I need to turn off the translatesAutoresizingMaskIntoConstraints on all my views? It's annoying, because IB doesn't actually me specify autoresizing masks, and I'm using autolayout in the nib file.
    >>
    >> I don’t think so, since I just decided to try to recreate your nib file at home and see if I could reproduce the problem. I think I *have* found the source of some of your “broken constraint” messages; I had forgotten something about split views; seems my initial instinct was wrong, and it doesn’t seem to use constraints to determine the position of the splitter. Moreover, it doesn’t let constraints keep the user from resizing the bottom pane smaller than your minimum size for that view, and when you do it, you get a crapton of broken constraint warnings (both these things are probably due to NSSplitView being created well before the advent of constraints and not being completely savvy regarding them). So you actually want to make the priority of the “Bottom Space” constraints 999 instead of 1000. This allows the layout system to actually move these views below the bounds of its superview if it has to. You also want to make a “Greater than or Equal” constraint from the button to the top edge of the superview, so that the constraint system pushes it off the bottom rather than the top. This video will sort of demonstrate:
    >>
    >> http://www.charlessoft.com/extraneous_stuff/constraints.m4v
    >>
    >> Next, I’m going to try to see if I can figure out a way to screw this xib file up and make it exhibit the behavior you’re describing. I’m a bit suspicious of all those constraints for the top pane, which should really be only four, one for each edge of the text view. Could you expand that pane a bit more so I can see the descriptions of all those constraints a little better?
    >>
    >> Charles

  • Which videos? I've watched the first two on constraints, and don't recall any mention of nssplitview.

    Sent from my iPhone

    On Jul 9, 2012, at 8:33, Kevin Cathey <cathey...> wrote:

    >> BTW, if the NSSplitView hasn't been updated to use constraints in its own layout, then why does it and up changing the size at runtime? For that matter it seems like IB is expressly forbidding adding constraints to the NSSplitView's panes.
    > There are known bugs with NSSplitView and auto layout on OS X 10.7 with both the runtime and with IB.  Mainly, even if you say a particular pane should be >= 100 (for example), you can still drag the splitter right past the 100pt mark.
    >
    > See the WWDC videos from this year for more information…
    >
    >
    > On Jul 8, 2012, at 9:01 PM, Rick Mann <rmann...> wrote:
    >
    >> Thanks for all your help, Charles.
    >>
    >> So, I'm getting the exact same behavior your video shows. I definitely don't want the bottom pane to get any smaller, and I can enforce that the old way, but it seems pretty lame that they didn't update it to work with autolayout.
    >>
    >> I figured out why it was adding extra constraints to the top pane; I've got that down to four. There don't appear to be any problems there (other than an inability to specify a minimum height).
    >>
    >> It's the bottom that has so many issues.
    >>
    >> I just sent you the NIB file. I'm going to keep poking at it.
    >>
    >> BTW, if the NSSplitView hasn't been updated to use constraints in its own layout, then why does it and up changing the size at runtime? For that matter it seems like IB is expressly forbidding adding constraints to the NSSplitView's panes.
    >>
    >> --
    >> Rick
    >>
    >>
    >> On Jul 8, 2012, at 20:46 , Charles Srstka wrote:
    >>
    >>> On Jul 8, 2012, at 10:23 PM, Rick Mann wrote:
    >>>
    >>>> On Jul 8, 2012, at 19:01 , Charles Srstka wrote:
    >>>>
    >>>>> Argh, now this stuff is frustrating. I really, really wish those autoresizing masks would stay out of it when autolayout is on. I’m assuming this is the lower text view; could you post a screenshot of all the constraints for that view? They should be listed nicely in the Size inspector in IB.
    >>>>
    >>>> Do I need to turn off the translatesAutoresizingMaskIntoConstraints on all my views? It's annoying, because IB doesn't actually me specify autoresizing masks, and I'm using autolayout in the nib file.
    >>>
    >>> I don’t think so, since I just decided to try to recreate your nib file at home and see if I could reproduce the problem. I think I *have* found the source of some of your “broken constraint” messages; I had forgotten something about split views; seems my initial instinct was wrong, and it doesn’t seem to use constraints to determine the position of the splitter. Moreover, it doesn’t let constraints keep the user from resizing the bottom pane smaller than your minimum size for that view, and when you do it, you get a crapton of broken constraint warnings (both these things are probably due to NSSplitView being created well before the advent of constraints and not being completely savvy regarding them). So you actually want to make the priority of the “Bottom Space” constraints 999 instead of 1000. This allows the layout system to actually move these views below the bounds of its superview if it has to. You also want to make a “Greater than or Equal” constraint from the button to the top edge of the superview, so that the constraint system pushes it off the bottom rather than the top. This video will sort of demonstrate:
    >>>
    >>> http://www.charlessoft.com/extraneous_stuff/constraints.m4v
    >>>
    >>> Next, I’m going to try to see if I can figure out a way to screw this xib file up and make it exhibit the behavior you’re describing. I’m a bit suspicious of all those constraints for the top pane, which should really be only four, one for each edge of the text view. Could you expand that pane a bit more so I can see the descriptions of all those constraints a little better?
    >>>
    >>> Charles

    >
  • On Jul 9, 2012, at 10:33 AM, Kevin Cathey wrote:

    >> BTW, if the NSSplitView hasn't been updated to use constraints in its own layout, then why does it and up changing the size at runtime? For that matter it seems like IB is expressly forbidding adding constraints to the NSSplitView's panes.
    > There are known bugs with NSSplitView and auto layout on OS X 10.7 with both the runtime and with IB.  Mainly, even if you say a particular pane should be >= 100 (for example), you can still drag the splitter right past the 100pt mark.
    >
    > See the WWDC videos from this year for more information…

    Conversing via private e-mail last night, we figured out that the problem was triggered by having a combination of an NSSplitView and an NSToolbar in the same window. Doing this even in a simple test-case app causes the split view to wig out. If you delete the toolbar, it works fine.

    Bug report filed: rdar://11828261 .

    Charles
previous month july 2012 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today