Re: Next GNUstep release?

[Fred Kiefer]

Mhm, I already did all of that yesterday...

But there is more to do. We now need to change all the places where we
load NIB (or Gorm or XIB) files to free the top level objects. The code
is a lot cleaner now, but as far as memory leaks are concerned we are
almost back to square one. We now leak all the top level objects again :-(

I will try to solve this later today, but wouldn't mind if anybody beats
me on this before I come back from the cinema.

Fred

Am 29.03.2010 18:49, schrieb Gregory Casamento:
> Wolfgang...
> 
> The patch looks good.   Please go ahead and apply it and make the
> change in GSNibLoading.m as well, if you wish.
> 
> Thanks, GC
> 
> On Sun, Mar 28, 2010 at 4:45 PM, Wolfgang Lux <address@hidden> wrote:
>> Gregory Casamento wrote:
>>
>>> Top level objects in the nib are the responsibility of the controller.
>>>  That is to say that if you load a nib from MyController then any and
>>> all top level objects in that nib should be released by MyController
>>> when it deallocates itself.
>>
>> Indeed. What I tried to point out (but maybe failed to do properly) is that
>> GNUstep does not implement this policy when the controller explicitly asks
>> for the top level objects using the NS(Nib)TopLevelObjects key. If one uses
>> that key, GNUstep passes ownership of the top level objects exclusively to
>> the array that is used to return the objects and when the controller
>> releases the top level objects, the application will crash. In fact, it is
>> even documented in the code that GSNibLoading and GSGormLoading are
>> implemented that way. However, this is incompatible with both Apple's
>> documentation and implementation. Attached below is a patch to fix
>> GSGormLoading. A similar change will be necessary in GSNibLoading.