ADC Home > Reference Library > Guides > Darwin > Porting > Porting UNIX/Linux Applications to Mac OS X >

< Previous PageNext Page > Hide TOC

Using Mac OS X Native Application Environments

Mac OS X includes three high-level native development environments that you can use for your application’s graphical user interface: Carbon, Cocoa, and Java. These environments are full-featured development environments in their own right, and you can write complete applications in any one of these environments.

In addition to these technologies, you can also use OpenGL, X11, Qt, Tcl/Tk, wxWidgets, and a number of other traditional UNIX graphics technologies when writing applications for Mac OS X. In each case, there are tradeoffs. This chapter explains these tradeoffs and shows how they affect you as a programmer as well as your users.

In this section:

Choosing a Native Application Environment
Lower-Level Graphics Technologies


Choosing a Native Application Environment

In the context of this document, Carbon, Cocoa, and Java are presented as a way to write a GUI wrapper for a UNIX-based tool.

Writing to these environments lets you build an application that is indistinguishable from any other native Mac OS X application. The Java or Cocoa frameworks are probably the environments that you will use in bringing UNIX applications to Mac OS X, although the Carbon frameworks are used by some developers. The following sections outline all three.

A good general rule is that if you decide to port your application from X11 to a native GUI environment, Carbon is a good choice for C and other procedural X11 applications, while Cocoa is a good choice if your application uses high-level toolkits such as Tcl/Tk or Qt. Cocoa is also a good choice for wrapping command-line applications with a GUI.


Figure 4-1  High-level graphics technologies

High-level graphics technologies

If you decide to port your cross-platform application to a native Mac OS X GUI environment, you should carefully consider how best to do this port in a way that is maintainable. For some helpful tips, you should also read “(Re)designing for Portability.”

Cocoa

Cocoa is an object-oriented framework that incorporates many of Mac OS X’s greatest strengths. Based on the highly-respected OpenStep frameworks, it allows for rapid development and deployment with both its object-oriented design and integration with the Mac OS X development tools. Cocoa is divided into two major parts: Foundation and the Application Kit. Foundation provides the fundamental classes that define data types and collections; it also provides classes to access basic system information like dates and communication ports. The Application Kit builds on that by giving you the classes you need to implement graphical event-driven user interfaces.

Cocoa also provides file system abstraction that makes things such as file browsers look like Mac users expect. If you are developing a commercial application, you should use these. If you are developing an in-house application that will largely be used by people familiar with UNIX, the layout may be confusing, so these APIs may not be appropriate. See “Presenting File Open and Save Dialog Boxes” for more information.

The native language for Cocoa is Objective-C, which provides object-oriented extensions to standard C and Objective-C++. The Objective-C 2.0 Programming Language describes the grammar of Objective-C and presents the concepts behind it. Objective-C is supported in gcc 2.95 and 3. Most of the Cocoa API is also accessible through Java. Cocoa is also the basis for AppleScript Studio, an application environment for script-based GUI development.

Additional Cocoa information, including sample code, can be found at http://developer.apple.com/cocoa. Cocoa documentation including tutorials is available at http://developer.apple.com/documentation/Cocoa/Cocoa.html.

Benefits of Cocoa Development

Drawbacks of Cocoa Development

Example: Calling C or C++ Code With Cocoa

When designing an application from the ground up in Cocoa, you are in an object-oriented environment. You can also take advantage of Cocoa’s object-oriented nature when converting preexisting code, as you can use the Cocoa frameworks to wrap the functionality of C or C++ code.

The Objective-C language has been extended to understand C++. Often this is called Objective-C++, but the functionality remains basically the same. Because Cocoa understands Objective-C++, you can call native C and C++ code from Cocoa. This is one example of how you can take advantage of your code base while adding a Macintosh front end. An example is provided below of how Objective-C wraps together C, C++, and Objective-C++ functionality. Listing 4-1 shows the Objective-C main class.

Listing 4-1  main.m

#import <AppKit/AppKit.h>
 
int main(int argc, const char *argv[]) {
    return NSApplicationMain(argc, argv);
}

This gets everything started when the user double-clicks the application icon. A call is then sent to invoke a HelloController object by the NIB, a file that holds interface information. The listings for HelloController.m and HelloController.h follow.

Listing 4-2  HelloController.m

#import "HelloController.h"
 
@implementation HelloController
 
- (void)doAbout:(id)sender
{
    NSRunAlertPanel(@"About",@"Welcome to Hello World!",@"OK",NULL,NULL);
}
 
- (IBAction)switchMessage:(id)sender
{
        int which=[sender selectedRow]+1;
        [helloButton setAction:NSSelectorFromString([NSString stringWithFormat:@"%@%d:",@"message",which])];
}
 
- (void)awakeFromNib
{
    [[helloButton window] makeKeyAndOrderFront:self];
}
 
@end

Listing 4-3  HelloController.h

#import <AppKit/AppKit.h>
 
@interface HelloController : NSObject
{
    id helloButton;
    id messageRadio;
}
- (void)doAbout:(id)sender;
- (void)switchMessage:(id)sender;
@end

The communication between the C, C++, and the Objective-C code is handled as shown in Listing 4-4. The header file SayHello.h is shown in Listing 4-5.

Listing 4-4  SayHello.mm

#import "SayHello.h"
#include "FooClass.h"
#include <Carbon/Carbon.h>
 
@implementation SayHello
 
- (void)message1:(id)sender
{
    NSRunAlertPanel(@"Regular Obj-C from Obj-C",@"Hello, World! This is a regular old NSRunAlertPanel call in Cocoa!",@"OK",NULL,NULL);
}
 
