Composer 5 Dialogs

The purpose of this document is to detail the dialogs used by Mozilla Composer, including improvements done during the "Gromit" project (now in the "MozillaClassic" tree in the CVS code repository.) This should be the basis for the new dialogs to be completed using the new XML-based dialogs in the Seamonkey project. We will start with a description of some characteristics common to all the dialogs of a given type.

Normal Dialogs

1. OK and Cancel buttons are usually present in a dialog and located along the bottom of the dialog. On the Mac, the placement should be Cancel, OK.
2. The OK button is usually grayed (disabled) if there is user input required to complete the action of the dialog (such as entering text in an edit field.) It is enabled after the user makes enters some valid text (something other than just whitespace) into the required editbox(es).

Multipane or Tabbed Dialogs

1. At the bottom of the outer panel, there are four buttons:OK, Cancel, Apply, and Help.

On the Mac the order of buttons is: Help, Cancel, Apply, and OK
Of course the Help button should only be present if help is available.
2. The Help button should bring up the help topic for the particular pane that is showing. The F1 key should bring up this same help content (standard in Windows, what about other platforms?)
3. The Apply button is initially grayed (disabled) until the user makes a change in one of the settings in any panel, then it is enabled. Switching from one panel to another should not automatically do the "Apply" actions.
4. The OK, Cancel, and Help button should always be enabled.
5. The OK button should do the same action as the Apply button, then close the dialog.
6. After the Apply button is used, all panels should execute actions needed to apply the changed settings. This action (currently) cannot be reversed while in the dialog, so the text on the OK button is changed to "Close" and the button remains enabled. Note that the action can be reversed by using Undo after the dialog is dismissed.
7. After using Apply, this button should be disabled until another setting is changed in the dialog.
8. Suggested new behavior:

After the state described in 4 above, the Cancel button text could be changed to "Undo" so the user can undo the last Apply action without leaving the dialog. Since the new Undo system supports multiple levels, this button should be left in the "Undo" state, available to undo any previous Apply action taken while in the dialog. After using this undo feature, the button text should change back to Cancel only after there all actions applied within the dialog are undone. If this state is reached the document should be in the same exact state as when the dialog was created, thus we probably should also change the "Close" button text back to "OK."

Composer Dialogs

The following will be needed only if a separate Composer Application with file I/O and publishing are implemented (i.e., they are not needed for just the Ender widget):

Dialog	Invoke	Comments	Days to Implement
Open Page	File | Open Page...	Previously shared with Navigator. Do the same	1
New Page From Template	File | New | Page from Template...		1
Publish	File | Publish	Scrolling list Combo box of document history	3
SaveChanges	File | Browse Page or Edit | HTML Source  and page already exists and has changes	This is a simple "Yes, No, Cancel" message box in Windows	1/2
Save New Page	File | Browse Page or Edit | HTML Source  and page has not been saved yet		1/2
Confirm Save File	File | Save or File | Save As		1/2
Saving/Publishing Page	During saving or publishing of HTML with associated files		1/2
Page Title	File | Save (new page)		1/4
SelectEditChanges	Upon returning focus to the page after editing in an external editor AND changes were also made in Composer's version after it was loaded into the other editor but before those changes were saved to disk. (Now you have two versions with new changes, each different from the file on disk so the dialog lets user decide which changes to accept)		1/2