Xfce Wiki

UI guidelines for Xfce are defined by this and a few other pages. These are guide lines provided to make the look and feel of native Xfce application be alike between applications. Other UI definitions

* UI Guidelines

Generally Xfce uses the guidelines found in GNOME Human Interface Guidelines 2.0. But as an addition to this, the following provide a check list of things needed to be considered when making an Xfce application more Xfce like.

This list is originally provided by Jannis Pohlmann, and it is meant as an inspiration and a place to start, so please anything that is missing, please feel free to add it.

• Assign applications to only one category in the Applications menu
• For application suites, install one Applications menu item per sub-application
• In the menu item name, include a description of the functionality and the name of the application
• Do not include words like “Xfce” or “GTK+” in menu names
• Do not include technical details in menu item names
• If the application name already is descriptive enough, use format “Application Name” for menu names, otherwise use “ApplicationName FunctionalDescription”
• Provide tooltip for Application menu items
• Phrase tooltip as an imperative verb (e.g. “design”, “write”)
• In the tooltip, describe only the most important tasks the user can accomplish with the application (don't be too verbose though)

• Only use the notification area for one icon at a time
• Clearly delimit the borders of progress bars and monitors
• Don't use animated icons (except maybe for blinking an errors)
• Perform default action on double-click or space key
• Display icon menu on right-click or Shift+F10
• If there is a properties item in the icon menu, open it on Alt+Enter
• Obey normal tooltip conventions

• Give every window (exception: alerts and toolboxes) a title containing information which is relevant to the user and distinguishes it from other windows
• Omit other information in the window title (like version numbers and technical information)
• Do not draw your own window borders, instead provide hints for the desired border type to the window manager
• Make windows modal only if interaction with other parts of the application could cause problems
• Provide clear way (like a cancel button) to leave modal windows
• Do not use system modal windows (blocking interaction with *all* windows)
• Ensure all application windows support click-to-focus, point-to-focus and keyboard focus (e.g. Alt+Tab)
• Show windows as early as possible but make sure they have the correct size before displaying it
• If window data takes longer to load, first display the window, then load the contents
• Hide windows as soon as possible after they are closed

• Ensure that primary windows appear in the panel window list
• Use filename (basename) or document name as title for document-based applications. If the pathname is important, show the full pathname in the status bar
• Before a new document has been saved, set the window title to “Unsaved <document type>” (e.g. “Unsaved Spreadsheet”)
• When a document has pending changes, insert an asterisk (*) at the beginning of the window title (e.g. “*My Report.sxc”)
• For non-document-based applications use “Application Name” as the window title
• Do not place information that is of no use for the user in the title (like version numbers, company names etc.)
• Use Single Document Interface windows unless there is a compelling reason not to

• Make sure utility windows are not shown in the panel window list unless they are or may be the only window shown by your application
• Ensure utility windows are raised above the application when the primary application window is selected from the window list
• Instantly apply settings. Do not make the user press an “OK” or “Apply” button to make changes happen, unless the change will take more than a second to apply or changes in the window have to be applied simultaneously
• Provide “Apply” buttons for groups of settings where required and leave the rest of the controls as instant reply where possible