How Window Controllers Work
A controller object (in this case, an instance of the
NSWindowController class) manages a window; this object is usually stored in a nib file. This management entails the following:
Loading and displaying the window
Closing the window when appropriate
Customizing the window’s title
Storing the window’s frame (size and location) in the defaults database
Cascading the window in relation to other document windows of the application
A window controller can manage a window by itself or as a participant in AppKit’s document-based architecture, which also includes the
NSDocumentController classes. In this architecture, a window controller is created and managed by a document (an instance of an
NSDocument subclass) and, in turn, keeps a reference to the document. For a discussion of this architecture, see Document-Based App Programming Guide for Mac.
The relationship between a window controller and a nib file is important. Although a window controller can manage a programmatically created window, it usually manages a window in a nib file. The nib file can contain other top-level objects, including other windows, but the window controller’s responsibility is this primary window. The window controller is usually the owner of the nib file, even when it is part of a document-based application.
For simple documents—that is, documents with only one nib file containing a window—you need do little directly with
NSWindowController objects. AppKit creates one for you. However, if the default window controller is not sufficient, you can create a custom subclass of
For documents with multiple windows or panels, your document must create separate instances of
NSWindowController (or of custom subclasses of
NSWindowController), one for each window or panel. An example is a CAD application that has different windows for side, top, and front views of drawn objects. What you do in your
NSDocument subclass determines whether the default
NSWindowController object or separately created and configured
NSWindowController objects are used.
Window Closing Behavior
When a window is closed and it is part of a document-based application, the document removes the window’s window controller from its list of window controllers. This results in the system deallocating the window controller and the window, and possibly the
NSDocument object itself. When a window controller is not part of a document-based application, closing the window does not by default result in the deallocation of the window or window controller. This is the desired behavior for a window controller that manages something like an inspector; you shouldn’t have to load the nib file again and re-create the objects the next time the user requests the inspector.
If you want the closing of a window to make both window and window controller go away when it isn’t part of a document, your subclass of
NSWindowController can observe the
NSWindowWillCloseNotification notification or, as the window delegate, implement the