• All but New, Open, and Exit are disabled in the File menu
• The Schedule menu, and all of its items, is disabled when there is no open calendar.
• All but the last four items in the View menu are disabled where there is no open calendar.

I think a table with each command, or groups of commands would be good. The table would have two columns -- commands and when enabled. State the commands are disabled in all other circumstances. The commands column would probably be well organized by menu, so there's a couple levels of command hierarchy in it. 3 "Pressing OK (4sep02)"

After a grep scan, it appears that nowhere do we say that scheduling dialogs "remain" on the screen after the user presses "OK". I suppose it's possible that some other word that "remain" was used, but the important point is that it looks like we most recently intended to go with all data-entry dialogs going away after `OK'. In the back of my mind, I've been thinking that data-entry dialogs stay up after `OK', because at some point in the past that was the case. Anyway, I like the (seemingly latest) idea of dialogs going away with `OK', but we need to be absolutely clear that this is the case consistently throughout. Also, it's appropriate either to have subsection here title "Precise Details of OK", or update the extant subsection "Precise Details of Clear and Cancel" to "Precise Details of OK, Clear and Cancel".

2.11.3. Comma-Separated Lists

May have any number of spaces around commas. In multi-line text input fields, may have any number of newline characters around commas.

2.11.4. Typed Input

Typed input is confirmed by one of three user actions

1. clicking the mouse on any other enabled element in a dialog
2. typing the tab key, which makes the lexically next enabled element active
3. typing the return (enter) key, which has the effect of pressing the `OK' or `Confirm' button

Include min/max values for year, which within reason are 0 and 3000.

When a user enters a time or date in a format that is different than the current setting of the time or date display options, the system automatically converts the time or date to options-specified format when the user confirms the data entry. For example, suppose the current setting of date and time format is

ddmmmyy

Following input confirmation, the parsing rules for date input are the following:

1. If the input is empty, the completed date is that defined as the default value for the input text field in which the date was entered, or today's date if no default is specified.
2. If the input is a single integer and that integer is beteewn 1 and the number of days in the current month, the completed date is the input day in the current month and year.
3. If the input consists of two integers, the integers are interpreted as a day number and month number, in the order defined by the current option setting for `Date Input Format' described in section Section 2.7.1. If the month number is between 1 and 12 and the day number is between 1 and the number of days in that month, then the completed date is the input month and input day in the current year.
4. If the input consists of three integers, the integers are interpreted as the day, month, and year, in the order defined by the option setting for `Date Input Format'. If the month is between 1 and 12, the day between 1 and the number of days in that month, and the year between 0 and 9999, then the completed date is that month, day, and year.
5. If the input consists of a legal month name and an integer in either order, and the day number is between 1 and the number of days in that month, then the completed date is the input month and input day in the current year.
6. If the input consists of a legal month name and two integers, the inputs are interpted as a month, day, and year, with the relative order of the day and year numbers defined by the option setting for `Date Input Format'.
7. Any other input is illegal.

When a date input is illegal, the system responds by highlighting the erroneous text and leaving the input field active with the typing cursor at the beginning of the text. This means that however the user confirmed the input, the original input field remains active, not the field to which the user moved by typing tab or clicking the mouse. If the user confirms an erroneous input by typing return, the `OK' or `Confirm' operation is not performed.

In the `Times and Dates' options tab,

2.11.6. Item Uniqueness Requirements

We don't need to include Sched-By, On, and/or Host as part of uniqueness as well, in case (rare) that two people schedule exactly the same meeting on two different hosts. This was addressed already in the meeting-scheduling section, here, and should be reiterated here.

For appts and meetings, go get it from whereever. I think we need to do a refinement of what we have so far, in that we have to unbundle recurring instances in order to make the check, or at least "conceptually" unbundle them. There's a modelling issue lurking here, viz., whether to model recurring items physically as single or multiple items. If we go with the single-item model, the logic like the last clause of the ScheduleAppt precond, q.v., needs to to be updated to deal properly with recurring items by somehow conceptually "generating" instances of recurring appts.

For events, I think it's gotta be name only, or name plus non-overlapping date. The deal is we need to be able to distinguish between a 3-day event versus 3 separate 1-day events, at least to some extent. It seems if we allow non-unique event names, then there's no way to distinguish multi-day from multiple consecutive 1-day events. I guess the same exact thing goes for an appointment.

A subtlety here is that changing the instance date of a single recurrig item to the same date as another instance violates the uniqeness rule. It's nice that the uniqueness rule covers this case in a general way, but I think it is worth mentioning. Way better redundant than sorry.

2.11.7. Scheduling Dialogs and Item-Level Displays

Ed. Note: I think it would be quite good to summarize these requirements in tabular form, with one table for each class of dialog, with one table row for each data-entry field in the dialog.

The following data entry formats apply to any scheduling dialog or item-level display where the indicated field appears:

1. The Title and Location fields are free-form, one-line strings. If the text is longer than will fit in the provided data-entry area, then it will automatically scroll as the user types and can be repositioned using the normal text movement arrow keys or such other forms of horizontal scrolling as may be available on a particular implementation platform.
2. The value of the Location field can be selected from the pulldown list of available locations, as shown in Figure 326.
   
   

   ---

   Figure 326: List of available locations.

   ---

   
   The deal with this this is that it could get too long, in which case the location DB dialog should come up instead of a pulldown list. There needs to be a way to set the length value at which the listing changes from a pulldown to the separate dialog window. Also, the down-pointing arrow should change to somthing like a right-pointing arrow when this happens. And one more detail -- if a location is selected from the DB, then what should appear in the type-in text field is the of the form <Name>, <Number>, i.e., the comma+space-separated concatenation of the location name and number.
3. The (Start) Date and End Date are type-in fields, with checking for legal date syntax. The following are legal forms of date entry: ...

Ref to two appropriate figures for meeting request and confirmation dialogs.

The precise data-entry rules for the fields that appear in both the scheduling request and confirmation dialogs are as follows:

• Title can be entered in either the request or confirmation dialog; it must be entered before confirmation.
• Duration must be entered in the request dialog, where the system- supplied default is 1 hour; it cannot be edited in the confirmation dialog.
• Recurring is optional in the request dialog, where the system-supplied default is non-recurring; it cannot be edited in the confirmation dialog.
• Category can be entered in either the request or confirmation dialog; the default is no category.
• Security can be entered in either the request or confirmation dialog; the default is public.
• Location can be entered in the request dialog; the default is empty, which is an allowable value. Location may be edited in the confirmation dialog; if edited there, the system validates that the newly entered location is available at the meeting date. If it is not available, the system signals the condition with an error dialog as discussed in Section 2.12. If the location of the confirmed meeting is empty, it is the presumed responsibility of the scheduler to inform attendees of the meeting location via some means external to the Calendar Tool system.
• Remind is optional in the request dialog, where the system-supplied setting is not to remind. It can be edited in the confirmation dialog and is optional there as well.
• Attendees must be entered in the request dialog and cannot be edited in the confirmation dialog.
• Details can be entered in either the request or confirmation dialog; it is optional in both. There is no system-supplied default.
• Minutes can be entered in either the request or confirmation dialog; it is optional in both. There is no system-supplied default.

The precise data-entry rules for fields that appear only in the scheduling request dialog are as follows:

• Earliest Possible Date must be entered; the system-supplied default is today's date.
• Latest Possible Date must be entered; the system-supplied default is two weeks from today's date
• Earliest Start Time must be entered; the system-supplied default is the value of the normal beginning-of-day time, the default for which is 8 AM.
• Latest Start Time must be entered; the system-supplied default is the value of the normal end-of-day time, the default for which is 5 PM, minus the default value for the duration, which is 1 hour; this means the default latest start time is 4 PM.
• Earliest End Date must be entered for a recurring meeting; there is no system-supplied default.
• Latest End Date must be entered for a recurring meeting; there is no system-supplied default.

The precise data-entry rules for fields that appear only in the confirmation dialog are as follows:

• Start Date and Start Time can edited only to one of the value pairs that appears in the possibles list.
• End Date can edited only to an earlier date that is not before the start date.
• Scheduled By cannot be edited.

If the user specifies a recurring event without checking any box in the additional recurring information, the event will be set by default to recur weekly, on the day of the week that is specified for the start date of the event. [Sketch: some other defaults are made clear by default display of selection box.]

Also explain what the standard defaults are for the settings of all dialog fields and note that these default settings can be changed in the by editing preferences.

2.11.8. Required Fields

The discussion in the next paragraph needs to be more precise in specifying for which types of item which fields are required. In working on the custom lists section, I've been thinking about adding a table that there with an added third column indicating if the field value is required or optional. If this table is added here, it should probably be ref'd from the custom lists section instead of appearing directly there. The only question is that this complete table (with all three columns) is more that is need either in the custom lists section or here, but seems like a good thing that should appear somewhere. Perhaps it belongs in another place. Anyway, we'll figure it out eventually, if we live that long.

When scheduling or changing an item, the following fields are required to be non-empty and properly formated: Title, (Start) Date, Start Time, and Duration. If one or more of these fields is missing when the user presses the `OK' or `Change' button, the system responds with the error dialog shown in Figure 327.

