contentRectForFrameRect bad behaviour ?

[Stéphane Goujet]

Hello,

  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


Explanation :

a) screen frame

  OK for both.

b) screen visible frame

 OK for both.
 GNUstep : WindowMaker icons reduce the width.
 Cocoa : the top menu reduces the height.

c) contentRectForFrameRect

  OK for Cocoa : it decreases the height by the height of the window bar
  WRONG for GNUstep : it does not take into account the window bar.

  [NSWindow contentRectForFrameRect] just calls [GSWindowDecorationView
contentRectForFrameRect]. There [GSWindowDecorationView offsets] is 
called and returns 0.0 for all dimensions.

  Is all this because in Cocoa the window bar is considered part of the 
window and in GNUstep/linux/X it is considered outside of the window, 
just handled by the window manager ?
  If it so, how am I suppose to get the same information that I can get 
in Cocoa ?

-------------------------------------------------------------------------------
Test program :
-------------------------------------------------------------------------------

#include <AppKit/AppKit.h>
#include <stdio.h>

void show_frame_dims(NSRect rect) {
        printf("w=%f, h=%f, x=%f, y=%f\n", rect.size.width, rect.size.height,
                rect.origin.x, rect.origin.y);  
}

int main(int argc, char *argv[])
{
        NSWindow *mainwin;
        NSRect frame;
        unsigned int style_mask;

        NSAutoreleasePool *pool =[[NSAutoreleasePool alloc] init];      

        [NSApplication sharedApplication];

        frame=[[NSScreen mainScreen] frame];
        printf("screen frame              : "); show_frame_dims(frame);

        frame=[[NSScreen mainScreen] visibleFrame];
        printf("screen visible frame      : "); show_frame_dims(frame);

        style_mask=NSClosableWindowMask|NSMiniaturizableWindowMask|
                NSResizableWindowMask|NSTitledWindowMask;

        frame=[NSWindow contentRectForFrameRect:frame styleMask:style_mask];
        printf("contentRectForFrameRect   : "); show_frame_dims(frame);
        
        mainwin=[[NSWindow alloc]
                initWithContentRect:frame
                styleMask:style_mask
                backing:NSBackingStoreBuffered
                defer:NO];
        [mainwin makeKeyAndOrderFront:nil];
        [mainwin setTitle:@"AquaticSonar serial devices"];

        frame=[mainwin frame];
        printf("mainwin frame             : "); show_frame_dims(frame);
        
        frame=[[mainwin contentView] frame];
        printf("mainwin contentView frame : "); show_frame_dims(frame);
        
        [pool release];
        [NSApp run];
        return 0;
}
-------------------------------------------------------------------------------

Goodbye,
          Stéphane Goujet.