How Menus Work

This section describes the basic appearance and behavior of OpenStep menus, which are built into the Application Kit. It covers the main menu, submenus, menu commands and keyboard alternatives. It also describes the user actions that operate menus.

The Application Kit supplies the basic menu functions covered in this section. In particular it supplies:

• The ability to respond to menu commands. (The chosen command is highlighted, and the action you define for the command, such as opening a submenu or a panel is performed.)

• Abilities of menus to open, close, hide, and return; of the main menu to change when the user changes the active application; of submenus to be torn off, and so on.
• Ability of a menu command to open a submenu.
• Ability of commands to handle keyboard alternatives.

Menus you create when you work in Interface Builder have these abilities. To add an application-specific command to a menu, for example, you drag a menu command from the Palettes window to the menu. You can then name the command, give it a keyboard alternative if necessary, and associate it with an action. Figure 6-1 shows typical menus.

Figure 6-1

Basic Menu Functions

The main purpose of a menu system is to display commands from which users can choose. To make this a relatively simple process for the developer and ensure easy use, the OpenStep interface implemented the following guidelines for overall menu functions in the App Kit:

• Menus are arranged hierarchically. A command can open a submenu that has its own commands.
• Menus are assigned to the third and fourth levels, which keeps them floating above everything else on the screen except spring-loaded windows (such as pop-up lists) and attention panels.
• Only menus for the active application are displayed. When the user moves to another application and activates it, current menus disappear and menus for the newly activated application take their places. The App Kit remembers which menus the user has opened and displays them whenever the application is reactivated. For more information, see "Window Order" and "Miniaturizing" and "The Active Application" in Chapter 4.
• Menus cannot be miniaturized. They do not need to be, since they are small (do not cover much of the screen) and are easily reopened after they have been closed.

The basic user operation is choosing a menu command with the mouse. Simply clicking on a command will choose it; users can also drag the pointer through the content area of a menu and release the mouse button when the pointer is over the desired command. (Dragging will highlight each command that the pointer passes over; a command is chosen when the button is released.)

The rest of this section covers these points in more detail.

Main Menu

Every OpenStep application has a main menu, which is displayed on the screen when the application is active. It contains standard commands used in every application and application-specific commands that you supply.

---

Programmer's Note - Project Builder creates a main menu with some standard commands for your application. You can add commands and submenus in Interface Builder. Note that some of the standard commands available in Interface Builder have actions or submenus already associated with them. If you add the Windows command to your main menu, you get the Windows submenu.

---

In the smallest applications, the main menu may be the only menu. Most applications need more than one menu to hold all of their commands. In OpenStep, this is handled by submenus--commands on the main menu identify general functional areas, and when chosen they open submenus with more specific commands. The hierarchical relationships between the main menu and its submenus give users access to all of the application's menus through the main menu.

The default location for main menu is the upper-left corner of the screen. Users can change the default location by dragging it to a new location. They can also change the main menu's location for all of their applications (except those whose main menus have already been moved) with the Preferences application.

The main menu does not have a close button; it is displayed whenever the application is active. When the user activates another application its main menu replaces the original main menu. When the user reactivates the original application, its main menu reappears.

Bringing the Main Menu to the Pointer

When the user presses the mouse button that is mappped to the MENU function, OpenStep opens a copy of the main menu at the pointer location. See Figure 6-2. Notice that the pointer must be over a window that belongs to the active application, rather than the screen background or an inactive window.

As long as the mouse button is down, the user can drag into this copy of the main menu, open its submenus, and choose one of the available commands. When the mouse button is released, this copy of the main menu and any submenus the user opened will disappear. Submenus that may have been opened from the permanent copy of the main menu are not affected.

Users can use the Preferences application to assign the MENU function to either the left or right mouse button. See "Changing the Functions of the Mouse Button" in Chapter 3 for more information on the MENU function.

Submenus

The main menu is created by Project Builder. All of the menus you create are submenus. They may open directly from the main menu, or they may open from one of its submenus (making them "sub-submenus"). Users open a submenu by choosing a controlling command on a menu that is already open.

Users can drag from a controlling command into a submenu and move the pointer to one of the submenu's commands. As long as the mouse button is held down, the submenu remains open and the controlling command remains highlighted. When the user releases the mouse button over a command, it is executed and the submenu disappears.

The OpenStep menu system gives users two options for working with submenus. They can be attached to their parent menu or torn off.

Keeping a Submenu Attached

The easiest way for users to open a submenu is to click on the parent menu command that opens it. They can also drag to the parent menu command, and release the mouse button. Either action will open the submenu and keep it attached to its super menu. The parent menu command will remain highlighted, indicating that its submenu is attached.

When attached, a parent menu and an attached submenu behave like a single window. User actions that move or close the parent menu will also move or close the submenu. An attached submenu has no close button of its own. A submenu attached to the main menu is assigned to the same window level as the main menu.

