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