Re: [Gnustep-cvs] r32163 - /libs/gui/trunk/Source/NSWindow.m

[Fred Kiefer]

Thank you for checking this. I followed your suggestion and just
reverted your change plus removing the content view creation.
Still I think we should rethink this whole are and remove the duplicate
management of the content view. But for now it is save to keep it this way.

Fred

Am 15.02.2011 14:10, schrieb Wolfgang Lux:
>> thank you for this tricky fix. This surely was a hard to track down bug.
> 
> it was certainly easier than you seem to think :-)
> 
>> Now with the fix in place it is a lot easier to think about the problem.
>> The main issue here seems to be that we need to track the content view
>> on two levels, once in the window and again in the decoration view.
>> Would it be possible to simplify this by only storing the content view
>> in the decoration view and getting it from there when needed? There
>> could be an issue with KVC and there might be other problems that I
>> currently don't see. But having code that need that much of
>> documentation to come along with it, is surely a sign for a possible
>> rewrite.
> 
> I share your feeling that something is wrong here. Indeed, my first
> thought when reading the implementation of -setContentView: was that
> this method shouldn't create a fresh content view when called with a nil
> argument. But then I left that code in place because I was too lazy to
> check whether this code is there on purpose and compatible with OS X and
> just decided to write down a clear comment instead (maybe a bit verbose,
> but still shorter than a full bug report :-).
> 
> I thought that this issue didn't deserve more effort, but your mail had
> me have just another look at it. The GNUstep implementation isn't
> compatible with OS X (if you call -setContentView: with a nil argument,
> Cocoa doesn't create a new content view for the receiver), so we could
> equally remove the code that creates the fresh content view. Feel free
> to make this change and revert my fix.