Re: [bug #17377] Various frame related methods in NSWindow return wrong results

[Richard Frith-Macdonald]

On 11 Aug 2006, at 13:37, Fred Kiefer wrote:

> Follow-up Comment #5, bug #17377 (project gnustep):
>
> The code we have there in the different decorators is there on  
> purpose. When
> Alexander Malmberg implemented the window decoration handling  
> inside of
> GNUstep gui he wanted to end up with things right the way they are  
> now.
> I remember there was documentation for all of this, but I cannot  
> find it at
> the momenet. The main thing was that Alex came up with three  
> rectangles where
> OpenStep only has two, contentRect and frameRect. The third one being
> screenRect, which is the actual space on the screen occupied by the  
> window.
> Including the window decoration, from what ever source it is  
> coming. For the
> different decorators two of these three rectangles are identical, but
> different ones for the different decorators.
> I would think that you should get the values you are aiming for by  
> using the
> screenRect methods instead of the frameRect methods. But this would  
> make your
> code incompatible to code for Cocoa or OpenStep.
> As far as I can tell this screenRect code does not get used  
> anywhere. Perhaps
> it would be better to reconsider the whole interface.

As far as I can tell without going into great detail, Alexander's  
basic idea seems entirely reasonable.

The contentRect should be the rectangle of the window's content view  
(ie where the user is allowed to draw) ... as in OpenStep/MacOS-X
The frameRect should be the rectangle that the window occupies on the  
screen ... as in OpenStep/MacOS-X
The screenRect should be the rectangle of the decoration view ...  
either the same as frameRect if the gui is drawing decorations, or  
the same as contentRect if the backend windowing system is doing it.

What I'm not sure is whether the code actually does it that way.