Re: kCGStatusWindowLevel
Re: kCGStatusWindowLevel
- Subject: Re: kCGStatusWindowLevel
- From: edward taffel <email@hidden>
- Date: Tue, 20 May 2014 20:43:25 -0400
On May 20, 2014, at 8:06 PM, Lee Ann Rucker <email@hidden> wrote:
>
> On May 20, 2014, at 4:45 PM, edward taffel wrote:
>
>>
>> On May 20, 2014, at 5:18 PM, Keary Suska <email@hidden> 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 <email@hidden> wrote:
>>>>
>>>>>
>>>>> On May 20, 2014, at 10:41 AM, Keary Suska <email@hidden> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden