|
|
Sample Programs from NeXSTEP 3.3
{\rtf0\ansi{\fonttbl\f1\fswiss Helvetica;\f0\fmodern Courier;}
\paperw11780
\paperh10200
\margl120
\margr120
{\colortbl\red0\green0\blue0;}
\pard\tx1140\tx2300\tx3440\tx4600\tx5760\tx6900\tx8060\tx9200\tx10360\tx11520\f1\b0\i0\ul0\fs36\fc0 Adding a Tools Menu
\fs24 \
\
Applications have windows other than document windows and need commands other than Open and New to bring them to the screen. For example, most applications have Find and Font panels, the Workspace Manager has a Processes panel and a Console window, and Webster has a Contents window that contains everything in the dictionary except the actual entries. Each window has a particular, well-defined function within the application and is controlled by its own command.\
\
Since it's easiest for users to find a command if it's arranged in a submenu with other functionally related commands, commands that bring up panels and other special windows like these should be located throughout the menu hierarchy as appropriate. 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.\
\
However, if the window is an independent tool that encapsulates a functional domain all its own, it may be difficult to group it with other commands. Examples are the palettes in a graphics program or the Inspector in Interface Builder. If your application has two or more such commands, you should consider collecting them together in a Tools menu. See the Workspace Manager for an example.\
\
However, the Tools menu should not be considered a default location for commands that bring up windows. If a window isn't perceived to be to a tool, its command should go elsewhere. If a command can be functionally grouped, it should be.
}
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.