Re: Replacing views with setContentView

[Fred Kiefer]

Andreas Höschler schrieb:
> 
> in our apps we have to replace views with setContentView:, e.g. in the
> inspector depending on the context. Our code works perfectly on MacOSX
> but failed under GNUstep. I spent 2 days on debugging this in the
> GNUstep sources. I finally figured out that this has to do with
> resizeWithOldSuperviewSize: and probably a no longer valid reference
> size after the replacing the contentView. Finally the following
> modification fixed the problem (last three lines):
> 
> GSWindowDecorationView:
> 
> - (void) setFrame: (NSRect)frameRect
> {
>   NSSize oldSize = _frame.size;
>   NSView *cv = [_window contentView];
> 
>   frameRect = [isa windowFrameRectForFrameRect: frameRect
>                      styleMask: [window styleMask]];
> 
>   _autoresizes_subviews = NO;
>   [super setFrame: frameRect];
> 
>   contentRect = [isa contentRectForWindowFrameRect: frameRect
>                      styleMask: [window styleMask]];
> 
>   // Safety Check.
> //  [cv setAutoresizingMask: NSViewWidthSizable | NSViewHeightSizable];
> //  [cv resizeWithOldSuperviewSize: oldSize];
>   [cv setFrame: contentRect];
> }
> 
> I don't understand what the author intended to do with this safety
> check, but it definitely makes our code fai. I checked 8 applications
> after my modification and all behave well. I therefore recommend to
> apply this patch.

I tried to understand this change, but failed to. I most cases I would
expect the current GNUstep code to be more or less equivalent to your
code. Where would there be any difference?
The safety check is only about resetting the resize attributes of the
content view, which should not be needed and doesn't make any
difference. And for normal views the resizeWithOldSuperviewSize: method
call should be equivalent to the setFrame: call. What I need to
understand is, why this makes a difference in your case, so what is the
resize behaviour of your content view? And what is the problem you
experience?

Fred