Fred Kiefer wrote:
Just imagine an NSDocument NIB file with plenty of top level objects
that go unhandled. What should we do in this case? Try to be clever in
our own NIB loading code? E.g. provide an array for the top level
objects and free them later on? Most likely this isn't what Cocoa
is doing.
The answer is simple: As Gregory already noted and is clearly stated
in Apple's documentation, the owner of the nib file, i.e., the object
which is loading the nib file, is responsible for releasing the top
level objects. So the good news here is that (in general) it is not
GNUstep's business to release those objects and no special magic is
needed.
Now for the bad news: There is one case where a gui object becomes
the owner of a nib and thus responsible for releasing the top level
objects, namely when NSWindowController is loading a nib file.
NSWindowController already has a _top_level_objects array attribute
that probably is intended to hold the nib's top level objects, but
this attribute at present is unused. In principle, a fresh array
should be created when the nib file is loaded and filled with the
nib's top level objects. Then, one could release those objects when
the window is closed. However, since the window is one of the top
level objects it looks like one must be careful to avoid
overreleasing the window when it is set to release when closed, which
happens to be the case in GNUstep when the window controller has an
associated document.
For the moment I think it is good enough to ignore the issue until it
shows up to be a real problem.
After the first inspection of NSWindowController, it seems to me that
the correct implementation requires some subtle changes to
NSWindowController, so I guess this is better done after the upcoming
release (unless somebody complains strongly about the space leak ...).
Wolfgang
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev