Hi Greg, thank you for pointing out this problem. I think that in this specific case the error lies with Gorm. What happens is that the displayRectIgnoringOpacity: method in GormViewEditor calls the super implementation of displayIfNeededInRectIgnoringOpacity:. This method on NSView now calls displayRectIgnoringOpacity:, which isn't a too strange behaviour, but now Gorm ends up in an infinite loop. It is surprising that the code there has ever worked. This was due to a specific implementation in NSView; I wouldn't be to surprised to see that Gorm wont work on Cocoa.
The solution is obvious. Replace the super call to displayIfNeededInRectIgnoringOpacity: with one to displayRectIgnoringOpacity:. With the new code in NSView in place you wont even need the displayIfNeededInRectIgnoringOpacity: method, as now all display operations go through displayRectIgnoringOpacity:. And I am even wondering if it isn't possible to move all this code into drawRect:, but I might have missed the point here. I also don't understand the idea behind the currently_displaying variable. Is this really needed? Are you going to change the Grom code, or should I do it? I would prefer that you look at the code, as I don't want to break Gorm. Cheers, Fred Gregory John Casamento wrote: > Fred, > > Upon seeing your notification of these changes... I tested with Gorm. The > changes appear to cause Gorm to go into an infinite recursion when trying to > select a control (such as a button) in a window. > > I have entered a bug for this... https://savannah.gnu.org/bugs/?20274. > > I'm not certain if it's Gorm's problem or the new changes in NSView, but we > should look into it. > > Thanks, GJC > > -- > Gregory Casamento > > ----- Original Message ---- > From: Fred Kiefer <[EMAIL PROTECTED]> > To: GNUstep Developer <gnustep-dev@gnu.org> > Sent: Tuesday, June 26, 2007 1:03:30 PM > Subject: Rework of NSView diesplay mechanism > > I just submitted a change that reworks the NSView display mechanism to > us the new method displayRectIgnoringOpacity:inContext:. To me the new > code looks a lot more logical and consistent than the old one, but as > this may only be a private opinion I would like you all to review and > test the new code. > > I tried to document the display mechanism a bit better. That way you > should be able to tell, what I want to achieve with the new code and > point out errors in it. What I also would like to know is if there is > any perceivable difference in performance. I don't expect any, but you > never know. > > Cheers, > Fred _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev