>>>
In the “View Programming Guide” you quoted is written:

Important: Several cautions apply to autoresizing. For autoresizing to work correctly, the subview being autoresized must lie completely within its superview’s frame.
<<<

I could be imagining things, but I *think* the “drifting subview” problem has been observed even when a generous minimum size has been specified for the enclosing view. The only way to avoid the problem completely is never to have more than one spring in a given direction (horizontal or vertical) for a given view. Roundoff errors occur when autoresizing tries to distribute a given number of pixels between two “springy” areas, based on some ratio. If there is only one spring, there is no ratio to compute; you just take the number of pixels left over after subtracting the sizes of the struts.

At least that’s my theory; I haven’t experimented with this stuff in a while.

It looks like views compute their new size by trying to preserve the margins and/or proportions from their *previous* size and position rather than their *original* size and position — what Dirk referred to as the use of real-time coordinates.

I think the problem is that when a margin gets close to 0, something causes it to be rounded to 0. I’m not sure if floating point rounding errors would be large enough to make this happen. I’ve wondered whether autoresizing explicitly rounds some coordinates to integers; I think I even tested this theory once with some NSLogs, but if so it was long ago. In any case, once a margin becomes 0, it tends to stay that way, because 0 always scales to 0. The only way to force it to become non-zero again is (in your example) to make the outer view smaller than the inner view. The inner view’s fixed size will be preserved, because struts apparently have higher precedence than springs. This would explain the lopsidedness that follows. The views have totally forgotten that one was centered inside the other; they are preserving whatever margin proportions you created at the moment you forced the stuck edges to separate.

As for the “sticking” only happening sometimes — I think in your experiments when you’re dragging to resize, it’s a matter of chance whether you hit the exact size that’s going to make a margin 0 at the exact time that a resizing event occurs. I think the “sticking” is more likely to happen if you’re dragging slowly enough for resize events to happen at almost every pixel that you move. For example, imagine you have the inner view with just a one-pixel margin all around, and then ever so carefully shrink the window by exactly two pixels.

Anyway, I’m not sure I’m saying a whole lot that’s new — Dirk was getting at some of the same points — but I’ve been meaning to comment on this post for ages, because it’s an interesting problem. One of these days I’ll check out the more sophisticated capabilities of CALayer.

Like Jense I’ve never thought of the splitters snapping shut as a design flaw. Comming from a non-cocoa environment where we didn’t have this problem I put time into getting our splitters to snap - the issue is that if you have, say, a list of icons with labels there is not that much point in having a splitter 4px running the width of the window. It would be less than 1/2 an icon. As a user I find this messy and not useful. As I remember when implementing the snapping behavior I was working on 10.3 & 10.4 and looked quite carefully at the Finder. As I remember they implemented the snapping at the point where you would otherwise get less than an icon. I think they got it right - when you move the splitter want to see more, or less. To me the extremes are as much as possible, nothing or the minimum that is useful.

For the avoidance of doubt, I think that the Auto Resizing behaviour *should* behave properly.

once a split view is in the picture, views don’t lie completely within their super view’s frame. most modern apps are based around a single window with a split view design. and usually there are more split views inside those split views. that kind of restriction is compeltely not realistic! : )

A subclass can override resizeSubviewsWithOldSize: or resizeWithOldSuperviewSize: to customize the autoresizing behavior for a view.

Important: Several cautions apply to autoresizing. For autoresizing to work correctly, the subview being autoresized must lie completely within its superview’s frame.

As far as the split view thing goes, my opinion certainly has alot to do with my personal preferences. I absolutely hate it when i can’t resize a window as much as i want, even though I completely understand that for some layouts, there absoultely needs to be a min size of the window or else buttons and things will be drawn ontop of each other or they’ll be out of the view. Same for split views. I want to drag back and forth as much as I want. I’m fidgety that way, I like to play with the interfaces. When I can’t and there’s no obvious layout reason why, first I think it’s broken, then when it finally snaps, I get annoyed. But that’s Just me.

One problem is the way people do it. Dirk Stoop pointed this out to me and I think it makes a difference. If you’re going to stop people from dragging any further, change the cursur icon from the left/right or up/down icons to ones that show only one direction. Then it’s more obvious that you can’t go any further and you’ll stop trying to pull it. If you’re going to snap it, change the cursur back to the arrow right away, don’t wait for the mouse up. Details like that help the user understand what’s going on. It’s nice to let them know they’re no longer in control.

These situations might also be the right time for a little animation to help clear things up. The snapping is so jarring.

(Springs-and-struts can be a pain, but every other layout mechanism I’ve experienced is much worse. Have you ever used Java’s LayoutManagers? I vividly remember building a simple inspector window in Swing that took me two whole days of messing with the dreaded GridBagLayoutManager, which I could have built in ten minutes with IB.)

rdar://problem/5742732

By the way, whenever you mention that you’ve filed a Radar bug, you should link to it for the benefit of any Apple employees who should run across your post. The syntax is rdar://problem/######.