Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Matching Cocoa Window Levels in Carbon

Hi Nick,
I don't have a lot of information to add to this thread and agree with
Eric that modifying window levels in Carbon could cause compatibility
problems in the future, but I wanted to clarify a couple points.

First, Cocoa does use window levels for its layering model, and Carbon
does not. We are considering unifying this, but need to consider the
implications. In Cocoa, modal windows are at kCGModalPanelWindowLevel
when the application is active, and get moved down to
kCGNormalWindowLevel when the application is inactive. Most other
windows for which Cocoa automatically assigns non-0 levels are
hide-on-deactivate, so they do not end up floating in front of other
applications when the owning app is inactive.

Secondly, please note that if you do use the window levels defined in
CGWindow.h, you should not use the keys as window levels - you should
pass kCGModalPanelWindowLevel rather than kCGModalPanelWindowLevelKey
to SetWindowGroupLevel

Thanks,
Kristin

>> I'm trying to integrate some Cocoa windows into my Carbon
>> application. I find that there is some kind of window level mismatch
>> between floating windows in the two environments. For example by
>> default, floating Cocoa windows appear above modal Carbon windows.
>> I've been playing with the window level features of window groups but
>> all window levels appear to be zero. For example, if I call
>> DebugPrintAllWindowGroups() I get the following:
>>
>> Window group tree
>> ----------------------------------------------------------------------
>> - --------
>> 1 level 0 group 0x7610C03F "com.apple.hitoolbox.windowgroups.root"
>> 2 level 0 group 0x7610C60F "com.apple.HIToolbox.windowgroups.floating"
>> 3 level 0 group 0x72C345BF "com.apple.HIToolbox.windowgroups.document"
>
> That's correct; Carbon uses window level 0 for all of its window
> classes except kUtilityWindowClass. Cocoa uses non-zero window levels
> for floating and modal windows, I believe (while the application is
> active; windows with non-zero window levels are moved to window level
> zero when the app is deactivated).
>
>
>> I could set the window levels of the standard window groups during
>> initialization and set the level of Cocoa windows as I create them.
>> For example:
>>
>> SetWindowGroupLevel(GetWindowGroupOfClass(kDocumentWindowClass),
>> kCGNormalWindowLevel);
>> SetWindowGroupLevel(GetWindowGroupOfClass(kFloatingWindowClass),
>> kCGFloatingWindowLevel);
>> SetWindowGroupLevel(GetWindowGroupOfClass(kModalWindowClass),
>> kCGModalPanelWindowLevelKey);
>>
>> and
>>
>>
>> [myWindow setLevel:NSNormalWindowLevel];
>> [myWindow setLevel:NSFloatingWindowLevel];
>>
>> Is this a reasonable thing to do or will this bite me somewhere down
>> the road?
>
> It's hard for me to entirely predict how this will interact with
> future versions of the toolbox, since we haven't gotten there yet. We
> have considered making Carbon use non-zero window levels for floating
> and modal windows; we may still do that in the future.
>
> Is there a specific problem that you're trying to solve by doing this?
>
>
> -eric
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.