I'm apparently missing something,... I get an error trying to compile that.
Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer ----- Original Message ---- From: Fred Kiefer <[EMAIL PROTECTED]> To: Gregory John Casamento <[EMAIL PROTECTED]> Cc: GNUstep Developer <gnustep-dev@gnu.org> Sent: Tuesday, May 20, 2008 4:34:53 AM Subject: Re: NSWindow & NSGraphicsContext issue Strange, I get the log message as soon as I open an image from the ToyViewer open menu entry. The ToyViewer version I am using is this one: http://www.sonappart.net/TV.tar.bz2 Hope this helps Fred Gregory John Casamento wrote: > I've tried to recreate this issue. I am not seeing the NSLog that was added > come up once during my tests either when running the application (ToyViewer) > or any other apps. > > I'm continuuing to look into it. I'm going to open a bug on this so that > the progress can be tracked there. > > GC > > Gregory Casamento -- Principal Consultant - OLC, Inc > # GNUstep Chief Maintainer > > > ----- Original Message ---- > From: Gregory John Casamento <[EMAIL PROTECTED]> > To: Fred Kiefer <[EMAIL PROTECTED]>; GNUstep Developer <gnustep-dev@gnu.org> > Sent: Monday, May 19, 2008 4:34:49 PM > Subject: Re: NSWindow & NSGraphicsContext issue > > Fred, > > I will take a look at this as soon as possible. The solution should allow > existing gorm files to be handled properly as well as correct the problem > going forward. > > GJC > > Gregory Casamento -- Principal Consultant - OLC, Inc > # GNUstep Chief Maintainer > > > ----- Original Message ---- > From: Fred Kiefer <[EMAIL PROTECTED]> > To: GNUstep Developer <gnustep-dev@gnu.org> > Sent: Sunday, May 18, 2008 7:26:06 PM > Subject: Re: NSWindow & NSGraphicsContext issue > > I was able to resolve most of the problems I listed below by not using > autorelease objects. > > There still is one issue and it is an important one. When creating an > NSWindow from a Gorm file the initialization is called twice. This will > result in two backend objects being created for the window and one of > them would leak and the window map would stay in an inconsistent state, > after the window is freed. I was able to hack around this, by adding a > check for an already existing _windowNum into > initWithContentRect:styleMask:backing:defer:screen:. This only prevents > part of the problem and a real fix would be not to have an NSWindow (or > a subclass) in a Gorm file at all. For NIB files we already us > NSWindowTemplate instead of GSWindowTemplate and this prevents the problem. > Could somebody with a deeper understanding of Gorm please look into this > issue? > > Fred > > Fred Kiefer wrote: >> Last week I tried to resolve a circular refernce problem between >> NSWindow and NSGraphicsContext. >> >> The source of the problem is that when an NSWindow gets displayed it >> generates an NSGraphicsContext (or rather a subclass) which will then >> manage all the actual drawing. The window retain the context and the >> context has an info dictionary which includes the window. That way we >> already start off with a circular reference. To break this I released >> the window once, to adjust the retain count. Now when the window gets >> deallocated I first do a retain on it and then release the graphics >> context which will in turn result in a release on the window. Or so I >> hoped. There were a few issues with my original code. The graphics >> context and the dictionary where autorelease objects, so I had to >> postpone the deallocation of the window by returning from dealloc and >> let it be called again. This also needed a bit of isa sizzling as >> subclasses will not be aware of that reference counting trick and wont >> be prepared to get dealloc called twice. (And the code in NSWindow >> dealloc needed to be reentrant as well) >> >> With that all resolved I expected my code now to work correctly, but >> this still isn't the case. As it turns out, calling retain on an object >> that already was about to get released wont have the expected result. >> When a release is send to an object with a retain count of 1, that count >> wont be changed! Now this means that I have to differentiate between >> calls to _termianteWindow that come from dealloc, where I don't call the >> retain and calls for oneShot windows, where I need to increase the >> retain count before freeing the context. >> >> All of this now looks like an even bigger mess then the one I started >> with and now any help on how to clearly solve this would be welcome. >> >> Cheers, >> Fred >> >> PS: Some of the code I talk about above is still not committed. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev