Putting Together an OpenStep Application

This introduction takes a brief look at the components of an OpenStep application. It explains the path that Project Builder and other WorkShop OpenStep tools offer you for going from a set of source files to a working application. It looks at the application development process in terms of resources and tasks that you, the developer, must provide and those that Project Builder and other OpenStep tools provide for you. Subsequent chapters present detailed information for each of the tools introduced here.

The process of developing an application can be divided into three general tasks: designing, coding, and debugging. These tasks are never performed entirely sequentially. You may decide after some coding that you need to change some aspect of design. Debugging always reveals code that needs rewriting, and occasionally exposes design flaws. When you develop an application with OpenStep tools, you can move easily among these tasks.

The following sections enumerate the components of the OpenStep application development process, describing those portions for which you are responsible and those which Project Builder, Interface Builder, and other WorkShop OpenStep development tools handle for you. For more information on Project Builder, see Chapter 2, "Using Project Builder"; for more on Interface Builder, see Chapter 3, "Working with Interface Builder. "

Designing Your Application

Before you write any code, you should spend some time thinking about design. Some components of application design to consider are functionality, program structure, and user interface. You should think about the goals of your application and the techniques you might use to meet those goals. You should determine the unique classes that your application requires and think about how to divide your program into separate modules. You should sketch out user interface ideas, and use Interface Builder to prototype and test those ideas.

Creating a Project

With the basic design determined, you can use Project Builder to start a new project.

In WorkShop OpenStep, a project is physically represented by a directory under the control of Project Builder; all of the components of the project must reside in this directory. When you start a new project, Project Builder automatically generates the project directory and a set of source files common to all applications, including a main file, a nib file, a makefile, and others.

The main file includes the standard main() function required in all C programs. The nib file is used by Interface Builder to archive the application's user interface. The makefile is updated by Project Builder to keep track of all the source files from which your application is built. Another file in the project directory, PB.project, is used by Project Builder itself to keep track of various project components.

Throughout the life of the project, you will add to and update the files in the project directory. WorkShop OpenStep development tools, including Project Builder and Interface Builder, may add to and maintain other files in this directory as your project grows.

Writing Code for Your Application

To establish the unique workings of your application, you create class interface and implementation files that include code for the appropriate methods and instance variables. Interface Builder can help in this process by creating skeletal code for a class if you list the methods in the Inspector panel. If you create the source files first, Interface Builder can parse them to learn about their id instance variables and action methods.

Project Builder lets you add source files to your project at any time. You can create other source files using standard C, Objective C, and C++ code. Project Builder can also know about and manage other files, such as pswrap files containing PostScript^(TM) code within C function wrappers.

Connecting Objects with Interface Builder

In Interface Builder, you can interconnect objects in your application. For example, you can establish the target and action for a control in the interface.

Interface Builder puts information about the classes used by your application in the nib file; included are Application Kit classes and other classes provided by OpenStep, as well as the custom classes you define. The nib file contains all the information required to generate the objects in your application at run

time: specifications for objects, connections between objects, icons, sounds, and other features. An OpenStep application can have one or more nib files for each application you create.

Adding Other Resource Files

Resource files are frequently used to customize the user interface for your application. Project Builder allows you to add icons for both your application and its documents. Interface Builder allows you to add icons and sounds for the buttons in your user interface. You can put other images in your application using Application Kit classes and PostScript code. You can add other sounds using Sound Kit methods. Project Builder provides a drag-and-drop interface for adding sounds, images, and other resource files to your project, including unique icons for your application and its document files.

Choosing Document Extensions for Your Application

If your application reads and writes documents, you will need to take measures to see to it that the Workspace Manager knows about and can work with those files. First, you need to write file management code that saves the documents with a unique extension. You also need to use the Project Builder application's Attributes display to specify document extensions for an application. Project Builder adds these extensions to the appropriate file to assure that your application is invoked by Workspace Manager when the user double-clicks on a file with the specified extensions.

Compiling Your Program

As you add source files to your application, Project Builder lists them in the project Makefile. When you use its Build command, Project Builder starts the make utility, which in turn reads the project Makefile and generates the executable file from the sources. As the make utility runs, it issues system commands to compile and link your application's source files into an executable file. The project Makefile, generated by Project Builder, provides the information the make utility needs to do this job. The warnings generated by the compiler and link editor provide information to help you locate and fix bugs detected at compile time.

In building your project, the make utility keeps track of source updates. Each time you run the make utility, only the source files that have been updated since the last make are regenerated; the rest are used as is. This minimizes the time required to generate your executable file.

Once you start building your application, Project Builder provides an interactive interface to Edit for locating source code problems detected by the compiler and link editor. Anytime the compiler encounters an error, Edit can locate the code with a single click--you can then edit out the problem and begin compiling again.

Debugging Your Program

After you successfully compile your program, you are ready to try running it. The easiest way to do so is by choosing Debug in the Project Builder application's Builder display. This selection builds your application (if necessary), then starts the distributed Debugger. The Debugger is described in detail in the SPARCWorks manual Debugging a Program.

Adding Help to Your Application

Using Project Builder, Interface Builder, and Edit, you can create context-sensitive help for your application. The standard help template provided by Interface Builder includes general information on the OpenStep environment. You can add to this template to include application-specific help, and you can create links between the controls in your application and the help system to provide the user with context-specific assistance.

Translate Your User Interface

When the application is complete and help is available, you can create alternate versions with translated text for windows, panels, menu items, and buttons, as well as any help information you have added. The OpenStep application programming interface (API) provides ways of accessing bundles in your application containing the text and user interface in various languages you want to support. Chapter 2, "Using Project Builder," provides information on how to make a project localizable.

Making Your Application Available to Users

Once an application is debugged, you can install it in an application directory using Project Builder. Project Builder lets you determine which directory to install the application in and provides a way to automatically install the application when you build it.

When the user double-clicks on a document file, the Workspace Manager has to locate and start the executable file for that application. Workspace Manager looks for the executable file in a systematic sequence of directory paths. This search sequence is contained in an environmental variable path. You can place an application in any of the directories specified in path.

Because of the search sequence specified by path, you can replace an application located later in the sequence with one of the same name earlier in the sequence. For example, $(HOME)/Apps occurs before /usr/openstep/Apps in path; if you place an application in the directory $(HOME)/Apps with the same name as an application in the /usr/openstep/Apps directory, the Workspace Manager finds and starts the version in $(HOME)/Apps (the Apps subdirectory in your home directory). You should consider the path when naming and installing applications.