Re: contentRectForFrameRect bad behaviour ?

[Fred Kiefer]

Hi Stephane,

Stéphane Goujet wrote:
>   I experience a very different behaviour of [NSWindow 
> contentRectForFrameRect] between Cocoa and GNUstep/linux :
>
>   Basically, GNUstep does not take into account the window decorations.
> Here are the results of a small test program that you can find at the 
> bottom of this message.
>
> ------------------------------------------------------------------------------- 
>
> GNUstep results :
> ------------------------------------------------------------------------------- 
>
> screen frame              : w=1024.000000, h=768.000000, x=0.000000, 
> y=0.000000
> screen visible frame      : w=960.000000, h=768.000000, x=0.000000, 
> y=0.000000
> contentRectForFrameRect   : w=960.000000, h=768.000000, x=0.000000, 
> y=0.000000
> mainwin frame             : w=960.000000, h=768.000000, x=0.000000, 
> y=0.000000
> mainwin contentView frame : w=960.000000, h=768.000000, x=0.000000, 
> y=0.000000
>
> ------------------------------------------------------------------------------- 
>
> Cocoa results :
> ------------------------------------------------------------------------------- 
>
> screen frame              : w=1024.000000, h=768.000000, x=0.000000, 
> y=0.000000
> screen visible frame      : w=1024.000000, h=742.000000, x=0.000000, 
> y=4.000000
> contentRectForFrameRect   : w=1024.000000, h=720.000000, x=0.000000, 
> y=4.000000
> mainwin frame             : w=1024.000000, h=742.000000, x=0.000000, 
> y=4.000000
> mainwin contentView frame : w=1024.000000, h=720.000000, x=0.000000, 
> y=0.000000

I was hoping that Alexander Malmberg would pick up to answer this 
question, he surely would have done a better job than me, still I'll try.

The current behaviour of GNUstep is strange, but it is expected. Not to 
say it is correct. The back ground here is, that we have been trying 
hard to implement into our X backend code to track reparenting and 
decoration by the window manager. As we also have the need to provide 
window decoration for systems without window managers. About a year ago 
Alexander wrote the new classes GSWindowDecorationView, 
GSBackendWindowDecorationView and GSStandardWindowDecorationView. The 
later gets used when GNUstep is in charge of handling the window 
decoration itself. In your case most likely 
GSBackendWindowDecorationView will be used. Now none of this should 
normaly affect the content rect to frame rect transformation you may 
argue. But it does, as the meaning of frame rect was changed. (Here it 
would be great to cite from Alexanders mail, but I cannot find it at the 
moment) We now have frame rect and screen frame rect, which are the same 
for GSStandardWindowDecorationView, but different for 
GSBackendWindowDecorationView. And for content rect and frame rect the 
opposite is true. There are extension methods to get the screen rect for 
a frame rect, and vice versa. (Alexander, didn't you at that time 
promise to flag them as such?)

So the short answer to all this is that the current GNUstep code intents 
to be different. I would be glad if we could get away from this again, 
as it does not help in writing portable code. But there were some good 
reasons to deviate.

Hope this helps and perhaps now Alexander steps in and fills in the gaps 
I left in explaining things.

Fred