Menus
File

The contents of the File menu strongly depends on the type of application. For the purpose of defining how File menus should look, we group applications into three categories:

• Document-Oriented Applications, e.g. text editors, word processors, and image manipulation programs.
• Games
• Other Applications.

Please note: This list may be extended in the future.

This section describes the file menu for a document-oriented application. An application is document-oriented if it operates on a document of some sort. Examples of documents can be: Text Files, Images, Drawings, etc.

A document always has a storage location associated with it. This is the location where the document is normally stored. The storage location can be undefined if the document has just been created. The storage location is often a filename or a URL.

For a document-oriented application, a typical File menu might look like this:

Not all menu items have to be present. If they are present, the items should have the following meaning:

If the New option has a sub-menu then the New option does not have a shortcut key combination assigned but rather a little arrow indicating that a sub-menu will be presented when selected. The application may offer the shortcut key combination Ctrl+N to select the default template from this sub-menu. The default template should be the topmost item in the sub-menu.

If the application only offers a read-only view or if the data in the main document area can never be saved back to the original source, Save As... should be the only saving option offered in the File menu. It should also be bound to the default save keyboard accelerator. The Save entry is only appropriate when files can be opened, editted and then saved back to the original file.

If the user has made modifications to the document and invokes the Close or Quit options, he/she should be asked by means of a dialog box whether the document should be saved.

If the user has made modifications to the document and the Revert option has been invoked, the user should be asked for confirmation by means of a dialog box.

Depending on whether your application is an SDI or an MDI application, its behaviour should follow the rules outlined below. Note that KDE applications should follow the SDI model. The MDI model is listed for informational purposes only.

SDI applications
In SDI the application is represented by the document-window. Each document-window can contain a single document.

Starting up an SDI application without specifying a document to load causes the application to enter its initial state.

In the initial state an empty default document is shown in the document window. An application may, by means of a modal dialog, ask the user whether to create a new document or open an existing document. The dialog should provide an option for experienced users to skip the dialog in the future. The dialog should also have an option to Quit the application.

After a document has been created or opened, the application is no longer in the initial state. An application also leaves the initial state when modifications to the empty default document are made.

If the application is in its initial state and the user opens a new document by selecting New in the File-menu or opens an existing document by selecting Open in the File-menu, then the document is loaded into the application, replacing the empty default document. This causes the application to leave the initial state.

If the application is NOT in the initial state and the user opens a new document by selecting either New or Open in the File-menu, then a new application is started in which the document is loaded.

Closing the document by selecting Close in the File-menu causes the application to return to the initial state. Note that this may cause a dialog to pop up asking the user whether to create a new document or open an existing document.

Closing the application by selecting Quit in the File-menu closes the document-window and the document within it. Closing the document-window by selecting the X on the window border is equivalent to selecting Quit in the File-menu.

In MDI the application is represented by the application-window. The application-window can contain a number of document-windows. Each opened document is represented by a document-window. KDE applications should not use this model, but use the SDI model instead.

Starting up an MDI application without specifying a document to load will result in an application-window without any document windows.

When the user selects either New or Open in the File-menu, a new document-window appears.

When the user selects Close in the File-menu, the document-window is closed as well as the document. Closing a document-window by selecting the X on the window border is equivalent to selecting Close in the File-menu.

When the user selects Quit in the File-menu, the application window is closed as well as all the document-windows and the documents with them. Closing the application-window by selecting the X on the window border is equivalent to selecting Quit in the File-menu.

Games

In games, the File menu is replaced with a Game menu. It often looks like this:

As with all menus, options that are not available in a specific game can be left out, and additional options can be added.

The Quit option should always be available and should always be at the bottom of the menu. Selecting it terminates the application.

Applications that do not fit any of the above categories should have a file menu consistent with:

As with all menus, options that are not available in a specific application can be left out and additional options can be added.

The Quit option should always be available and should always be at the bottom of the menu. Selecting it terminates the application.

Previous Next