Re: contentRectForFrameRect bad behaviour ?

[Alexander Malmberg]

Fred Kiefer wrote:
> 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.

Sorry about that; I have a large mail backlog currently, hence the late 
replies...

> (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, 

Well, I added comments about this to NSWindow.h when I did this, so that 
might be what you're thinking of. I also think there's more information 
in the mailing lists archives, though.

> 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?)

Either way, they should be flagged, so I'll do it now.

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

(Using the terminology from NSWindow.h.) The problem is that in 
OPENSTEP, the "frame" of the window is _both_ the screen frame and the 
window frame. This was possible then (and is now in Cocoa, I presume) 
because the decorations were managed by the app (and were thus "inside" 
the backend window).

However, in GNUstep we have chosen to support decorations that aren't 
managed by the app. These decorations are "outside" our backend window, 
and this means that the screen frame and the window frame are no longer 
the same. Thus, there's no way we can have a single "frame" that is both 
the window frame and the screen frame.


In short, the original OPENSTEP interface didn't take external 
decorations into account, so in order to support them we are forced to 
extend it in a slightly incompatible way.

- Alexander Malmberg