A primary window usually presents a view of the user's data, such as a text document in a word processor application, an image in a drawing program, or calculations in a calculator or spreadsheet application. It may also be a view of something more abstract, like a game. A single instance of an application may have more than one primary window, and more than one kind of primary window.
A primary application window normally has a border, a menubar and a statusbar, and may also contain one or more toolbars.
For document-based applications, use Document Name as the window title. Use only the filename, not the full pathname, as this will make it easier to distinguish both here and other places the window title is used, such as the window list on the panel. If the pathname is important, for example the user has opened two documents with the same name from different directories in the same application, show the full pathname in the statusbar.
Example 3.1. Using document names as window titles
Application | Example window title |
---|---|
AbiWord | My Report.abw |
Evolution | Inbox |
Music player | U2 - Better Than the Real Thing |
Before a new document has been saved for the first time, set the window title to Unsaved <document type>. For example, Unsaved Drawing, Unsaved Spreadsheet, or the more generic Unsaved Document.
While document names are most pertinent to users, we understand that application developers may want to increase recognition of their application. If you plan to include your application's name in the title of a primary window, use the following format: Document Name - Application Name. This will ensure that the document name appears in limited space situations such as the system window list.
![]() | Warning |
---|---|
Including the application name in the title of a document-based application is not recommended. |
For other types of application, use Application Name as the window title.
Example 3.2. Using application names as window titles
Application | Window title |
---|---|
Dictionary | Dictionary |
Calculator | Calculator |
Do not place version numbers, company names, or other information that is of no immediate use to the user in the window title. These consume space, making titles in limited spaces such as the system window list less useful, and add more text the user has to scan to find useful information. In a "beta" product, where version numbers are critical for bug information, placing version numbers can be useful, but remove them from stable releases. Place version information in the about box instead.
![]() | Tip |
---|---|
Think about naming windows in the context of the panel window list. On a typical screen with a relatively small number of windows open, a window will have 20-30 characters of text and an icon. Consider which text will provide the most immediately obvious clues to a user looking for a particular window. |
A single document interface places each document in its own primary window. Toolboxes and other utility windows may be shared between multiple SDI documents, but closing them should have no effect on the document windows. Use SDI for your GNOME application unless there is a compelling reason not to.
A multiple document interface presents a paned, tabbed or similar presentation of two documents within a single window.
MDI has several inherent usability problems, so its use is discouraged in applications. It is better to open each document in a new primary window, with its own menubar, toolbars and statusbar, or allow multiple instances of your application to be run simultaneously. In either case, this leaves it for the window manager (acting on the user's preferences) rather than your application to decide how to group and present document windows from the same application.
In a typical SDI application, document windows are treated as primary. For example, when all document windows have been closed, the application (including utility windows) exits as well. In CSDI a utility window is treated as the primary window. For example, closing this utility window will close all document windows and exit the application.
![]() | Warning |
---|---|
Using CSDI is not recommended |
CSDI is sometimes used because document windows might be too small to have menu bars. Typically this is not the normal use case for the application, but does represent a significant minority use case. For example, an image editor being used to edit small web page elements will often result in very small document windows that cannot accomodate a title bar.
We should really have a way of doing overflow automatically in GTK+.A better way to address this problem is to allow menu bars to "collapse" into an overflow button, in much the same way toolbars operate when the window shrinks to below the toolbar width. This allows for small windows, but also provides an opportunity for people to figure out where their menus have gone.
![]() | Tip |
---|---|
Note that if very small documents are the primary use case for your application, you should consider finding a means to avoid windows altogether. Windows are not an effective interface for dealing with large numbers of small items. Consider looking for a fixed/automated layout system for presenting the "documents". Also consider if the "documents" will be primarily used in a higher level grouping, in which case that grouping could become the document instead. |