The Mac OS X Window Server manages the screen (or screens), the keyboard, and the mouse. Unlike the X Window Server and the NeXTSTEP Display PostScript Window Server, the Mac OS X Window Server is lightweight — it doesn’t actually do the drawing itself. Instead, its primary role is to manage which regions of the screen each application is allowed to use, and to allow the applications to do their own drawing. The main job of the Window Server, then, is to assure that programs draw in their own rectangular piece of real estate on the screen, and to see to it that events destined for one program aren’t accidentally sent to another.
The Window Server frees you from having to worry about interactions between your program and other programs that are running simultaneously. For all intents and purposes, you can design your program as if it is the only one running.
The actual drawing on the Mac OS X screen is done with Quartz. Most Cocoa applications use Quartz to draw to an off-screen buffer that is flushed to the screen when the drawing is finished. This buffer is shared between the application and the Window Server using the Mach virtual memory system, making it very fast.
The Quartz system has native support for Adobe’s Portable Document Format (although Apple’s implementation of PDF doesn’t actually use any of Adobe’s code, for licensing reasons). As a result, Quartz can both display and generate PDF files. Quartz can display text in any font size and at any angle. And because it is easy to translate PDF into the commands used by most modern printers, Quartz assures that what you see on the screen looks pretty much like what gets printed on paper (except that the printer output looks better because of its higher resolution).
Quartz is a device-independent graphics system that handles all aspects of line drawing, typesetting, and image presentation on the computer’s screen. Device-independent means that Quartz hides all differences in resolution from your program: to draw a line; you simply tell Quartz to draw a line. Quartz automatically figures out which pixels on the screen (or dots on the printed page) should be turned on or turned off.
Quartz also handles output attributes such as line width and fill color. If you want to draw a dark gray line, you simply set the color to dark gray and draw the line. If the output device is black-and-white only, Quartz or the PDF driver for your printer will automatically dither or halftone the line as necessary (dithering and halftoning are techniques for showing continuous-tone images on devices that can display only a few shades of color, or black and white only). If your output device can handle gray tones, Quartz or the PDF driver will automatically choose values of gray according to what you’ve selected.
When you’re programming with color, Quartz allows you to specify color using a variety of color models — for example, RGB, CMYK, and HSB — and then, as with black and white, converts the color that you requested to what is appropriate to your display. This makes the color output from Cocoa programs look as good as it possibly can on whatever display you use.
Finally, Quartz can automatically take advantage of any graphics acceleration hardware that is present on your computer.
Recall that Cocoa’s Application Kit (AppKit) is a collection of Objective-C classes that define and create objects for use by applications. Many of these AppKit objects, such as NSWindow, NSMenu, and NSButton, have on-screen representations. In this section, we’ll describe how these objects communicate with the Window Server.
An application’s NSApplication object (recall that every Cocoa application must have precisely one of these) is responsible for communication between the AppKit objects in the application and the Window Server. One of the main functions of the NSApplication object is to receive events from the Window Server and distribute them to the appropriate window (or windows).
NSWindow objects manage an application’s representation of windows on the screen. NSWindow objects work together with the Window Server to handle window-moved, window-exposed, and other window events so that on-screen windows are kept up-to-date.
The AppKit class implementations are stored in a special file called a shared library that is contained within the AppKit bundle. The shared library is automatically linked with your program when your program is run. This means that Apple can make improvements in the Application Kit from release to release, and that those improvements are automatically reflected in your program when it runs on the newer release of the operating system. No recompiling is necessary! Shared libraries also make program images smaller, because the library isn’t loaded into the program until the program is loaded for execution.
You can find out which shared libraries an application depends on by
using the otool command in the Terminal. Enter the
following commands, shown here in bold, to find out which shared
libraries Mac OS X’s Clock.app
application uses:
% cd /Applications/Clock.app/ % otool -L Contents/MacOS/Clock Contents/MacOS/Clock: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 617.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/ Foundation (compatibility version 300.0.0, current version 423.0.0) /System/Library/PrivateFrameworks/HIServices.framework/Versions /A/HIServices (compatibility version 1.0.0, current version 64.0.0) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/ApplicationServices (compatibility version 1.0.0, current version 16.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 55.0.0) %
Note that Clock.app uses the AppKit and
Foundation class libraries, together with three others.