23dec05 note: describe selecting multiple items with shift-click, including how multiple selections and span more than one window (if that's what we want), and reiterate how this applies to delete but not change.

20aug01 note: need to update this section to include target selection in list displays as well as calendar displays.

The first five commands in the `View' menu apply to a user-selected target in the calendar display, or to a default target. To select a viewing target, the user clicks on a desired location somewhere in the current display window. The "current display window" is defined precisely as the display window most recently generated by the system or the window most recently made current by the user having clicked on it or selecting it in the `View Windows' menu. The following are the specific details for how a viewing target is selected in the current display window:

For the `View Item' command, an item is selected as follows:

1. In a day, week, or month view, the user selects a scheduled item by clicking anywhere on the time range or title of the item.
2. An item cannot be selected in a year view, since no times or titles are displayed there.
3. If no item is explicitly selected by the user, the default is the first item, if any, scheduled on today's date. If there is no such item, then the `View Item' command has no effect. (The exact system response to commands with no effect is described in Section 2.17.41 on error conditions.)

For the `View Day' command, a day is selected as follows:

1. In a table- or list-style week view, the user selects a day by clicking on any of the day names that label the table columns, or on any item in a desired day.
2. In a list-style week view, a month view, or a year view, the user selects a day by clicking on the numeric date of any day, or on any item in a desired day.
3. If the current display window is a day view, the `View Day' command has no effect.
4. If no day is explicitly selected by the user, the default is today's date.

For the `View Week' command, a week is selected as follows:

1. In a day view, the selected week is the one that contains the currently displayed day.
2. In a month or year view, the user selects a week by clicking on the numeric date of any day within the desired week, or on any item in a day within the desired week.
3. If the current display window is a table-style week view, the `View Week Table' command has no effect; if the current display window is a list- style week view, the `View Week Lists' command has no effect.
4. If no week is explicitly selected by the user, the default is the week containing today's date.

For the `View Month' command, a month is selected as follows:

1. In a day or week view, the selected month is the one that contains the currently displayed day or week.
2. In a year view, the user selects a month by clicking on the name of any month or on the date of any day within the month.
3. If the current display window is a month view, the `View Month' command has no effect.
4. If no month is explicitly selected by the user, the default is the month containing today's date.

1. In a day, week, or month view, the selected year is the one that contains the currently displayed day, week, or month.
2. If the current display window is a year view, the `View Year' command has no effect.
3. If no year is explicitly selected by the user, the default is the year containing today's date.

In all of the cases where a name or numeric date is selected, the system confirms the selection by highlighting the name or date in reverse video. For example, Figure 328 shows how the system highlights the date of September 1 when the user clicks on that date number in the monthly display.

The system provides a three-way option to control the scheduling of items with overlapping times. The option settings are the following:

1. disallow overlapping times entirely
2. allow overlapping times, with warning
3. allow overlapping times, no warning

Explain/illustrate the Delete and Change category commands in the edit- categories dialog of Figure 8.

Explain what happens when a user selects the `Edit ...' item in the `Add Category' dialog. Here's a sketch:

1. A typical dialog naming/add/delete dialog comes up.
2. There's also some form of generic color chooser, e.g., RGB.
3. Deletion is prohibited if there exists any scheduled item with a category that is colored with the color to be deleted.

Dont forget to explain emacs-style reg expr search for the name lists that appear in the admin dialogs. An important detail is how the fuck the regular expression search is enacted, which is not at all clear from the discussion (actually mention) of it in the "other user" section. Presumably, it could work like emacs' incremental re search, but this needs to be clarified.

A really great motherfucking idea is to move re search to the future work section. I think I'll do it. (Good for you, motherfucker.)

OK, motherfucker, not motherfucking quite. RE search is pretty major part of filtering. So, what we can do to speed things the fuck up here is to cite some external source for the definition of regular expression, and be done with it. We do still need to explain moby re search in the admin dialogs, or eliminate it there, which would probably be just fine.

2.11.14. Regular Expression Filtering Patterns

While the soltice and time-change events may not strictly be considered "holidays", they are none-the-less included in the `holiday' category.

2.11.17. Dialog State Details

22aug02 NOTE: Given the clarification default options, things may be easier here than the 1st sentence of the ne paragraph suggests.

This is the section where we define all of the horendously boring details of what intial and historical states the various dialogs assume. Hopefully we can batch bunches of them together under a single heading. Anyway, I think it's pretty clear that such details are necessary, and I think this is the best place to put them. The motivation for this section having come into existence was slogging through the details of the custom list dialog states, and thinking how boring it was to have all of those details piled up there.

2.11.17.1. Custom List Dialog

Dialog state rules:

1. List Name text box: Initially, contains highlighted text "New List". There after, dialog remembers whatever name that was in the text box when the dialog window was most recently closed; in the case when the last defined list is deleted, the dialog reverts to the intial "New List" state.
2. Field check boxes: per Table 5
3. Start and end dates: initially the default, thereafter most-recently entered
4. Command buttons:
   Add enabled when any currently undefined list name appears in the list-name text box, including the system-supplied "New List" and an empty value.
   1. Change, Delete, and Apply enabled when any currently defined list name appears in list-name text box; Apply is also enabled when the user has done some editing to a not-yet-defined list that is yet to be confirmed with Add.

The following is a way-too-complex version of things, which might be useful at some point as a class/book example, but maybe is best just nuked.

Dialog state is simply that the

• Intially, `List Name' field contains "New List", highlighted.
• When Add is the most recently invoked dialog command, the most recently added list name appears in the List Name box, unhighlighted.
• When Change is the most recently invoked dialog command, the most recently changed list name appears in the List Name box, unhighlighted.
• When Apply is the most recently invoked dialog command, the most recently applied list name appears in the List Name box, unhighlighted.
• When Delete is the most recently invoked dialog command, the most recently added, changed or list name appears in the List Name box, unhighlighted.
• When Cancel is the most recently invoked dialog command of the first four, the most recently added list name appears in the List Name box, unhighlighted.
• Aborted here when noticed that things were getting way too complex.

A long text string is scrollable in the text box and truncated in the menu, based on how wide the menu otherwise is in the dialog.

This is originally from Section 2.3.3.6. and needs to be generalized here for all combo boxes:

When `specific date' is initially selected, the system clears the text box and the user types a specific date value into the text field. When `specific date' is subsequently selected, the system restores and highlights the most recently typed value. If any of the other menu entries is selected, typing is disabled in the text field.

Sketch: Form of default names is "New XXX", where XXX is the subject, e.g., "List", "Filter". Initially, we were going to say that "New XXX" form cannot be used to save a filter, but is only displayed as the high-lighted name when the user selects the `New' item in some name menu. Howerver, instead of this, I think we should say the following. "New XXX" is the initial default name. If the user uses it, so be it, becauuse "New XXX" will not appear again if and until all extant filters are deleted. Sweet.

2.11.20. Name Completion

Need to define precisely what "change" and "most recent" mean in terms of data field editing. It seems like we'll need to model this using time stamps for each meeting field. Here's an interesting scenario that we need to make sure is well understood and covered by our rules:

1. scheduler schedules
2. user changes non-critical field F
3. scheduler changes F, elects not to notify
4. scheduler changes some critical field, therefore notifies

Things work like Emacs, not as hairy-assed as they could by coninuous diffing. Viz., as soon as an edit is made, `Change' gets enabled and `Delete' disabled. If the edit is reversed by further editing, the system does not notice that there are effectively no changes, and hence leaves the buttons in the changes-made state. If the user proceeds with a confirmed change at this point, the system goes throught the motions, but the change has no effect on the data. This just like adding a char, deleteing it, then saving in Emacs -- the same data get saved back on the file.

I believe what this means from the formal perspective is that we dont want the precond on channge that says the two args must be different. If we do have this, then we either need to enforce it with diff-style change button enable/disable, or issue an error/warning when the change is confirmed. The latter seems pretty useless, given this seems to be a "no harm done" case if we let the nugatory change just happen.

2.11.24. Precise Details of Clear and Cancel

1aug02 -- OK, I'm thinking that the addtion of the "cleared" state, as alluded to below to be distinct from the "defaults" state, is probably overkill. I'm ready to go back in the appts-scheduling section to "... to their default states." from the recently updated "... to there cleared states", and deal with the meaning of `Clear' in the options dialog as a separate issue. Given that there are no option defaults, except in the standard Options file, and having `Clear' in the options dialog clear to the `Options file doesn't really make sense, given that the user can load that file if desired.

In addition, the idea that `Clear' can have the same conceptual meaning in all dialogs is I think wrong, given that it needs to mean "clear to defaults" in a first-time input (aka, create) dialog, versus "clear to state preceding any unsaved changes" in a second-and-beyond-time edit (aka, edit) dialog. And to deal with things consistently in this regard, we can consider the options dialog to be an edit not create dialog.

And to be fully precise, we should here, or perhaps elsewhere, specifically enumertate which dialogs are create and which are edit. You go, boy.

Finally for today, it's just occured to me (per the rename of this section from "... the Clear Command" to "... Clear and Cancel"), that we need to include here a precise general definition for the meaning of `Cancel', viz., that unless stated explicitly to the contrary, `Cancel' always implies clear, and maybe we don't even need the "unless ... to the contrary" part.

OLD and I think invalid stuff starts here.

Need to define "cleared" state for each form of widget, noting (as is done just below) that "cleared" is not equal to "default".

The `Cear' button behaves uniformly the same in all dialogs that contain it, by clearing all text-entry fields and setting other fields to there unset (not default) states. Note that even when the `defaults' selection is made for `Initial Values', and some fields have non-empty defaults, those non-empty values are not set when the clear button is pressed.

But wait -- this may not be the right way for `Clear' in the options dialog. We need to think about this, and make sure that whatever we say about `Clear' in the options section is consistent with what we say here.

For simplicity, there's no explicit `Defaults' button in any data- entry dialog except for the the tabbed `Options' dialog. This means there's no direct means to restore default settings to a dialog. This can be accomplished explicitly as follows: (1) set `X.Defaults.Initial Values' to `as specifed in default option settings'; (2) close and re-open the dialog. The `Edit.Undo' command can also be used to undo the effect of `Clear', but that may not lead directly to the restoration of default values.

2.11.25. Add User and User Record Dialogs

I'm thinking that validation failure of the user's local computer information should probably not result in a fatal error, since an admin may adding or editing a user record when the user's host computer is down. So, the cal tool admin system will perform the validation, report the results, but not prevent the We might have the cal tool be out of the business of validating local computer user information altogether. What we can say is that it's up to the admin to use some external means to perform validation. However, this seems harsh.

Some fodder originally from admin section:

If communication cannot be established with the selecte host, the first line is changed to

Communication cannot be established with the selected host computer.

The selected host computer is not currently running a Calendar Tool server.

The selected Calendar Tool file <file name> is not readable.
The selected Calendar Tool file <file name> does not exist.
The selected Calendar Tool file <file name> is not valid.

Put this here, or probably someplace else, but the bottom line is the "pixel" must be defined as "the atomic unit of screen-size measure for a particular display". This is the measure used by the underlying operating environment to describe screen measurements, as in the screen size is 1024 x 768 "pixels".

2.11.27. Options Data

Hopefully in most cases, details have been covered in other dialogs to which otions apply. I believe the following are specific to options:

1. In scheduling meetings: the left and right screen positions are in pixels and must be between 0 and the max dimensions of the screen.

Unless stated explicilty to the contrary, all preceding refereneces to "alphabetic order" mean case insesnitive order based on the lexical colating sequence in use on a particular operating environment. Typical lexical collating sequences are ASCII and UNICODE.

2.11.29. Dialog Memory

• Specified as options for scheduling dialogs.
• As most recently closed for (I think all) others; should proably itemize these, with the following having come particularly to mind:
  • the file dialogs, which should remember the last path they were on; at startup they should always go to the user dir
  • major edit dialogs, which presumably come up the last way the looked when closed during the current session, and some other reasonable defatul way after start up; this reasonable default is most likely just the way the appear in their first figure in the scenarios
  • need to make a decision about the little detail of whether dialogs remember when ever closed, or only when closed with confirmation (`OK'), but not with `Cancel'; the idea here would be that if they're closed with `Cancel', they'll remember the last time they were closed with `OK', or the last time they were opened, whichever occurred most recently.

2.11.31. Unbounded Limits on Calendar Size and Numbers

2.11.32. Calendar Specificity and Modality of Dialog Windows

One way or another, include unprocessed meeting notifications in the category of pending edits. The term "pending edit" is used explicitly in the file section for the close (and exit) commands. The def there is this

A pending edit is any unconfirmed or unapplied change the user has made in one or more of these dialogs.

Here's a tad of fodder about reviewing unprocessed notifications that may require an explicit dialog of its own, but I think and hope the fuck not, instead piggy backing on the existing way that notifications are reviewed in the meetings section, and doin the thing about the system proceeding without further confirmation, answering affirmatively on the users behalf everywhere.

Here are non-model editing dialogs that are calendar-specific, one-per- calendar:

1. all four scheduling dialogs
2. category editing dialog
3. custom lists editing dialog
4. custom filters dialog
5. options dialog

Here are non-modal selecting dialogs that are calendar-specific, one-per- session:

1. find -- if calendar changes, the find happens in it
2. goto date -- if calendar changes, the goto happens in it

Here are non-modal viewing dialogs that are calendar-specific:

1. view other user dialog
2. view group dialog

1. host connection table -- lines in the table are calendar-specific, but the overall table applies to the entire session
2. all three database viewing dialogs
3. contact admin -- dialog is self-contained in that it contains the host address to contact

Here are the modal dialogs, all are calendar-specific:

1. everything in the file menu -- cal-specificity of save/load settings is that saving save those of current cal, loading loads into currennt cal
2. admin->password dialog

OK, here's a semi-epiphany -- get rid of the Save button altogehter, but retain Save-As. The rationale is to have all non-scheduled-item data handled uniformly. Viz., we have the following calendar-specific non- scheduled-item data:

1. categories
2. custom lists
3. custom filters
4. options
5. host(s) -- 9jul94: I think this needs to go as cal-specific data, since we'll have the connection table save it; a problem with having it cal-specific is that their could be confusion with connection table, e.g., the connection table might well be expected to grow and shrink as cals are opened and closed; also, it seems cleaner to have host association be independent of the cal itself, since hosts may come and go, and we can have the connection table be the place where this is dealt with, rather than having a potentially obsolete host in a(n old) cal.

1. Apply
2. Save As ...
3. Load ...

There are unsaved {category, custom list, custom filter, option} changes ...

Extracted from gui-details section:
If more than one calendar is open, only the current calendar is affected by `Apply'. If no calendar is open, then the `Apply' button is disabled.

Extracted from gui-details section:
Make sure the effect of window closing is 100% defined. Hopefully close === Cancel works most or all of the time.

Unless otherwise noted in the scenarios, all dialogs are non-modal. It would be prudent here to list exactly the (hopefully few) cases where modal behavior is enforced. We should also discuss what happens when would-be modal dialogs are closed, viz., and not necessisarily limited to, reminders and meeting notifications. Another interesting case is when the same user executes two or more `Schedule Meeting' operations while an original such operations is in the synchro stage. It seems clear that this should mean that the user is put in the queue behind himself (!).

I'm thinking that --maybe-- modal dialogs should never appear in the windows list, hence we don't need to mention window modality when we discuss the `View Windows Close' command, as we don't currently do. We do need to address the issue that any "pending" activities are canceled with a window is closed.

Somewhere we need to address what it means for the system to interrrupt a modal dialog, particularly with the proceed-to-schedule notification. In this case, I'm pretty sure that it should mean the modal dialog is canceled, which means we have to be careful to put a cancel button in all modal dialogs.

Extracted from window-viewing section:

I think the following paragraph is way too confusing and potentially error prone. Better is to have all calendar-specific data-entry dialogs apply to the calendar that is current when the dialog is originally opened. Now, this may well mean that when more than one calendar is open, all calendar-specific windows are unconditionally (i.e., not optionally not) labeled with the name of the calendar to which they apply. Also, we may want to allow more than one data-entry dialog for each type of command, for each calendar. The possibilities in this regard are the following:

1. one dialog total for each (calendar-specific) data-entry command, and the dialog applies to one of these:
   1. the current calendar
   2. the calendar that was current when the dialog command was originally executed
2. one dialog for each different calendar for each (calendar-specific) data-entry command, the dialog therefore applying to its particular calendar
3. multiple dialogs for each and every execution of each (calendar-specific) data- entry command, the dialog therefore applying to the calendar that is current when its command is executed

1. one dialog total for each (calendar-specific) data-entry command:
   1. pros: avoids window proliferation, of which there is potential for much already
   2. cons: For the the current calendar, this requires that dialog contents change when cur calendar changes, including the notion of a "pending" operation for a particular calendar so that dialog contents can be intelligently updated between calendars. For the calendar that was current when the dialog command was originally executed, this makes it potentially confusing as to which calendar dialog applies to and potentially inconvenient to change scheduling focus between calendars.
2. one dialog for each different calendar
   1. pros: avoids cons of one-total approach
   2. cons: window proliferation and still some potential confusion if user doesn't pay (close) attention to changing window banners
3. multiple dialogs for each and every execution
   1. pros: consistent with multi-window mode and an overall "the more windows the merrier" philosophy
   2. cons: even more potential window proliferation and multi-window confusion

OLDER STUFF:
All data-entry dialog windows are non-modal, calendar-specific, and unique. "Non-modal" means ... . "Calendar-specific" means that when the operation of a data-entry dialog is confirmed with `OK', the operation applies to the current calendar. "Unique" means that exactly zero or one data-entry dialog of each for data-entry command. [Enum all data-entry commands explicitly.] For example, suppose a user has three calendars open, named "A" and "B", and "C". With calendar A current, the user executes the `Schedule Appointment' command, enters some values in the appointment scheduling dialog, but does not press `OK'. The user then makes calendar B active, executes a view command for it, and then re-executes the `Schedule Appointment' command. At this point, the system does not display a new appointment scheduling dialog, but moves the previously-displayed dialog to the front of all windows. That dialog contains the values most- recently entered by the user. If the user were to press `OK' in the appointment scheduling dialog at this point, the appointment would be scheduled on calendar B, even though the values were entered in the dialog when calendar A was active. In this scenario, assmume that the user proceeds to make calendar C current and executes one or more viewing commands for calendar C. The user then makes the appointment scheduling dialog current by selecting its window name in the `View Windows' menu. Since there is at most one appointment scheduling dialog active at any time, selecting its name in the `View Windows' menu has exactly the same effect as re-executing the `Schedule Appointments' command, viz., the appointments scheduling dialog is made active. The user now proceeds to enter additional information in the appointments scheduling dialog and presses `OK'. If the entered information is error free, the system schedules the appointment on calendar C.

NOTE that the windowing mode is calendar-specific, meaning that each open calendar must have at least one open view window.

More details on window closing. Since scheduling dialogs are non- modal, the user could do this: Open a calendar, execute a schedule command, close all calendar view windows, then confirm the scheduling command. But hey, this ain't a problem, given that confirming (with `OK') does not close the scheduling, so it'll just stay open as the only window. It looks like we're OK here, given that all of the editing dialogs stay up until the user presses cancel (which closes) or closes explicitly. And it's at that point (i.e., close/cancel) that the following dialog comes up (before the close takes place):

This is the last open window for the calendar "name".
Closing this window will close the calendar.

• close-calendar-on-last-window-close dialog appears
• user presses `Yes' (or `OK') to proceed with calendar close
• if there are no unsaved changes, system closes window and calendar, with appropriate updates to windows and calendars lists
• if there are unsaved changes, system leaves original window up but removes close-calendar-on-last-window-close dialog, then displaying the offer-to save dialog
• if user presses `Cancel' in offer-to-save dialog (or subsequent file-saving dialog), original window and calendar remain open stay up
• if user proceeds to completion of offer-to-save, system closes original window and calendar

NOTE: Fodder from options section follows.

NOTE: Rewrite all of the introduction to get rid of the long-winded calendar-specific biznis, moving it instead to the end, in the same that it's presented at or near the end of the categories, custom lists, and custom filter sections. Ditto for the revised Save-As and Load semantics. The deal there is that when the user switches calendars, the current options remains unchanged, but it does not belong to the current calendar.

... If more than one calendar is open, only the current calendar is affected by `Apply'. If no calendar is open, then the `Apply' button is disabled.

NOTE: The following paragraph needs to be updated per the most recent banner policy, which is controlled by options.
Since options are calendar-specific, the banner of the options dialog indicates which options settings are currently active, and therefore displayed in the options dialog. In Figure XXX, for example, the options are those for the CommunityCalendar file. When the user changes the current calendar while the options dialog remains on the screen, the banner and contents of the dialog are changed to reflect the options for the newly current calendar. When no calendar file is open, the options dialog banner is "Options for new calendars", meaning that the option dialog is operating on the settings in the standard `Options' file.

Each and every calendar file has a separate copy of option settings. This allows users to define different options for different calendars, as desired. When more than one calendar is open, the active option settings are those of the current calendar. If there is no open calendar, then the active options are those defined in the standard options file named "Options". This file is stored in the user's Calendar Tool directory, as described in Section The contents of the Options file are used as the default for all new calendars. Whenever a new calendar is created, the contents of the Options file are copied into the new calendar as the initial settings for all options.