An attached submenu can also have its own attached submenu. This is illustrated in Figure 6-3. The Mail menu is attached to the Services menu, which is attached to the main menu. Moving the main menu moves all three.

Figure 6-3

Tearing Off an Attached Submenu

After opening a submenu, the user can tear it off and drag it to another location. See Figure 6-4. The torn-off menu can be moved close to the location where the user is working. The user can also close the parent menu and work only with the submenu. When a menu is torn off, it gets its own close button. Any submenus that were attached to the submenu when it was torn off remain attached and move with it.

Figure 6-4

Once a submenu has been torn away from its parent menu, it stays where the user puts it. To reattach it, the user must close it and then reopen it from the parent menu.

If the user presses the mouse button while the pointer is over the controlling command that opened the torn-off submenu, a second copy of the submenu temporarily appears in the attached position (next to its parent menu). Figure 6-5 shows this condition.

Figure 6-5

Closing a Submenu

An attached submenu can be removed from the screen in three ways:

• By choosing its controlling command again. In Figure 6-4, clicking on the Mail command (on the detached Services menu) will make the Mail submenu disappear.
• By choosing any other command in the parent menu.
• By removing its parent menu from the screen. For example, when a torn-off parent menu is closed, its attached submenu disappears from the screen.

A torn-off submenu is removed from the screen by clicking on its close button.

Commands

Menu commands use the targeted-action paradigm. Some commands--Cut, Copy, Paste, and Miniaturize Window, for example--require the user to select the target. Others--such as Hide, Quit, and Info--do not require selection, because the target is assumed by the action.

When a command is chosen (by either a mouse action or a keyboard alternative), it is highlighted. When the user uses a keyboard alternative to choose a command in an off-screen menu, some visual feedback is necessary.

OpenStep provides it by highlighting the menu's controlling command or, if the parent menu is not visible, the parent menu's controlling command. This indicates that the keyboard alternative has in fact invoked the command.

Many commands control submenus. The actions of these commands are simply to attach the submenu to the menu. These commands are identified by the submenu symbol

.

Other commands cause panels or standard windows to appear on screen:

• Some open a standard window--the New command in the Document menu, for example, or the Console command in the Workspace Manager Tools menu.
• Some put an attention panel on screen to help clarify or complete the command. For example, the Save As command produces a panel that asks the user to type in the file name the user wants to use for the document.
• Others open a panel that can stand on its own, independent of the command that produced it. Sometimes the panel simply imparts information to the user--a Help panel, for example. But usually it acts as a control panel where the user can give instructions to the application--the Font and Find panels, for example. Such panels are similar to submenus in that they open a range of options to the user.

The highlighting behavior of a command depends on its action. If it controls a submenu, it remains highlighted while the submenu is attached. If it controls an attention panel, it remains highlighted until the panel is closed. If it opens a panel that is not an attention panel, it does not remain highlighted.

You can disable a command, as described in "Disabling Commands" later in this chapter. Disabled commands have dark gray text (instead of the usual black) on the usual light gray background. They are completely inoperative and are not highlighted in response to user actions.

Keyboard Alternatives

Users can often use keyboard alternatives, instead of the mouse, to choose commands. A keyboard alternative is a combination of a character and the Command key. For example, holding down the Command key and pressing the "p" key is the standard keyboard alternative for the Print command. Keyboard alternatives are discussed in detail in "Other Action Commands" in Chapter 3.

Implementing Menus

The App Kit supplies the format for a basic appearance and functions for OpenStep menus. This section covers what you do to create a menu system for your application:

• Designing the menu hierarchy
• Choosing command names
• Disabling commands

Designing the Menu Hierarchy

When designing your application's menu hierarchy you begin with a main menu that was created by Project Builder. As you add features to your application, and design menus that will make those features available to your users, keep the following guidelines in mind:

• Use as many of the standard menus (described later in this chapter) as possible. Using the standard menus is one of the easiest ways to ensure consistency between applications, and it will speed up the development process
• Keep your application's menu hierarchy as shallow as possible. In general, a menu should be no more than two steps away from the main menu. It is even better when you can keep it one step away, but don't let it become too long (too many items) or confusing just to avoid the second level. Figure 6-6 shows a hierarchy that has too many levels.

Figure 6-6

• A menu should never have fewer than two commands, unless you add and remove commands dynamically and the menu has fewer than two commands in some situations. If an application has a menu with only one command in it, move the command up one level and replace the controlling command that opens that menu. A specific example of this is discussed minify Menu" later in this chapter.
• A menu can have as many submenus as it has commands, although only one at a time can be attached to the menu. A menu should appear only once in the menu hierarchy--it should not be the submenu of two menus.

Choosing Command Names

