[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: When should an NSDocument stop being an NSWindow's delegate?
From: |
David Chisnall |
Subject: |
Re: When should an NSDocument stop being an NSWindow's delegate? |
Date: |
Sun, 25 Oct 2009 22:19:26 +0000 |
On 25 Oct 2009, at 20:36, Fred Kiefer wrote:
What goes on here is really some unusual coding and it took me some
time
to accept it. If you have a better way of doing this ownership
transfer
that is required in the common case. I am willing to change this.
But what ever goes on here is totally unrelated to the issue you are
having. Just forget about this _window ivar.
If I had a better way, then I'd have committed it already. I am not
fully convinced by the transfer of ownership, nor why it is required
that the _window ivar goes away. Given that this is set in the nib
file, it seems wrong that you should be able to set the window in Gorm
and then a call to -window will not return the Window immediately
after the nib is loaded (as happens now). I haven't tested whether
this is what happens on OS X, but I'd be very surprised if it is.
Presumably the question of ownership arises for the purpose of
removing retain cycles. I'd expect, therefore, that the solution
would be to use one of the spare flags in the class to indicate
whether it owned the window, and to remove it if it did.
Unfortunately, this doesn't seem to work (or, didn't when I tried it;
possibly I missed something).
I'm not entirely sure what the best approach is, but I'll keep thinking.
Your problem is that you have the document as the delegate of the
window, but don't have a way to remove this relationship, when the
document gets deallocated. I think the best you can do in that case is
to remove the delegate of the window in _removeWindowController:.
But at
that time the controller no longer has a reference for that window. We
may need to swap a few lines of code here.
That was my third thought, but for as you say, the controller is no
longer the delegate here.
The GNUstep code of NSWindowController has special handling for the
case
where the controller is the delegate of the window. Perhaps this
constellation would fit your needs better? Or we could add similar
special code for the document being the delegate at the same place?
That might be possible. That was my second thought, but I avoided it
because now you have one class controlling the relationship between
two other classes, which seems a bit fragile.
David
-- Sent from my IBM 1620