Dialogs are secondary windows that appear over a primary, parent window. They are used to present additional information or controls, including preferences, properties, or to present messages or questions.

GTK+ provides a number of stock dialogs that can be used, such as for printing or color selection.

There are three basic types of dialog design.

When to use

Dialogs are a commonly recognized design pattern, and there are established conventions for the different types of dialogs that you might want to use. The guidelines on each type of dialog provides further information on this.

While dialogs can be an effective way to disclose additional controls or information, they can also be a source of interruption for the user. For this reason, always question whether a dialog is necessary, and work to avoid the situations in which they are required.

There are many ways to avoid using dialogs. Examples include:

  • Inline composition for new messages, records or contacts.

  • In-application notifications are an alternative to message dialogs.

  • Popovers can be a way to display additional controls or options in a less disruptive manner.

Message Dialogs

Message dialogs are the simplest type of dialog. They present a message or question, along with 1-3 buttons with which to respond. They are always modal, meaning that they prevent access to their parent window. Message dialogs are an appropriate choice when it is essential that the user sees and responds to a message.


Confirmation dialogs use a message dialog to check - or confirm - that the user wants to carry out an action. They have two buttons: one to confirm that the action should be carried out and one to cancel the action.

Confirmation dialogs will often be accidentally or automatically acknowledged, and will not always prevent mistakes from happening. It is often better to provide undo functionality instead.

Error dialogs present an error message to the user. They often include a single button that allows the user to acknowledge and close the dialog.

Error dialogs should generally be a last resort. You should design your application so that errors do not occur, and to automatically recover if something does go wrong.

Action Dialogs

Action dialogs present options and information about a specific action before it is carried out. They have a heading (which typically describes the action) and two buttons which allow the action to be carried out or cancelled.

The user may be required to choose options or content items before an action can be carried out. In these cases, the affirmative action button should be insensitive before the required steps have been performed in the dialog itself.

Buttons in action dialogs should be labelled with imperative verbs, for example Save, Print. This allows users to select an action with less hesitation.


Many of the stock GTK+ dialogs are action dialogs. The print dialog is a good example: it is displayed in response to the user using the print action, and presents information and options for that print action. The two header bar buttons allow the print action to either be cancelled or carried out.

Presentation Dialogs

Presentation dialogs present information or controls. Like action dialogs, they have a header bar and a subject. However, instead of prefixing an action, their content relates to an application or content item.


Preferences and properties are both examples of presentation dialogs, and both present information and settings in relation to a specific entity (either an application or a content item). Properties dialogs are a good example of how dialogs can be used to disclose additional information which is not always needed in the main application window.

Resist the temptation to provide a preference window for your application. Always question whether additional settings are really necessary. Most people will not bother to investigate the preferences that you provide, and configuration options will contribute to the complexity of your application. Make an effort to ensure that your application design works for everybody without the need to change its settings.

Instant and Explicit Apply

Presentation dialogs are either instant or explicit apply. In instant apply dialogs, changes to settings or values are immediately updated. In contrast, explicit apply dialogs include a button for applying changes.

Instant apply should be used wherever possible. Instant apply presentation dialogs have a close button in their header bar.

Explicit apply is only necessary if changes in the dialog have to be applied simultaneously in order to have the desired behaviour. Explicit apply dialogs include a Cancel and a Done button (Cancel resets all values in the dialog to the state before it was opened and Done applies all changes and closes the window).

Button order

Many dialogs include an affirmative and a cancel button, both of which close the dialog window. The affirmative button carries out the operation that is the subject of the dialog, such as Print, Save, or Quit, and the cancel button closes the window and prevents the operation from taking place.

Always ensure that the cancel button appears first, before the affirmative button. In left-to-right locales, this is on the left. This ensures that users become aware of, and are reminded of, the ability to cancel prior to encountering the affirmative button.

Default buttons

When designing a dialog or utility window, you can assign the return key to activate a particular button in the window. GNOME indicates this button to the user by drawing a different border around it.

Choose the default button to be the most likely action, such as a confirmation action or an action that applies changes. Do not make a button the default if its action is irreversible, destructive or otherwise inconvenient to the user. If there is no appropriate button in your window, to designate as the default button, do not set one.

In particular, it is currently not recommended to make the Close button the default in an instant apply window, as this can lead to users closing the window accidentally before they have finished using it.

General guidelines

  • Dialog windows should never pop up unexpectedly, and should only ever be displayed in immediate response to a deliberate user action.

  • Dialogs should always have a parent window.

  • Follow the layout guidelines when designing the content of windows.

  • Use view switchers or tabs to break up controls and information.

  • Avoid stacking dialog windows on top of one another. Only one dialog window should be displayed at a time.

  • When an affirmative button is included, label it with its actual action. Print is a better label than OK or Done, for example.

  • Do not enable the OK or equivalent button until all fields that require input have been attended to by the user.

  • When opening a dialog, provide initial keyboard focus to the component that you expect users to operate first. This focus is especially important for users who must use a keyboard to navigate your application.