Names for commands should be short. Limit them to a single word whenever you can, and use very short phrases when you cannot. Avoid abbreviations in command names, especially abbreviations that are not standardized or widely used. Apply the same capitalization rules to all applications in the same language. (For English, commands are capitalized as they would be in a title--the first and last words begin with uppercase letters, as well as major words in between.)

Command names should be unique. No two commands, even when they are in different menus, should have the same name.

Commands That Perform Actions

If a command performs an action, its name should begin with a verb, giving a command name that reads like a short imperative sentence (addressed to the application). Examples of this include Hide, Open, Save As, and Revert to Saved.

When a menu command is used to toggle a state or condition, you should change its name rather than using two menu commands. The clearest way to inform the user of situation like this is to change the verb in the command's name. Do not, for example, create a menu with both Show Ruler and Hide Ruler commands. (Note that one of the commands would always be disabled.) Some examples of good names are listed in Table 6-1:

Table 6-1

First State	Second State	Notes
Show Ruler	Hide Ruler
Show Grid	Hide Grid
Use Grid	Ignore Grid	Do not use Grid On and Grid Off.
Bold	Unbold	Bold is treated like a verb in this command.

Commands That Open Panels

If the main purpose of a command is to perform an action, and it opens a panel to help the user through the action, name the command for the action rather than the panel. Follow the naming guidelines for action panels (see "Commands That Perform Actions" in the previous subsection). The standard Save, Save As, and Save To commands, for example, are action commands that happen to open a panel (named the Save panel). Notice that the panel is given a name that reflects the command's name.

If the main purpose of the command is to open the panel, then name the command for the panel. This usually results in a name that is a noun phrase, instead of the verb phrase used for action commands. The Preferences command, for example, opens the Preferences panel, and the Spelling command opens the Spelling panel.

With one exception, a command that opens a panel must have three dots after its name (for example, "Preferences..."). The exception is for panels that are warning panels, such as the panel that comes up when the user tries to revert to a saved version of a document. Because the user would complete the action if the warning panel did not open, you don't want to imply that the command opens a panel where the user does work. In addition to this, new users often examine an application's panels by choosing the menu commands with "...". You do not want these users to choose commands that open warning panels. For example, the Workspace Manager Log Out command does not have three dots, but it always opens a warning panel.

Do not put three dots after commands that open standard windows (like the New Viewer command in the Workspace Manager, or the New command in the standard Document menu).

---

Note - Use three periods (not the ellipsis character) to produce the three dots.

---

A command that opens a panel should not usually have the word "panel" in its name, since the three dots indicate that it opens a panel. It is acceptable to use "Panel" in a command name that would otherwise be identical to the name of an existing command name. For example, when the command that opens the Info panel is in the Info menu, the command is named Info Panel. When an application has no Info menu, the command is named just Info.

Commands That Open Submenus

Commands that open submenus usually begin with nouns, but verbs or adjectives are acceptable when they are clearer. It is important that these commands have names that clearly identify what the submenu contains. For example, it is a bad idea to have both a Tools menu and a Utilities menu under the main menu, since most users will not be able to remember the differences between the two.

If a command opens a submenu of actions, it might be appropriate to have the command name include the target of the actions. This scheme is used in the Document menu: the Open command can be read as Open Document, the New command can be read as New Document, and so on.

Commands That Open Standard Windows

Commands that open standard windows should begin with "New," as in the standard New command that appears in the Document menu, or match the title of the window they open. The Workspace Manager's View menu, for example, has a New Viewer command that opens a Viewer.

Sample Command Names

Some representative names for commands are listed in Table 6-2:

Table 6-2

Command Name	What the Command Does
Cut	Performs an action
Font	Attaches the Font menu
Font Panel...	Opens the Font Panel
Hide	Performs an action
Info Panel...	Opens the Info panel (used only when Info is already used)
New	Opens a new document in a standard window
Preferences...	Opens the Preferences menu
Save As...	An action command that happens to open a panel
Select All	Performs an action
Show Graphics	Switches to Hide Graphics when graphics are already visible

Disabling Commands

When an application is in use, it is not uncommon for commands to have no valid function. For example, when a text editor does not have any documents open, its Save and Close commands have no function. In situations like this, a menu command that has no current function should either be disabled or it should open a panel explaining the function is not currently available. The text editor mentioned previously, for example, should have its Save and Close commands disabled, as shown in Figure 6-7.

When users chooses a disabled command with a keyboard alternative, the computer should beep. This lets the user know that the command is not valid, even if the command is not visible.

If an invalid command opens an explanatory panel, it should explain why the command is inappropriate and offer assistance. The panel must provide more information than just that the command will not work, since that information can more directly be conveyed by disabling the command.

Graphical Devices in Menu Commands

The area to the right of a command can be used for two things: the keyboard alternative character or the submenu symbol. (Commands that control submenus cannot have keyboard alternatives.) Nothing else is permitted in this area.

