Fred, The NSDrawer change:
* I think that setFrame:display:animate: didn't exist when I originally wrote the code for NSDrawer. The issue is that on Windows systems and on some slower systems the code that was there (in NSDrawer) was very slow and was causing the drawer to open very very slowly. The GSNibLoading change: * As stated in the ChangeLog, this one is temporary until I find all of the places this is crashing. The issue is not in GSNibLoading itself, but is in some of the nib loading code (initWithCoder: methods) of objects being loaded. I believe this to be the case since I have found a few places where objects were not being retained properly (GSMenuItemSeparator, as one example) that were causing crashes. I put this temporary change in place to prevent crashes for people who simply want their apps to work (yes, at the cost of a memory leak) until I can locate all of the places where this is an issue. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer ________________________________ From: Fred Kiefer <fredkie...@gmx.de> To: Gregory Casamento <greg_casame...@yahoo.com>; GNUstep Developer <gnustep-dev@gnu.org> Sent: Wednesday, January 28, 2009 2:43:20 AM Subject: Re: [Gnustep-cvs] r27706 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m 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.
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
