Screen frames and fullscreen windows

[Christiaan Hofman]

That's definitely not the problem, as the fullscreen window is  
created long after the nib has been loaded. Moreover the offset is  
far bigger (and the opposite direction) than cascading would do.

But I think I have figured out the problem, though I cannot test it  
at the moment without a secondary screen. The screen of the window  
seems to be assigned delayed, only when it is actually displayed.  
Therefore, I may do my calculations using a stale screen variable.  
(documentation would have been helpful).

Christiaan


On 18 Aug 2007, at 6:53 PM, Todd Ransom wrote:

> Have you checked - (BOOL)shouldCascadeWindows in the window  
> controller?
>
> Todd Ransom
> Return Self Software
> http://returnself.com
>
>
>
> On Aug 16, 2007, at 9:57 AM, Christiaan Hofman wrote:
>
>> I am struggling at the moment with properly placing fullscreen  
>> windows on arbitrary screens. In particular when the fullscreen  
>> window is not on the primary screen, the fullscreen window  
>> sometimes gets offset, and I've no idea what causes this. I use  
>> [screen frame] for the frame of the fullscreen window and place  
>> some secondary windows relative to this frame. But they sometimes  
>> seem to get offset relative to the primary screen.
>>
>> First of all, I need to understand the coordinates that are used  
>> for windows and screens. Unfortunately the docs are vague and  
>> inconsistent on this point, so I'm not sure if my interpretation  
>> is correct. They mention in several place "screen coordinates".  
>> E.g. window frames and content frames and screen frames are  
>> relative to this. My main question is : what are screen  
>> coordinates (as this is not defined anywhere in the docs).
>>
>> I can think of two distinct interpretations:
>>
>> 1. relative to the lower right corner of the primary screen
>> 2. relative to the lower right corner of the current screen (the  
>> one that is referred to).
>>
>> I've made 1 my working hypothesis. But it is inconsistent with  
>> what the docs say about the window's contentRect (which implies 2  
>> should be correct). However 2 seems utterly useless to me as you  
>> would not be able to refer to the frame of any screen in an  
>> unambiguous manner (it always has origin NSZeroPoint relative to  
>> itself) and would make it impossible to move windows to another  
>> screen.
>>
>> And how are different resolutions oif the different screens taken  
>> into account in the screen coordinates? I've no idea, frankly.
>>
>> It would be helpful is someone could enlighten me a bit.
>>
>> Thanks,
>>
>> Christiaan
>>
>> _______________________________________________
>> MacOSX-dev mailing list
>> MacOSX-dev at omnigroup.com
>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>