In addition, menu commands should not use arbitrary graphical devices, such as check marks, to show state. There is almost always a more appropriate way to display current state in the OpenStep interface--for example, by using buttons or check boxes in a panel or by designing objects that can be directly manipulated (such as those in the Edit application's ruler).

Assigning Keyboard Alternatives

"Other Action Keys" in Chapter 3 lists standard and recommended keyboard alternatives.

Standard Menus and Commands

This section describes the standard menus supplied by the Application Kit, Using as many of them as possible will speed application development and help you achieve consistency between applications. It also covers the standard arrangements for commands in each menu.

Menu and command names are shown in U.S. English. If you are working in another language, there will be a different set of standard names (for example, Quit is Quitter in French applications) but you should use them.

---

Programmer's Note - The standard menu commands and much of their functions are supplied by the App Kit, Project Builder, and Interface Builder. The App Kit even manages the names of some supplied commands (such as changing Bold to Unbold) and disables some commands, such as Heavier when they are invalid. However, you should double-check that each menu command works properly.

---

Main Menu

Every application should have its main menu laid out as described in this section. Figure 6-8 shows a typical main menu layout.

Figure 6-8

The main menu's title should be the application's name, shortened when necessary. For example, the main menu of Interface Builder is titled IB because "Interface Builder" would waste screen space.

Table 6-3 describes Main Menu commands.

Table 6-3

Command	Action
Info	Attaches the Info menu, which contains commands that give general information about the application, as well as let the user set general preferences about how the application works. Info is the first command in the main menu in part because it can be read in conjunction with the application name in the title bar (for example, Info about Edit, Info about Draw, and so on). See "Info Menu" later in this chapter.
Document	Attaches the Document menu, which has commands that affect a document as a whole--opening, saving, and closing, for example. This menu is named differently in different applications, so it is important that the command be in a prominent, well-defined location (second). See "Document Menu" later in this chapter.
Edit	Attaches the Edit menu, which contains commands affecting the current selection. Every application that can have editable documents or selectable text must have this menu. See "Edit Menu" in this chapter.
Format	Attaches the Format menu, which contains commands affecting the layout of documents, including the font and paragraph format of text and the arrangement of graphic images. See "Format Menu" later in this chapter.
Windows	Attaches the Windows menu, which contains commands affecting the windows that belong to the application. See "Windows Menu" in this chapter.
Print...	Opens the Print panel, which permits the user to print a document. You can omit the Print command if your application does not print. In general, the Print command is assumed to print the document in the main window. If a panel can be printed (for example, one that contains a registration form), then to avoid confusion the panel might contain its own Print button.

Table 6-3 (Continued)

Command	Action
Services	Attaches the Services menu. This menu lets the user choose services provided by the system or by other applications. See "Services Menu" later in this chapter.
Hide	Hides all the windows of the application. See "Hiding and Retrieving Windows" in Chapter 4.
Quit	Terminates the application. If quitting the application might cause the user to lose work, then the application should open a Quit panel. Otherwise, the application should not require confirmation of a Quit command.

The Info, Services, Hide, and Quit commands should be in the main menu of every application. The other commands described above should be included when appropriate.

Adding Commands to the Main Menu

The main menu works best when it is short (so that commands are easy to find) and narrow (so that it does not take up much screen space). Try to limit your main menu to no more than 11 or 12 commands.

The main menu is also, for the most part, a menu of menus. The commands you add should generally be commands that open submenus.

When designing your application's user interface, you can move a command that the guidelines place in a submenu up one level to the main menu, provided that:

• The main menu is short enough to accommodate another command.
• The command provides functionality that is considered central, even crucial, to the application. For example, a text editor might bring the Font command up to the main menu from the Format menu, but a spreadsheet would not.

Like any other command that is added to the main menu, a command that is raised from a submenu should generally control another submenu.

When a command is promoted to the main menu, you should, for continuity, put it immediately after the command that controls the submenu it was in. For example, if the Font command is promoted from the Format menu, it follows the Format command. If the Find command is promoted from the Edit menu, it follows the Edit command, as shown in Figure 6-9.

Figure 6-9

Info Menu

The Info menu contains commands that let the user view and set information about the application as a whole. See Figure 6-10. A License command is an example of the kind of command you could add to this menu. Table 6-4 describes Info Menu commands.

Table 6-4

Command	Action
Info Panel...	Opens a panel that displays a small amount of basic information about the application. This standard panel is described in "Implementing the Info Panel" in Chapter 5.
Show Menus	Displays and tiles all the application's menus. There is currently no support for this command in the App Kit. You can implement it or not as you see fit.
Preferences...	Opens the application's Preferences panel, which permits the user to customize the application. This standard panel is described in "Implementing the Preferences Panel" in Chapter 5.
Help...	Opens a panel with helpful information on how to use the application. If you implement this command, you should use the standard Help panel, which is described in "Using the Help Panel in Chapter 5. If you do not implement this command, then when the user Help-clicks on an object in your application, the system opens a panel informing the user that the application does not use the OpenStep help system.

If your application does not support any of the commands in the Info menu except Info Panel, you can omit the menu and make the Info command open the panel instead of opening the menu. If you do this, add the three dots to the command.

Document Menu

This menu contains commands that affect a document as a whole. (Commands that affect selected parts of a document are generally in the Edit menu.) Applications that do not open or save documents of some kind and do not have a New command may omit this menu. Figure 6-11 shows a typical Document Menu, and Table 6-5 describes menu commands.

The command for of this menu (the second command in the main menu) should indicate the type of thing that the Open command opens and the Save command saves. It might be Document, Project, File, Model (for spreadsheets), or Shell (for a terminal emulator). Never call this menu Window, since most applications include the standard Windows menu.

Table 6-5

Command	Action
Open...	Opens the Open panel so the user can open a file. Opening a file also opens a window (or windows) that displays it.
New	Opens a new, unnamed file and a window to display it in. This new document should be in the same folder as would be displayed in the Open panel. (See the section "Using the Open Panel" in Chapter 5.)
Save	Saves any changes in the document displayed in the current main window to a file. If the document has never been saved to disk, this command should have the same effect as the Save As command.
Save As...	Saves the document displayed in the main window, as changed, by writing it to a new file with a name supplied by the user. The document displayed in the main window corresponds to the new file, and the window's title is changed accordingly. This command places a Save panel on screen that asks the user to type in a file name or cancel the command.
Save To...	Saves the current version of the document displayed in the main window, by writing it to a new file with a name supplied by the user. Save To is similar to the Save As command, but Save To does not replace the window's current file with the new one. You can choose whether to implement Save As or Save To, or both in your application.
Save All	Saves every document that is open in the application. This is a shortcut for performing the Save command on every open document.
Revert to Saved	Replaces the current version of the document displayed in the main window with the version saved on disk. This undoes any changes made to the document since it was last saved.
Close	Closes the document in the main window, and all the windows used to display that document. It is completely parallel to the Open command. See "Windows Menu" later in this chapter for information on a related command, Close Window.

If your application uses more than one window to display a document, you can add a Miniaturize command that miniaturizes all of the windows associated with the currently selected document (the document of the key window) into a single miniwindow. There is a standard command in the Windows menu (Miniaturize Window) that miniaturizes a single window.

Performing an Implicit New Command

If the user starts up an application by double-clicking an application icon rather than a document icon, the application should, if appropriate, provide the user with a new document to work in (performing an implicit New command). This is much friendlier to a new user than simply putting a menu on screen. Users should be permitted to disable this action through a preference.

It is almost always appropriate for general-purpose applications to perform an implicit New command. However, it is not appropriate if the application cannot produce a new document without user input. It is also not appropriate if producing a new document has side effects, such as modifying the file system by creating a new folder or adding a file that might persist even if the user decided not to save the new document.

When an application is started up automatically at login or from another application, it should not perform an implicit New command.

If the user opens another document without touching the new one that was provided at startup, the application could automatically close the new one. But this is not a requirement of the user interface.

Uneditable Documents

If a document is opened that the application will not allow the user to save (even with a Save As command), it should not permit the user to edit the document on screen. Waiting until the user is ready to save changes is too late.

Edit Menu

The Edit menu contains commands that alter the selection in the current key window (or in the main window if the key window does not respond to the command). Commands should be dimmed when they cannot operate on the current selection. See Figure 6-12.

Table 6-6 describes commands contained in the Edit Menu shown above.

Table 6-6

Command	Action
Cut	Deletes the current selection and copies it to the pasteboard.
Copy	Copies the current selection to the pasteboard without deleting it.
Paste	Replaces the current selection with the contents of the pasteboard.
Paste As	Attaches a submenu that permits the user to paste the current contents of the pasteboard into the document in a specified data type. The submenu lists the possible data types, as discussed in "Paste As" in the next subsection.

Table 6-6 (Continued)

Command	Action
Link	Attaches the Link menu, which contains commands for manipulating linked information. See "Link Menu" later in this chapter.
Delete	Deletes the current selection without copying it to the pasteboard, thus leaving the contents of the pasteboard intact. The Delete key has the same effect.
Undo	Undoes the last editing change. This usually includes all changes since the user last made a selection, including the selection of an insertion point.
Find	Attaches the Find menu, which contains commands related to the Find panel. See "Find Menu" later in this Chapter.
Spelling...	Opens the Spelling panel.
Check Spelling	Finds the next misspelled word without bringing up the Spelling panel.
Select All	Makes the entire contents of the file the current selection.

Applications that permit the user to edit text or graphics should support at least the Cut, Copy, Paste, and Select All commands. It is strongly recommended that you also implement the Undo command.

---

Programmer's Note - To includes this menu, drag it from the Palettes window of Interface Builder. It is already associated with the text object, which provides all the menu's functions except Find, Paste As, Link, and Undo.

---

Paste As Menu

The Paste As menu, shown in Figure 6-13, is rarely needed because applications can take care of pasteboard data types without user intervention. However, sometimes it is useful for the user to be able to specify the format in which data is pasted. For example, the user of a page layout program might want to choose whether text is pasted as ASCII or Rich Text Format (RTF), or whether graphics are pasted as EPS or TIFF.

This menu should include only the types appropriate for its application. As usual, you should disable any invalid menu commands. For example, when the pasteboard contains only text data, any graphics formats should be disabled.

Checking Spelling

The Spelling and Check Spelling commands in the Edit menu are intended to provide a uniform user interface for the spell check function that parallels the interface for Find. (Find is discussed in "Find Menu" later in this chapter.) These commands for checking spelling are supported by the App Kit's NSText object; custom objects will need custom code to check spelling.

The Spelling command opens the Spelling panel, which is described in Chapter 5, "Panels." The Check Spelling command is equivalent to the button on the panel that searches for and selects the next misspelled word in the main window; it permits the user to find the next misspelled word without bringing up the panel. If the application cannot find the next misspelled word until the user takes some action within the Spelling panel (for example, loads a dictionary), Check Spelling opens the panel. (This function is parallel to Save, which opens a panel when the user must first supply a file name, or Find Next opening the Find panel if the user needs to enter a text string to search for.)

If an application has spelling options that cannot be accommodated in a panel, Spelling and Check Spelling should be replaced by a Spelling command that opens a submenu. That menu could have Spelling Panel and Check Spelling commands.

Link Menu

The Link menu provides a standard interface for the functions of receiving and supplying linked information. See Figure 6-14. Linked information is information, such as a graphic image, that has been copied from another file or application, but will be automatically updated when the original is modified. See the Using the OpenStep Desktop for more information on working with links. Table 6-7 lists Link Menu commands and their actions.

---

Programmer's Note - The App Kit supports links with its NSDataLinkManager and NSDataLink classes. See the OpenStep Programming Reference for detailed information on how to make your application receive and supply links.

---

Table 6-7

Command	Action
Paste and Link	If the last Copy operation was performed in an application that can supply linked information, this command pastes the contents of the pasteboard and links it to the original information.
Paste Link Button	If the last Copy operation was performed in an application that can supply links, this command pastes a button that, when clicked, opens the document that contains the original information. Link buttons are discussed in "Implementing Buttons" in Chapter 7.
Publish Selection	Creates a link file. When this link file is dragged into documents that can receive linked information, the end result is as if a Paste and Link command had been done. This command places a panel on screen that asks the user to type in a file name or cancel the command.
Show Links	Highlights or unhighlights all linked information in the current document. The name of this command must alternate between Show Links and Hide Links, depending on the state of the document.
Link Inspector	Opens the Link Inspector panel, which is discussed in "Using the Link Inspector Panel" later in this chapter.

An application that can receive linked information (one that implements one or both of the Paste and Link and Paste Link Button commands) should also implement Show Links and Link Inspector.

When users choose the Show Links command, the application should highlight all the linked information in the main window, as shown in Figure 6-15. In the window shown in the illustration, the picture at the lower left is the only visible linked information, so it is the only picture that is highlighted with a chain pattern.

Find Menu

Applications that display large amounts of text are encouraged to include a Find menu like the one illustrated in Figure 6-16. Other applications might also find this menu useful, but because it is designed most specifically for text, a variation of it might better meet their needs. Table 6-8 describes Find Menu commands.

Table 6-8

Command	Action
Find Panel...	Opens the Find panel, makes it the key window, and selects everything in the text field labeled Find so that the user can easily enter new text. If the panel is already on screen, the command brings it to the front, makes it the key window, and selects the Find field.
Find Next	Searches forward for the next occurrence of the string in the panel's Find field.
Find Previous	Searches backward for the previous occurrence of the string in the panel's Find field.
Enter Selection	Enters the current selection into the panel's Find field so that Find Next and Find Previous can search for it.
Jump to Selection	Scrolls to display the beginning of the current selection.

Find Next and Find Previous begin searching at the current selection. If the search is successful, the text that is found is selected and becomes the starting point for the subsequent search. Neither command requires the Find panel to be on screen. However, if the panel's Find field is empty, Find Next and Find Previous both open the Find panel, make it the key window, and select its Find field. This is exactly what the Find Panel command does. These other commands do it as a convenience to the user, who has indicated an intention to do a search.

The Find panel is further described in "Implementing the Find Panel" in Chapter 5.

Format Menu

The Format menu, shown in Figure 6-17, should hold the principal formatting commands available to users of your application. For applications that deal mainly in numbers, they may be commands that format the text display of floating-point numbers or the graphical display of numeric data. For text processors, they may include the commands that would otherwise go into the Text menu, plus others. Table 6-9 describes commands in the Format Menu.

Table 6-9

Command	Action
Font	Opens the Font menu, which has commands that alter the font of the current selection. (See "Font Menu" on page 6-32)
Text	Attaches the Text menu, which lets the user choose the format of the selected blocks of text. (See "Text Menu" on page 6-35.)
Page Layout...	Opens the Page Layout panel, which lets users determine how documents are to be printed and displayed on the screen.

If you promote the Font command to the main menu and have no other commands to add to the Format menu, the Format menu would become little more than a container for the Text menu. In this circumstance, the commands that would otherwise go in the Text menu should be placed directly in the Format menu. A separate Text menu is needed only when there is reason to isolate these commands from other formatting commands, or to shorten what would otherwise be an excessively long Format menu.

When commands from the Text menu are placed in the Format menu, they should follow the Page Layout command, so that the Copy Ruler and Paste Ruler commands end the menu.

Font Menu

Applications that support text entry and editing should provide a Font menu (shown in Figure 6-18) and Font panel. The Font panel is described in "The Standard Panels" in Chapter 5. It contains controls that let users preview and set font attributes. The Font menu has a command to open the panel, and commands to make common adjustments to a font.

Each command alters one aspect of the font, such as its size or style, while leaving other aspects intact. The Font menu and Font panel target currently selected text. The Preferences panel should be used to alter the default font. Table 6-10 describes Font Menu commands.

---

Note - When you drag this menu in from Interface Builder's Palettes window, you get the menu and its functions from the NSText object with little additional work. Make sure that every command works, dims, and changes it name as it should.

---

Table 6-10

Command	Action
Font Panel...	Opens the Font panel.
Bold	Makes the current selection bold, if it is not bold already, and makes it unbold if it is. The name of the command must alternate between Bold and Unbold depending on the selection.
Italic	Makes the current selection italic or oblique, if it is not already, and makes it unitalic if it is. The name of the command must alternate between Italic and Unitalic depending on the selection.
Underline	Underlines the current selection, if it is not already underlined, and removes the underlining if it is. When the current selection is already underlined, the command name must change to Ununderline.
Larger	Makes the current selection one point larger.
Smaller	Makes the current selection one point smaller.
Heavier	Uses a heavier typeface to display the current selection.
Lighter	Uses a lighter typeface to display the current selection.
Superscript	Moves the currently selected text up an appropriate amount for a superscript. Choosing the command again moves the text that much higher.
Subscript	Moves the currently selected text down an appropriate amount for a subscript. Choosing the command again moves the text lower by the same amount.
Unscript	Returns the selected superscripted or subscripted text to the normal baseline of the text.
Copy Font	Copies from the current selection all the text attributes listed in this menu, including font family, font size, bold, italic, underlining, superscript, and subscript.
Paste Font	Alters the current selection so that it has all the font attributes previously copied with the Copy Font command.

---

Note - When the current selection is an insertion point, commands in the Font menu affect the characters that are typed next, rather than any existing text (unless the text area can contain only one font). If an area of text can have only one font, then selections on the Font menu and Font panel change the font of all text in the area.

---

The only commands that must be included in the Font menu are Font Panel, Copy Font, and Paste Font, although frequently used commands like Bold and Italic should be present in most cases. Applications that are not text intensive may decide to omit less frequently used commands, such as Heavier and Lighter.

Each command leaves other font attributes intact. For example, Bold will change 11-point Times Roman to 11-point Times Bold and 24-point Courier Oblique to 24-point Courier Bold Oblique.

If there is more than one font in the selection, the Larger and Smaller commands make each one point larger or smaller than its current size. The other commands make only the change that is appropriate for the first character in the selection. For example, if the first character in a multifont selection is italic, the Unitalic command will remove the italic trait from all the text in the selection, but will not change any text that is not italic. If the first character is not italic, the same command (now called Italic) will italicize the entire selection, but it will not alter any text that is already italic.

The Colors command, which opens the Colors panel, often appears in the Font menu. You can put it somewhere else; each application should place the Colors command in a menu that indicates the kind of objects the Colors panel can affect. In Mail and Edit, colors can be applied only to characters (and not to their background), so the Colors command is in the Font menu.

Text Menu

The Text menu, shown in Figure 6-19, contains a set of formatting commands that affect text. These commands are supported by the Application Kit's NSText object.They can be isolated in a Text submenu, as shown here or included directly in the Format menu. If you have other formatting commands that are more important to your application, those commands, rather than those listed in Table 6-11, should go in the Format menu.

Table 6-11

Command	Action
Align Left	Aligns the text at the left margin, leaving a ragged right margin.
Center	Centers the text between the left and right margins.
Align Right	Aligns the text at the right margin, leaving a ragged left margin.
Justify	Aligns the text at both the left and right margins.

Table 6-11 (Continued)

Command	Action
Show Ruler	Displays a ruler in the text area, if the ruler is not currently visible. Otherwise, this command hides the ruler. The name must alternate between Show Ruler and Hide Ruler, depending on the state of the text area. The ruler is a scale containing controls that affect the format of a paragraph (such as margins and tabs).
Copy Ruler	Copies the ruler settings in the first paragraph of the selected text.
Paste Ruler	Alters the paragraphs containing the text selection to have the settings most recently copied with the Copy Ruler command.

An application, such as a word processor, which includes many other text-related commands, can put all of them in the Format menu, in the order that is most useful. All applications should, however, use the command names shown above in the Text menu, no matter which menu the commands are in. (See "Format Menu" in this chapter.)

Windows Menu

The Windows menu (see Figure 6-20) contains commands that affect the windows belonging to the application. You may replace this menu with one more suitable for your application. If the application that has multiple windows per document, for example, you might add commands that organize those windows. Table 6-12 describes Windows Menu commands.

---

Programmer's Note - This menu, with all of its functionality, is provided for you. Drag the Windows command into your main menu from the Palettes window of Interface Builder.

---

Table 6-12

Command	Action
Arrange in Front	Stacks and offsets all the application's document windows (those that can become the main window and are created using Open and New commands) at the front of the screen. While this command is recommended, it is not mandatory.
Miniaturize Window	Miniaturizes the key window if it has a miniaturize button. The affected window need not be a document window.
Close Window	Closes the key window if it has a close button. If the window is the last one (or only one) open displaying a document, it also closes the document, just as the Close command would. (See "Document Window" earlier in this chapter, for a description of the Close command.)

The commands in this menu bring windows to the front of the screen or remove them. Other kinds of commands, even if they affect windows in some way, should be located elsewhere in the menu hierarchy.

You can replace Arrange in Front with an Arrange command that opens a panel or menu giving the user more choices concerning which windows to arrange and how they should be tiled or stacked.

The commands inserted below Arrange in Front list current document windows. Each command brings one window to the front and, if possible, makes it the key window. The Application Kit creates this list and dynamically adds a command for each new document window that it is opened. Because the Application Kit creates the command names from the title bars of the document window, improperly titled windows can lead to the Windows menu becoming too wide. Window titles are discussed in "Choosing a Title in Chapter 4. Figure 6-21 is an example of dynamically created commands for document windows.

Services Menu

This menu is required; it contains commands that invoke services provided by the system or by other applications. Refer to Figure 6-22. Commands are placed in the menu dynamically by the Application Kit when it becomes aware that other applications are service providers. This means there is no need for you to specify the order in which commands are added.

Figure 6-22

---

Programmer's Note - To take advantage of services provided by other applications, you should first drag the Services menu from the Palettes window of Interface Builder. Then, if you use the NSText object in your application, your application automatically gets many services. Your application can get more kinds of services if you write a few lines of code.

---

Providing Services

---

Programmer's Note - To provide services to other applications, your application advertises its services in a section of its executable file or in its file package. (File packages are special folders that look and behave like files.) These services are automatically included in the menus of any applications that can accept them.

---

If you application provides services, you can specify how menu commands that request services should be worded. The following guidelines apply:

• Each command should begin with a verb and should name the application that will respond to the request. If the name of the application can be interpreted as a verb, it can be the first word of a command phrase (for example, Chart Selection for an application named Chart). Otherwise, the verb that begins the command should be followed by a preposition and the name of the responding application (Open from Workspace).
• If an application responds to more than one service request, it can arrange the commands in a submenu under the application's name. Commands in the submenu do not have to name the application, but should, like all other commands, begin with a verb.

However, if the application name is commonly interpreted as a verb, the submenu commands can consist of words that would meaningfully follow the application name in a phrase, much as the commands in the Paste As menu. For example, Figure 6-23 shows the Sort command:

Service requests conditionally activate the other application, but only if user input might be required. For example, Digital Webster is likely to require the user to scroll the display, but the Workspace Manager does not need the user's help to get a file opened. The application that opens the file will become active, but the Workspace Manager will not.

Adding a Tools Menu

Since it is easiest for users to find a command when it is in a submenu with related commands, the commands that open panels and special non-document windows should be located throughout the menu hierarchy in the appropriate submenu. For example, the Font Panel command is in the Font menu, the Open command is in the Document menu, and Page Layout is in the Format menu.

In some cases, a window or panel is an independent tool with a functional domain all its own, and you may find it difficult to group the command that controls this window with your other commands. Some common examples of this are the palettes in a graphics program, the Inspector in Interface Builder, and the Console in the Workspace Manager. If your application has two or more such commands, consider collecting them together in a Tools menu. Figure 6-24 shows a Tools menu from the Workspace Manager.

The Tools menu should not be considered a default location for commands that open windows or panels. If a window or panel is not truly a tool, its command should go elsewhere. If you can put a command into a submenu by function, you should do so.