On May 20, 2014, at 8:06 PM, Lee Ann Rucker <lruc...@vmware.com> wrote:

> 
> On May 20, 2014, at 4:45 PM, edward taffel wrote:
> 
>> 
>> On May 20, 2014, at 5:18 PM, Keary Suska <cocoa-...@esoteritech.com> wrote:
>> 
>>> On May 20, 2014, at 9:55 AM, edward taffel wrote:
>>> 
>>>> apologies keary,
>>>> 
>>>> on reread, my question is badly cast: i should have read it the same as 
>>>> you.
>>>> 
>>>> the issue is:
>>>> 
>>>> i have an overlay (created programmatically  w/ NSBorderlessWindowMask) at 
>>>> the top of my document view; after switching to full screen setFrame 
>>>> disregards my requested rect (without log emission) & adjusts to a max 
>>>> below the menu drop-down area. best coding practice suggests (to me) an 
>>>> arithmetical level adjustment like document-window-level plus one, but 
>>>> this does not attain. kCGOverlayWindowLevel does the trick, but 
>>>> kCGStatusWindowLevel is lower on the list & i wondered what class of 
>>>> window is intended at this level.
>>> 
>>> AFAIK, status window level is for windows belonging to NSStatusItems.
>> 
>> go figure—i’ve never fiddled with status bar items: i thought something 
>> completely different. i wish they would note this in the header.
>> 
>>> I am not completely educated on full screen issues, but I imagine since 
>>> changing the window layer changes its behavior, the full screen semantics 
>>> are using the window layer as a hint to handle resizing. Just for grins, 
>>> what happens when you send -toggleFullScreen: to your overlay?
>> 
>> the overlay has no life of its own; it’s managed by the window it’s attached 
>> to—toggleFullScreen is out of its context. &, i’ve just looked up 
>> toggleFullScreen (again): i’ve never seen a method description more in need 
>> of editing.
>> 
>> thanks for your comments keary!
> 
> No, you wouldn't want to toggleFullScreen on it - it would go off into its 
> own space!
> 
> We tweaked window levels for what seemed like good reasons in 10.7 
> fullscreen, and then those tweaks didn't work so well with 10.9 because Apple 
> was using different levels for some UI parts than it had before. At WWDC, 
> Apple advised against it. 
> 
> The setFrame issue might be an Apple bug which we reported but I don't have 
> the rdar handy - it's applying the constraints as if there was a menu there, 
> and there *is*, but it slides down as needed and should not prevent windows 
> going into that area.

i’m glad someone else thinks it’s a bug. i’ve had similar level issues w/ 
overlays in viewing mode (i.e. time machine), which i might broach in a new 
thread.

thanks lee ann!

> 
>> 
>>> 
>>>> On May 20, 2014, at 10:59 AM, edward taffel <etaf...@me.com> wrote:
>>>> 
>>>>> 
>>>>> On May 20, 2014, at 10:41 AM, Keary Suska <cocoa-...@esoteritech.com> 
>>>>> wrote:
>>>>> 
>>>>>> On May 20, 2014, at 8:17 AM, edward taffel wrote:
>>>>>> 
>>>>>>> does anyone know where to find the definition of kCGStatusWindowLevel 
>>>>>>> (NSStatusWindowLevel)?  or alternatively, can anyone define it?
>>>>>> 
>>>>>> NSStatusWindowLevel is declared in NSWindow.h, kCGStatusWindowLevel is 
>>>>>> declared in CGWindowLevel.h. Is it the actual numeric value of the 
>>>>>> constant that you want?
>>>>> 
>>>>> no, the definition of a status window; i.e. what is it used for?
>>>>> 
>>>>>> I would code against it, as it can easily change at any time without 
>>>>>> notice.
>>> 
>>> 
>>> Keary Suska
>>> Esoteritech, Inc.
>>> "Demystifying technology for your home or business"
>>> 
>> 
>> 
>> _______________________________________________
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=uzaDYeANc2BRg2D0CSTBWJLLfFrsEcqavI6QpMfTAws%3D%0A&s=beabc2cdba95b599795fcc2ba8cdffa736d817b915d8eb60b0c96bd0b90df3de
>> 
>> This email sent to lruc...@vmware.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to