Hi Fred,
Hi Wolfgang,
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.
Wolfgang
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev