A small tip (that someone else handed to me). If you’re going to post bug-report numbers publicly, you might want to use the ‘rdar’ URL. Supposedly, it’ll help Apple folks find quickly look up bug reports. Details here: http://rentzsch.com/notes/rdarUrls

I do hope that CocoaTouch is made available for Mac apps to use. It’s a better implementation in many ways, and it was designed by people who lived and breathed the AppKit for decades.

-jcr

I could subclass each of the views in my example project from the first post and hard code the resizing behavior using these methods. It would work in this case.

The one that stays centered is easy, but for the one that resizes with the window, I’ll have to make some iVars to keep track of the margins I’m trying to maintain since I can’t get them from NSView. I’ll also want to subclass the setAutoresizingMask method in case that information changes during runtime. Already, things are getting a little messy, but that’s fine, there are two views in that example.

In a medium to large interface project, this kind of approach isn’t really maintainable and really susceptible to bugs.

I think that if you want to define your own layout behavior for NSView, it’s cleaner and easier to debug if you make some sort of layout class that you keep in NSView instead of using the built-in autoresizing. You could still use the masks, but why limit yourself to those options at that point?

Also, this still doesn’t change the issue I’m ranting about in this post, which is, I think, the harder thing to deal with when you have a view hierarchy that changes while the app is running. A constraints based system is a much nicer way to define a layout for a view hierarchy that is going to change during runtime.

“When you turn off a view’s autoresizing, all of its descendants are likewise shielded from changes in the superview. Changes to subviews, however, can still percolate downward. Similarly, if a subview has no autoresize mask, it won’t change in size, and therefore none of its subviews autoresize.

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

That would mean getting rid of all 177 public classes listed in the AppKit headers, many of which solve some very tricky programming problems. Practically every modern piece of Mac software in use or currently in development (with a few notable exceptions) is based on AppKit.

It sounds like what you want is an updated/refreshed view API, which is totally reasonable and possible to do without tossing out the entire framework. The layout techniques in NSView are one part of a much larger body of code.

I’m a big fan of CALayer’s layout options, it is really as simple or as complex as you need it to be, and that’s a big plus. Good luck with your bug!