gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] r27706 - in /libs/gui/trunk: ChangeLog Source/GSNibLoa


From: Fred Kiefer
Subject: Re: [Gnustep-cvs] r27706 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Date: Wed, 28 Jan 2009 08:43:20 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20081227)

Gregory Casamento wrote:
> Author: gcasa
> Date: Tue Jan 27 21:33:17 2009
> New Revision: 27706
> 
> URL: http://svn.gna.org/viewcvs/gnustep?rev=27706&view=rev
> Log:
> This is a temporary change.   Commenting out RELEASE(_connections) will be 
> reverted ASAP.
> 
> Modified:
>     libs/gui/trunk/ChangeLog
>     libs/gui/trunk/Source/GSNibLoading.m
>     libs/gui/trunk/Source/NSDrawer.m

Could you please explain these two changes?
I am more interested in the one for NIB loading, although the drawer
change also surprised me. The old code there looks strange, why didn't
we use setFrame:display:animate: in the first place. Still it looked
like a working feature...

The other change is more interesting. Did you switch of the memory
management for NIB connections because of the ugly memory problems this
is causing on applications like Bean? We have noticed this during our
session in Bergamo as well. My impression there was that outlets set via
the NIB connection mechanism get deallocated behind the back of the
application. We didn't have the time to investigate this in detail. My
first idea was the perhaps the mechanism we use to set the outlets
doesn't follow the documented memory management rules, but as far as I
can tell this wasn't the case. I think we are using GSObjCFindVariable()
and GSObjCSetVariable() and these should work correctly. Perhaps we
could switch to setValue:forKey: here to have a more general mechanism
in place. But basically this would end up calling the same code, it is
just a bit cleaner and easier to understand.

Anybody out there with an idea, what might go wrong here?
Or perhaps I am looking at the wrong bit of code. It might well be that
the memory leak happens somewhere completely different.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]