- (void)message2:(id)sender
{
    int howMany;
    NSString *theAnswer;
    Foo* myCPlusPlusObj;
    myCPlusPlusObj=new Foo();
    howMany=myCPlusPlusObj->getVariable();
    delete myCPlusPlusObj;
    theAnswer=[NSString stringWithFormat:@"Hello, World! When our C++ object is queried, it tells us that the number is %i!",howMany];
    NSRunAlertPanel(@"C++ from Obj-C",theAnswer,@"OK",NULL,NULL);
}
 
- (void)message3:(id)sender
{
    Alert(128,NULL); //This calls into Carbon
}
 
@end

Listing 4-5  SayHello.h

#import <AppKit/AppKit.h>
 
@interface SayHello : NSObject
{
}
 
- (void)message1:(id)sender;
- (void)message2:(id)sender;
- (void)message3:(id)sender;
@end

The C++ class wrapped by these Cocoa calls is shown in Listing 4-6. The header file, FooClass.h, is shown in Listing 4-7.

Listing 4-6  FooClass.cpp

#include "FooClass.h"
Foo::Foo()
{
 variable=3;
}
 
int Foo::getVariable()
{
 return variable;
}

Listing 4-7  FooClass.h

class Foo {
public:
    Foo();
    int getVariable();
    void * objCObject;
private:
    int variable;
};

You should be careful when writing code using Cocoa, because the same constructs that make it easy for the developer tend to degrade performance when overused. In particular, heavy use of message passing can result in a sluggish application.

The ideal use of Cocoa is as a thin layer on top of an existing application. Such a design gives you not only good performance and ease of GUI design, but also minimizes the amount of divergence between your UNIX code base and your Mac OS X code base.

Java

Mac OS X includes a complete implementation of Java 2 Platform Standard Edition with both the 1.4.x JDK and 1.4.x SDK. Pure Java development in Mac OS works just as it would on other platforms. More information on Java development in Mac OS X can be found online at http://developer.apple.com/java.

Benefits of Java Development

Drawbacks of Java Development

Carbon

Carbon is an environment designed to bring existing Mac OS applications to Mac OS X. It can be used to bring an X11 application to a native Mac OS X environment, since the basic drawing primitives are at a similar level of abstraction.

Carbon also offers relatively straightforward file I/O with a few enhancements that are unavailable through POSIX APIs, such as aliases (which behave like a cross between a symbolic link and a hard link). Carbon presents the file system differently to the user than UNIX applications do. This is the layout that Mac users are used to seeing, and thus you should use it if possible when developing a commercial application for broad-scale deployment.

However, if your users are predominantly UNIX users (for example, if you are an in-house developer in a corporate environment), the use of the Carbon file API may not be appropriate, since volumes appear as they do in the Finder, rather than being organized according to the file system hierarchy.

Benefits of Carbon Development

Drawbacks of Carbon Development

In case you’re wondering, that isn’t a typo. Procedural design in a GUI can be both a benefit and a drawback.

Procedural design can be a benefit in terms of being able to easily integrate into any environment, regardless of language. It is also a benefit because it fits many styles of graphical programming well.

Procedural design can be a drawback, however, when dealing with more complex GUI designs where it would be more convenient to have the methods more closely tied to the data on which they operate.

Lower-Level Graphics Technologies

With some code it is simple to abstract the display code from the underlying computational engine, but often this isn’t the case. Especially for graphics-intensive applications, you may want to take advantage of directly calling the core graphic functionality of your targeted operating system. You still need to wrap this functionality in a higher-level API to display it to the screen and allow user interaction, but for times where you need to push pixels in very specific ways, Mac OS X offers you access to three first-class graphics technologies: Quartz, OpenGL, and QuickTime.


Figure 4-2  Low-level graphics technologies

Low-level graphics technologies

Quartz

Quartz is the graphical system that forms the foundation of the imaging model for Mac OS X. Quartz gives you a standards-based drawing model and output format. Quartz provides both a two-dimensional drawing engine and the Mac OS X windowing environment. Its drawing engine leverages the Portable Document Format (PDF) drawing model to provide professional-strength drawing. The windowing services provide low-level functionality such as window buffering and event handling as well as translucency. Quartz is covered in more detail in Mac OS X Technology Overview and in Apple’s Quartz website (http://developer.apple.com/quartz/).

Benefits of using Quartz

Drawbacks to using Quartz

OpenGL

OpenGL is an industry-standard 2D and 3D graphics technology. It provides functionality for rendering, texture mapping, special effects, and other visualization functions. It is a fundamental part of Mac OS X and is implemented on many other platforms.

Given its integration into many modern graphics chipsets and video cards, it is of special interest for programs that require intricate graphic manipulation. OpenGL’s homepage gives more information on the technology in general at http://www.opengl.org.

Apple’s OpenGL page, at http://developer.apple.com/opengl/, gives more information on how it is integrated into Mac OS X and explains the enhancements that the Mac OS X OpenGL implementation provides.

Benefits of using OpenGL

Drawbacks to using OpenGL

QuickTime

QuickTime is a powerful multimedia technology for manipulating, enhancing, storing, and delivering graphics, video, and sound. It is a cross-platform technology that provides delivery on Mac OS as well as Windows. More information on the technology can be found at http://developer.apple.com/quicktime/.

Benefits of using QuickTime

Drawbacks to using QuickTime

Note that while QuickTime itself is not supported on UNIX-based systems, the QuickTime file format is supported by various third-party utilities.



< Previous PageNext Page > Hide TOC

© 2002, 2008 Apple Inc. All Rights Reserved. (Last updated: 2008-04-08)

Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.