Framework: Library/Frameworks/AppKit.framework
Header File Directories: Library/Frameworks/AppKit.framework/Headers
The Application Kit is a framework containing all the objects you need to implement your graphical, event-driven user interface: windows, panels, buttons, menus, scrollers, and text fields. The Application Kit handles all the details for you as it efficiently draws on the screen, communicates with hardware devices and screen buffers, clears areas of the screen before drawing, and clips views. The number of classes in the Application Kit may seem daunting at first. However, most Application Kit classes are support classes that you use indirectly. You also have the choice at which level you use the Application Kit:
To learn more about the Application Kit, review the NSApplication, NSWindow, and NSView class specifications paying close attention to delegate methods. For a deeper understanding of how the Application Kit works, see the specifications for NSResponder and NSRunLoop (NSRunLoop is in the Foundation Framework).
The Application Kit is large; it comprises more than 100 classes and protocols. The classes all descend from the Foundation Framework's NSObject class (see Figure 0-1). The following sections briefly describe some of the topics that the Application Kit addresses through its classes and protocols.
The Application Kit class inheritance
![[image: Art/IntroAppKit.gif]](Art/IntroAppKit.gif)
Every application uses a single instance of NSApplication to control the main event loop, keep track of the application's windows and menus, distribute events to the appropriate objects (that is, itself or one of its windows), setup autorelease pools, and receive notification of application-level events. An NSApplication object has a delegate (an object that you assign) that is notified when the application starts or terminates, is hidden or activated, should open a file selected by the user, and so forth. By setting the NSApplication object's delegate and implementing the delegate methods, you customize the behavior of your application without having to subclass NSApplication.
The NSResponder class defines the responder chain, an ordered list of objects that respond to user events. When the user clicks the mouse or presses a key, an event is generated and passed up the responder chain in search of an object that can "respond" to it. Any object that handles events must inherit from the NSResponder class. The core Application Kit classes, NSApplication, NSWindow, and NSView, inherit from NSResponder.
An NSApplication object maintains a list of NSWindow objects-one for each window belonging to the application-and each NSWindow object maintains a hierarchy of NSView objects. The view hierarchy is used for drawing and handling events within a window. NSWindow objects handle window-level events, distribute other events to its views, and provide a drawing area for its views. An NSWindow object also has a delegate allowing you to customize its behavior.
NSView is an abstract class for all objects displayed in a window. All subclasses implement a drawing method using graphics functions; this is the primary method you override when creating a new NSView.
The NSPanel class is a subclass of NSWindow that you use to display transient, global, or pressing information. For example, you would use an instance of NSPanel, rather than an instance of NSWindow, to display error messages, or to query the user for a response to remarkable or unusual circumstances. The Application Kit implements some common panels for you such as the Save, Open and Print panels, used to save, open, and print documents. Using these panels gives the user a consistent "look and feel" across applications for common operations.
The NSMenu, NSMenuItem, and NSCursor classes define the look and behavior of the menus and cursors that your application displays to the user.
The NSBox, NSScrollView, and NSSplitView classes provide graphic "accessories" to other view objects or collection of views in windows. With the NSBox class, you can group elements in windows and draw a border around the entire group. The NSSplitView class lets you "stack" views vertically or horizontally, apportioning to each view some amount of a common territory; a sliding control bar lets the user redistribute the territory among views. The NSScrollView class, and its helper class, NSClipView, provide a scrolling mechanism as well as the graphic objects that let the user initiate and control a scroll. The NSRulerView class allows you to add a ruler and markers to a scroll view.
The NSControl and NSCell classes, and their subclasses, define a common set of user interface objects such as buttons, sliders, and browsers that the user can manipulate graphically to control some aspect of your application. Just what a particular control affects is up to you: When a control is "touched," it sends an action message to a target object. You typically use Interface Builder to set these targets and actions by control-dragging from the control object to your application or other object. You can also set targets and actions programmatically.
An NSControl object is associated with one or more NSCell objects that implement the details of drawing and handling events. For example, a button comprises both an NSButton object and an NSButtonCell object. The reason for this separation of functionality is primarily to allow NSCell classes to be reused by NSControl classes. For example, NSMatrix and NSTableView can contain multiple NSCell objects of different types.
The NSTableView class displays data in row and column form. NSTableView is ideal, but not limited to, displaying database records, where rows correspond to each record and columns contain record attributes. The user can edit individual cells and rearrange the columns. You control the behavior and content of an NSTableView object by setting its delegate and data source objects.
The NSTextField class implements a simple editable text field, and the NSTextView class provides more comprehensive editing features for larger text bodies.
NSTextView, a subclass of the abstract NSText class, defines the interface to OpenStep's extended text system. (Use only the methods defined by NSText if you are programming strictly according to the OpenStep Specification.) NSTextView supports rich text, attachments (graphics, file, and other), input management and key binding, and marked text attributes. NSTextView works with the font panel and menu, rulers and paragraph styles, the Services facility (for example, the spell-checking service), and the pasteboard. NSTextView also allows customizing through delegation and notifications-you rarely need to subclass NSTextView. You rarely create instances of NSTextView programmatically either since objects on Interface Builder's palettes, such as NSTextField, NSForm and NSScrollView, already contain NSTextView objects.
It is also possible to do more powerful and more creative text manipulation (such as displaying text in a circle) using NSTextStorage, NSLayoutManager, NSTextContainer, and related classes.
The NSFont and NSFontManager classes encapsulate and manage font families, sizes, and variations. The NSFont class defines a single object for each distinct font; for efficiency, these objects, which can be rather large, are shared by all the objects in your application. The NSFontPanel class defines the font-specification panel that's presented to the user.
The classes NSImage and NSImageRep encapsulate graphic data, allowing you to easily and efficiently access images stored in files on the disk and displayed on the screen. NSImageRep subclasses each know how to draw an image from a particular kind of source data. The presentation of an image is greatly influenced by the hardware that it's displayed on. For example, a particular image may look good on a color monitor, but may be too "rich" for monochrome. Through the image classes, you can group representations of the same image, where each representation fits a specific type of display device-the decision of which representation to use can be left to the NSImage class itself.
Color is supported by the classes NSColor, NSColorPanel, NSColorList, NSColorPicker, and NSColorWell. NSColor supports a rich set of color formats and representations including custom ones. The other classes are mostly interface classes: They define and present panels and views that allow the user to select and apply colors. For example, the user can drag colors from the Color panel to any color well. The NSColorPicking protocol lets you extend the standard Color panel.
With very little programming on your part, custom view objects can be dragged and dropped anywhere. Objects become part of this dragging mechanism by conforming to NSDragging... protocols: draggable objects conform to the NSDraggingSource protocol, and destination objects (receivers of a drop) conform to the NSDraggingDestination protocol. The Application Kit hides all the details of tracking the mouse and displaying the dragged image.
The NSPrinter, NSPrintPanel, NSPageLayout, and NSPrintInfo classes work together to provide the means for printing and faxing the information that your application displays in its windows and views. You can also create an EPS representation of an NSView.
Use the NSFileWrapper class to create objects that correspond to files or directories on disk. NSFileWrapper will hold the contents of the file in memory so that it can be displayed, changed, or transmitted to another application. It also provides an icon for dragging the file or representing it as an attachment. Or use the NSFileManager class in the Foundation Framework to access and enumerate file and directory contents. The NSOpenPanel and NSSavePanel classes also provide a convenient and familiar user interface to the file system.
The NSPasteboard class defines the pasteboard, a repository for data that's copied from your application, making this data available to any application that cares to use it. NSPasteboard implements the familiar cut-copy-paste operation. The NSServicesRequest protocol uses the pasteboard to communicate data that's passed between applications by a registered service.
The NSSpellServer class lets you define a spell-checking service and provide it as a service to other applications. To connect your application to a spell-checking service, you use the NSSpellChecker class. The NSIgnoreMisspelledWords and NSChangeSpelling protocols support the spell-checking mechanism.
If an application is to be used in more than one part of the
world, its resources may need to be customized, or "localized,"
for language, country, or cultural region. For example, an application
may need to have separate Japanese, English, French, and German
versions of character strings, icons, nib files, or context help.
Resource files specific to a particular language are grouped together
in a subdirectory of the bundle directory (the directories with
the ".lproj" extension).
Usually you setup localization resource files using Interface Builder.
See the specifications for NSBundleAdditions and NSBundle class
for more information on localization (NSBundle is in the Foundation
Framework).