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

[Quentin Mathé]

Le 15 août 06 à 19:20, Richard Frith-Macdonald a écrit :

> 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.

I agree on this point.

> 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

True on GNUstep also.

> The frameRect should be the rectangle that the window occupies on  
> the screen ... as in OpenStep/MacOS-X

It's not always the case with GNUstep, it can be the contentRect.

> 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.

screenRect is always the frameRect at this time.

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

It doesn't.
However what you propose seems better than the current terminology. I  
still think we can find a better term than screenRect. May be  
backendRect?

Quentin.

--
Quentin Mathé
qmathe@club-internet.fr