(Note to self: it's good to respond to the mailing list instead of just the message author.)
---------- Forwarded message ---------- From: *Ivan Vučica* Date: Friday, September 20, 2013 Subject: NSWindow and delegate methods To: Fred Kiefer <[email protected]> On Thursday, September 19, 2013, Fred Kiefer wrote: > It looks like I added the check for these methods being send to self > about ten years ago. But I don't have any recollection of this. So the > best I can do is look up the Apple documentation for zoom:. There it says: > > "Invokes the windowWillUseStandardFrame:defaultFrame: method, if the > delegate or the window class implements it, to obtain a “best fit” frame > for the window. If neither the delegate nor the window class implements > the method, uses a default frame that nearly fills the current screen, > which is defined to be the screen containing the largest part of the > window’s current frame." > > > I am now a bit unsure what is meant by "the window class". When > implementing the code I thought the method should be called on the > window itself, but it might as well be the class of the window. Later on > for windowShouldZoom:toFrame: the documentation is more clear. > This means that removing this call is not a valid option. Indeed, you're (as always!) right - Apple's text is very clear on this, and subclasses can implement this method. I did not see this. > Moving away > from defined behaviour, just because the code gives warnings on some > overambitious compiler isn't enough reason. > The trouble is I was not getting warnings -- I was getting errors. This is because many of these 'delegate' methods don't return an object -- so they need a valid definition containing the correct return type. Current solution (adding the definition to every NSObject, just like before with an informal protocol) seems less than ideal, because it brings us right where we started. We might as well define the formal protocol to be empty. > I would also think that Greg's fix is not correct, as it removed the > method from the delegate protocol. It looks like in the case of an > optional protocol we need to duplicate the definitions, once in the > protocol and again in an NSObject extension. > Greg's fix (adding a category that happens to implement the formal protocol) did add the methods back into NSObject, at least for me, so I no longer get the errors that I did when he first moved the methods to @protocol. Thing is, should these methods be declared in NSObject? Should we keep supporting the informal protocol once we support the formal one? -- Ivan Vučica [email protected] <javascript:_e({}, 'cvml', '[email protected]');> -- Ivan Vučica [email protected]
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
