Re: More Layout Questions


Dave
 

HI,

Thanks for this, I did something like this a long while back and must have confused the “Display” path with the “Layout” path, thanks for putting me on the right track again. The its written it will be very easy to change what I have already to do it the way you describe below.

Honestly, that means using autolayout because that “is thew way Cocoa works these days” but I sympathize with a strong desire to avoid it, as well as there being a number of use cases it simply can’t handle.

The amount of time it was taking to make the board for the game I am working on to work was ridiculous for the return. The number of constraints was enormous and it was really slow when resizing. Add to this that as soon as you wanted to change something it sometimes meant re-doing *lots* of constraints and still it wasn’t 100%. It’s not Auto-Layout itself, the underlying technology is really good and I’d love to use it, but the tools we have for creating the Layouts in the first place are just horrible and unforgiving. I think a lot of it is due to having everything shoved into one giant all-purpose window/tab in Interface Builder. IMO its needs a specialist window that is designed specifically for Auto-Layout generation.

Where you put resize logic probably best depends on who knows the most about how views should be laid out. For a super view that auto resizes subviews, its -resizeSubviewsWithOldSize: method is called anytime its frame changes. That is a better place to perform resizing on subviews, since it will be called by any method that changes the view's frame. If you want each subview to manage itself, you would override -resizeWithOldSuperviewSize: in the view. IMHO, it makes more sense for the superviews to manage their subviews so you avoid a bunch of subclasses that do nothing but self-resizing.
I’m in two minds on this, a lot of the work can be done in a View Base Class that the subviews inherit from, this means that each subview has minimum extra code, but you can override it if you want to. I’m actually working on a number of games that use (mostly) a common board, each Game-App, and I can pull in Custom Views for the Games if I like, just by either adding or replacing a View in the Hierarchy and can be done in IB with no or minimal code changes.


Thanks again for your help.

All the Best
Dave

On 22 Sep 2018, at 16:54, Keary Suska <cocoa-dev@...> wrote:

On Sep 22, 2018, at 5:29 AM, Dave <dave@...> wrote:

Hi,

I’m confused then! The “layout” method has been around a lot longer than Auto Layout and it worked in conjunction with the Auto-Resizing options (defined in the Size Pane in IB). I assumed that in order to customise my layout I would override “layout” as done in the past, is this not the case?
This is incorrect: “layout” methods were added when autolayout was introduced in Lion (10.7). Before that, you used “frame” and “display” methods, and it was generally the responsibility of the superview to resize its subviews when its frame changes.

You seem to be saying that If I want to layout my views myself, I don’t override the layout method or use setNeedsLayout?
Yes.

I could change the name of the method from “layout" to (say) “layoutView” for instance and instead of calling “setNeedsLayout” call “layoutView” on the subviews. However, at the moment when the window is resized, it initially calls “layout” in the WindowTracker view, do I still override this and “layoutView” on its subviews?

The only other way of handling I can think of is to override setFrame and do the layout there, does that sound like a better approach?
Where you put resize logic probably best depends on who knows the most about how views should be laid out. For a super view that auto resizes subviews, its -resizeSubviewsWithOldSize: method is called anytime its frame changes. That is a better place to perform resizing on subviews, since it will be called by any method that changes the view's frame. If you want each subview to manage itself, you would override -resizeWithOldSuperviewSize: in the view. IMHO, it makes more sense for the superviews to manage their subviews so you avoid a bunch of subclasses that do nothing but self-resizing.

I’m just trying to find a decent way of laying out my views that’s fits into the way Cocoa works these days…..
Honestly, that means using autolayout because that “is thew way Cocoa works these days” but I sympathize with a strong desire to avoid it, as well as there being a number of use cases it simply can’t handle.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

On 21 Sep 2018, at 17:28, Quincey Morris <quinceymorris@...> wrote:

On Sep 21, 2018, at 08:07 , Dave <dave@...> wrote:

I’m not sure what you mean, my storyboard file has Auto Layout DISABLED and there are no constraints anywhere in the project. Also, all the old-type layout options are off in the Size Panel in IB.
I mean that if you have disabled auto-layout, then you shouldn’t be trying to use auto-layout. Implementing the “layout” method comes under the heading of “trying to use auto-layout”, as the documentation says.

It may be possible that “layout” gets called anyway (it would have no effect unless you overrode it to do something), but the behavior isn’t documented in that case. You can’t rely on it to behave in any meaningful way.

Join cocoa@apple-dev.groups.io to automatically receive all group messages.