Re: Next GNUstep release?

[Wolfgang Lux]

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