Class DialogFooter

  • All Implemented Interfaces:
    java.awt.image.ImageObserver, java.awt.MenuContainer, java.io.Serializable, javax.accessibility.Accessible

    public class DialogFooter
    extends javax.swing.JPanel
    This is a row of buttons, intended to be displayed at the bottom of a dialog. This class is strongly related to the com.bric.swing.QDialog project, although the DialogFooter can exist by itself.

    On the left of a footer are controls that should apply to the dialog itself, such as "Help" button, or a "Reset Preferences" button. On the far right are buttons that should dismiss this dialog. They may be presented in different orders on different platforms based on the reverseButtonOrder boolean.

    Buttons are also generally normalized, so the widths of buttons are equal.

    This object will "latch onto" the RootPane that contains it. It is assumed two DialogFooters will not be contained in the same RootPane. It is also assumed the same DialogFooter will not be passed around to several different RootPanes.

    Preset Options

    This class has several OPTION constants to create specific buttons.

    In each constant the first option is the default button unless you specify otherwise. The Apple Interface Guidelines advises: "The default button should be the button that represents the action that the user is most likely to perform if that action isnŐt potentially dangerous."

    The YES_NO options should be approached with special reluctance. Microsoft cautions, "Use Yes and No buttons only to respond to yes or no questions." This seems obvious enough, but Apple adds, "Button names should correspond to the action the user performs when pressing the buttonŃfor example, Erase, Save, or Delete." So instead of presenting a YES_NO dialog with the question "Do you want to continue?" a better dialog might provide the options "Cancel" and "Continue". In short: we as developers might tend to lazily use this option and phrase dialogs in such a way that yes/no options make sense, but in fact the commit buttons should be more descriptive.

    Partly because of the need to avoid yes/no questions, DialogFooter introduces the dialog type: SAVE_DONT_SAVE_CANCEL_OPTION. This is mostly straightforward, but there is one catch: on Mac the buttons are reordered: "Save", "Cancel" and "Don't Save". This is to conform with standard Mac behavior. (Or, more specifically: because the Apple guidelines state that a button that can cause permanent data loss be as physically far from a "safe" button as possible.) On all other platforms the buttons are listed in the order "Save", "Don't Save" and "Cancel".

    Also note the field reverseButtonOrder controls the order each option is presented in the dialog from left-to-right.

    Platform Differences

    These are based mostly on studying Apple and Vista interface guidelines.
  • On Mac, command-period acts like the escape key in dialogs.
  • On Mac the Help component is the standard Mac help icon. On other platforms the help component is a com.bric.swing.JLink.
  • By default button order is reversed on Macs compared to other platforms. See the DialogFooter.reverseButtonOrder field for details.
  • There is a static boolean to control whether button mnemonics should be universally activated. This was added because when studying Windows XP there seemed to be no fixed rules for whether to use mnemonics or not. (Some dialogs show them, some dialogs don't.) So I leave it to your discretion to activate them. I think this boolean should never be activated on Vista or Mac, but on XP and Linux flavors: that's up to you. (Remember using the alt key usually activates the mnemonics in most Java look-and-feels, so just because they aren't universally active doesn't mean you're hurting accessibility needs.)
See Also:
Serialized Form