bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Frith-Macdonald
Subject: Re: [bug #17377] Various frame related methods in NSWindow return wrong results
Date: Tue, 15 Aug 2006 18:20:37 +0100


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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]