Window Layers and Levels

Window Layers and Levels

Windows can be placed on the screen in three dimensions. Besides horizontal and vertical placement, windows are layered back-to-front within distinct levels. Each application and document window exists in its own layer, so documents from different applications
can be interleaved. Clicking a window to bring it to the front doesn’t disturb the layering order of any other window. A window’s depth in the layers is determined by when the window was last accessed. When a user clicks an inactive document or chooses it
from the Window menu, only that document and any open utility windows should be brought to the front.

Window Levels

Windows are ordered within several distinct levels. Window levels group windows of similar type and purpose so that the more “important” ones (such as alert panels) appear in front of those lesser importance. A window’s level serves as a high-order
bit to determine its position with regard to other windows. Windows can be reordered with respect to each other within a given level; a given window, however, cannot be layered above other windows in a higher level.

There are a number of predefined window levels, specified by constants defined by the

NSWindow

class. The levels you typically use are:

NSNormalWindowLevel

,
which specifies the default level;

NSFloatingWindowLevel

,
which specifies the level for floating palettes; and

NSScreenSaverWindowLevel

,
which specifies the level for a screen saver window. You might also use

NSStatusWindowLevel

for
a status window, or

NSModalPanelWindowLevel

for
a modal panel. If you need to implement your own popup menus you use

NSPopUpMenuWindowLevel

.
The remaining two levels,

NSTornOffMenuWindowLevel

and

NSMainMenuWindowLevel

,
are reserved for system use.

Setting Ordering and Level Programmatically

You can use the

orderWindow:relativeTo:

method
to order a window within its level in front of or in back of another window. You more typically use convenience methods to specify ordering, such as

makeKeyAndOrderFront:

(which
also affects status),

orderFront:

,
and

orderBack:

,
as well as

orderOut:

,
which removes a window from the screen. You use the

isVisible

method
to determine whether a window is on or off the screen. You can also set a window to be removed from the screen automatically when its application isn’t active using

setHidesOnDeactivate:

.

Typically you should have no need to programmatically set the level of a window, since Cocoa automatically determines the appropriate level for a window based on its characteristics. A utility panel, for example, is automatically assigned to

NSFloatingWindowLevel

.
You can nevertheless set a window’s level using the

setLevel:

method;
for example, you can set the level of a standard window to

NSFloatingWindowLevel

if
you want a utility window that looks like a standard window (for example to act as an inspector). This has two disadvantages, however: firstly, it may violate the human interface guidelines; secondly, if you assign a window to a floating level, you must ensure
that you also set it to hide on deactivation of your application or reset its level when your application is hidden. Cocoa automatically takes care of the latter aspect for you if you use default window configurations.

There is currently no level specified to allow you to place a window above a screen saver window. If you need to do this (for example, to show an alert while a screen saver is running), you can set the window’s level to be greater than that of the screen saver,
as shown in the following example.

[aWindow setLevel:NSScreenSaverWindowLevel + 1];

Other than this specific case, you are discouraged from setting windows in custom levels since this may lead to unexpected behavior.