When the user selects the `Windows ->' command in the `View' menu, the system displays a submenu of the form shown in Figure 69.

The windows are listed by the strings that appear in the window banners. When the banner is longer than the default menu width, the " ..." suffix is added. The window listed as "Calendar Tool" is the command menubar. It is listed explicitly because it is a physically separate window, however it always appears at the bottom of the list since it is never considered current for the purposes of window selection and closing.

To make any window current, the user selects its name in the `Windows' menu. In response, the system performs the following actions:

1. deiconifies the window if necessary;

2. moves the window to the front on the screen, so it is in front all other windows;

3. moves the window's title to the top of the windows menu list, unless the selected window is the command menubar;

4. defines the calendar associated with the selected window as current, per the rules below for calendar currency, unless the selected window is the command menubar.

Immediately below the window list is the `Close' window command. When the user selects this command, the system removes the current window from the screen and removes its name from the windows list. If there is a pending action in the window being closed, the action is canceled without warning. For example, if the window being closed is a scheduling dialog in which the user has made unconfirmed edits, closing the dialog window cancels all edits and does not perform any scheduling operation. In this way, closing a window has exactly the same effect as pressing the `Cancel' button in any window that has a `Cancel' button. In editing windows without a `Cancel' button, such as item-level displays, closing the window cancels any unconfirmed edits, such that the next time that item-level display appears, any previously unconfirmed edits have been lost. After the current window is closed, the next window in the list becomes current. Any window except the command menubar can be closed with the `Close' menu command.

The action performed by the `Close' command is different from the action typically referred to as "iconify" or "minimize" in window-based operating environments. The iconify action does not completely remove a window, but rather reduces it to an iconic form that can be re-opened. In contrast, the close operation fully removes a window from the screen, leaving no icon or minimized item of any form. An underlying operating environment may provide both iconify and close operations. If it provides close, the Calendar Tool detects closure of one of its windows, removes the name of the closed window from the windows list and makes the next window on the list current.

In operating environments that provide an iconify or minimize operation, the effect of this operation in the Calendar tool is to change the window title in the `Windows' menu to greyed italic type. The position of an iconified window does not change in the list, but it cannot be the current window. Therefore, if current window is iconified, its name is greyed in the list, and the current window becomes the first in the list that is not iconified. For example, Figure 70 shows the state of the `Windows' menu in Figure 69 after the top two windows have been iconified, the `Scheduled Appointment' window has been iconified, and the list windows have been closed.

As noted above, the command menubar window cannot be closed using the Calendar Tool `Close' command. If the operating environment provides a means to close a window, closing the menubar window has the same effect as executing the `File Exit' command, described in Section 2.8.7.

When the user closes the last active window for a calendar, the system executes the `File Close' command for that calendar, as described in Section 2.8.3.

2.3.6.2. Windowing Mode

As introduced in earlier scenarios, the user may choose from three different windowing modes. To do so, the user selects the `Windowing Mode' command, in response to which the system displays the submenu shown in Figure 71.

The default windowing mode is `Per-Level'. The windows list in Figure 69 reflects the state of windows based on per-level mode having been active during the scenarios presented to that point. In per-level mode, there are up to eleven separate viewing windows active on the screen. Table 7 describes each of these windows.

For item views, the item-type is one of "Appointment", "Meeting", "Task", or "Event". For week views, the results of `View Week Table' and `View Week Lists', go in the same window. For custom lists, the custom list name is the name of one of the custom lists defined by the user.

When one of the eleven mode-affected view commands is executed in per-level mode, the system performs the following display actions:

1. If there is no window currently displayed for that command, one is created and displayed on the screen.

2. If there is an existing window for that command, the contents of the window are updated to reflect the results of the latest command execution and the window is moved to the front of all other windows on the screen.

The `View Next' and `View Previous' commands never create a new window in per-level mode. This is because these two commands must be executed in the context of an existing display. Therefore, `View Next' and `View Previous' always change the current display when executed in per-level mode.

The `View Goto Date' command updates an existing applicable window if one exists. Otherwise it creates a new window at the default viewing level. Further operational details of `View Goto Date' are given in Section 2.3.2.3.

In some cases, the size of an existing window may change when a command is executed in per-level mode. For example, at the item-level of viewing, the size of an appointment display is larger than an event display. In such cases, the window is positioned so that its upper left corner stays in the same screen location.

2.3.6.2.2. Two-Window Mode

In two-window mode, a single window is used to display all calendar viewing commands; another single window is used to display all list commands. Hence there up to two active display windows in two-window mode. The calendar viewing commands are the first five in the `View' menu, and the first five listed in Table 7. The list viewing commands are those in the `View Lists' submenu, and the last six listed in Table 7.

When the user selects two-window mode, the mode transition does not itself change the state of the screen. Rather, the transition establishes how windows are displayed subsequently. Hence, the transition to two-window mode from per- level or multi-window modes does not remove any windows from the screen.

When one of the five calendar view commands is executed in two-window mode, the system performs the following actions:

1. If there is no calendar view window currently displayed, one is created and displayed on the screen.

2. If there is an existing calendar view window, the contents of the window are updated to reflect the results of the latest command execution and the window is moved to the front of all other windows on the screen.

Three or more windows can be displayed while in two-window mode, but only two of them are actively used for command display. If the user changes the active calendar window while in two-window mode, the newly current window becomes that in which all subsequent single-window calendar display occurs. The same applies to a change in the current list view window.

The size of an existing window may frequently change when a command is executed in two-window mode. In such cases, the window is positioned so that its upper left corner stays in the same screen location.

2.3.6.2.3. Multi-Window Mode

In multi-window mode, a separate window is used for each and every execution of a mode-affected view command, even for commands at the same calendar level and for list commands of the same type. The purpose of multi-window mode is to allow the user to create side-by-side displays of consecutive calendar periods, or other useful combinations of multi-window information. For example, Figure 73 shows a side-by-side three-month display, which the user creates by performing the following actions:

1. execute the `View Windowing Mode Multi-Window' command

2. execute `View Month' for the month of September 1998

3. execute `View Previous' and `View Next' from the September display

4. resize the monthly agenda windows to smaller sizes and move them next to each other on the screen

In multi-window mode, or when multiple calendars are open, it is possible for multiple windows to have exactly the same banner string. For example, Figure 73 shows three windows with the same banner. When this occurs, the window banners are not disambiguated in any way. This means that when the windows are listed in the `View Windows' submenu, their names are identical.

2.3.6.2.4. Windowing Mode Calendar Specificity

The windowing mode is calendar-specific. That is, each calendar has its own windowing mode setting. When more than one calendar is open, the windowing mode shown in the `Windowing Mode' menu is that for the current calendar and applies only to the current calendar. In per-level and two-window modes, the maximum number of displayed windows is computed on a per-calendar basis. For example, if three calendars are open and two-window mode is on for all three, then up to six windows can be displayed -- two windows for each calendar.

2.3.6.3. Magnetizing Windows

The window magnetizing feature of the Calendar Tool helps the user manage multi-window displays. When a window is magnetized, it "sticks to" other windows when it is moved in close proximity to them. "Close proximity" is defined by default as four screen pixels, where a pixel is the smallest granularity of screen measurement available on a particular physical display. The user can change this value with an option command, as described in Section 2.7.4.2.

To magnetize any window, the user selects that window and then chooses the `Magnetize' command in the `View Windows' submenu. In response, the system turns on the magnetic property of the window. The magnetizing command acts as an on/off toggle, switching between the states `Magnetize' and `Demagnetize'. The state of the command label reflects the magnetized state of the current window. Specifically, if the current window is not magnetized, then the command label is `Magnetize'. If the current window is magnetized, then the command label is `Demagnetize'.

When the user moves the side of a magnetized window in close proximity to the side of another window, the two sides are snapped into alignment and the windows become magnetically connected. The magnetic effect between two windows is the same if either or both are magnetized. Hence, moving an unmagnetized window in proximity to a magnetized one, or vice versa, has the same effect.

When two or more windows are magnetically connected, moving any one of the windows moves all connected windows along with it, so that the relative positions of the windows is maintained. A magnetized window can be moved independently by holding down the shift key while moving, which temporarily demagnetizes the window during the move. A window can be be moved independently without the shift key whenever it is demagnetized and not connected to any other magnetized windows.

Figures 74 through 80 illustrate the series of actions taken by the user to produce the side-by-side display in Figure 73.

In Figure 77 the user moves the August window up while holding down the shift key, so that the top of the August window is in close proximity to the top of the September window. If the user did not use the shift key during the move, both the August and September windows would move together, since they are now magnetically attached. During the August move, the system maintains the left-to-right alignment of the two windows as long as the user does not move the mouse more than four pixels to the left or right from its initial left-to-right position at the time the move began. In response to the upward movement of the August window, the system snaps the top of the August window into alignment with the top of the September window, as show in Figure 78.

To complete the side-by-side configuration, the user moves the connected August/September window pair so its top and right sides are in close proximity to the top and left sides of the October window, respectively, as shown in Figure 79. During this move, the user does not hold down the shift key so that the window pair moves together. This can be accomplished by moving either of the two connected windows; the other window remains connected during the move. In response to this final move, the system snaps the August/September pair into both top and left-to-right alignment with the October window, as shown in Figure 80

Magnetic connection is only made between the outside edges of windows, not with inside edges. This means that magnetically connected windows never overlap with each other, although they can overlap with other unconnected windows. When the side of a moving window comes into proximity with the side of an overlapping window such that the outside edges can be connected without overlap, the system snaps the windows into alignment. This case is illustrated in Figure 75 above.

In total, there are six possible types of window alignment, as described in Table 8.

The top-to-bottom alignment type is considered the same as what could be called bottom-to-top alignment. Similarly, left-to-right alignment is considered the same as right-to-left alignment.

The magnetic connection between two windows takes effect as soon as the windows are in close proximity. This means that the system snaps the moving window up to the proximate window as soon and as long as the two windows are in close proximity, including while the user continues to move the original moving window. Movement is considered to be continuing until the user performs whatever environment-specific action is required to discontinue a move, such as releasing a mouse button. At that point, the windows are connected, so that they move together on all subsequent moves that are not augmented with the shift key or until all connected windows are demagnetized.

When the magnetic effect is initially established, the moving window continues to move independently until the user discontinues the move. As long as the user does not move out of proximity with the snapped-to window, the moving window stays aligned along the axis of connection. This is the same form of alignment-constrained movement as when the user employs the shift key while moving a magnetically-connected window, as illustrated in Figure 77. With a left-to-right connection, alignment-constrained movement in the vertical directions occurs freely, but there is "resistance" to horizontal movement. That is, when the user moves the mouse horizontally, the window itself does not move until the distance moved by the mouse is greater than the proximity distance. With top-to-bottom alignment, the same form of free and resisted movement occurs, but in the horizontal and vertical directions, respectively.

If the user moves a magnetized window in close proximity to the aligned sides of two or more other windows, all windows become magnetically connected. If the user moves a magnetized window in close proximity to the unaligned sides of two or more windows, the system establishes the magnetic connection with only the closest proximate window. As explained above, a moving window stays connected with a proximate window until the moving window goes out of proximity. Given this, the magnetic effect that would normally occur between two windows may not take effect if the sides of two or more windows are out of alignment by less than the proximity distance. Figure 81 illustrates such a case, assuming that the default values for proximity distance and magnetic spacing are in effect, which are four pixels and one pixel respectively.

Connected windows are treated separately for the purposes of current window selection. That is, when the user selects one window of a connected set of windows, the selected window alone becomes current, and that window alone is the one to which the `Magnetize'/`Demagnetize' command applies. Hence, the `Magnetize'/`Demagnetize' command affects exactly one window per execution. If the current window on the screen is not a calendar or list display window, e.g., it is a scheduling dialog, then the `Magnetize'/`Demagnetize' command is disabled. In order for a window to be moved independently without using the shift key, it and all windows to which it is magnetically connected must be demagnetized.

Magnetization is not transfered from one window to another via magnetic connection. For example, suppose in Figure 79 that only the August window is magnetized, with the September and October windows not magnetized. In this case, the system would not perform the magnetic attachment to produce the Figure 80 configuration. This is because neither the September nor October windows is magnetized, and the magnetization of the August window is not transfered to the September window. If the user moved the August window into close proximity of the October window, the system would connect the windows, since only one of a window pair need be magnetized for the connection to be made.

2.3.6.4. The Calendars List

Zero or more calendars can be open in a given Calendar Tool session. The names of open calendars are displayed using the `Calendars ->' item at the bottom of the `View' menu. When the user selects this item, the system displays a submenu of the form shown in Figure 82.

If a calendar has unsaved changes, its name in the calendars list is marked with a boldface asterisk character. The precise definition of unsaved changes is given in Section 2.8.4 The calendars of other users and groups are shown in grey italic type.

When a calendar has been saved to a file, the calendar name is synonymous with its root file name, where "root" is the file name without any leading file path and without any file extension. If a calendar has not yet been saved to a file, its name is "unnamed". If more than one calendar of the same name is open, then the names of the second calendar and beyond are suffixed with [i], for i equal 2 to the number of calendars with that same name. Two or more calendars can have the same name if they have the same root name in different file directories, the same root name with different extensions, or if they are an "unnamed" calendar.

Other-user and group calendars cannot be saved to a file. Therefore, the names of these calendars consist of the keyword "user" or "group", followed by the name of the user or group who owns the calendar. Other-user and group calendars are not editable, therefore their names are never shown with an asterisk in the Calendars list.

The user can change the current calendar by selecting its name in the list. In response, the system performs the following actions:

1. defines the selected calendar as current for the purposes of all subsequent Calendar Tool operations that reference the current calendar;

2. moves the calendar's name to the top of the `Calendars' menu list

3. makes current the most recently active window of the selected calendar, per the above rules for window currency

4. updates the currently defined categories to be those of the selected calendar (see Section 2.5.5 for explanation of calendar-specific categories)

5. updates the custom lists menu to reflect the custom lists defined for the selected calendar (see Section 2.3.3.6 for explanation of the custom lists menu)

6. updates the custom filters menu to reflect the custom filters defined for the selected calendar (see Section 2.3.4.2 for explanation of the custom filters menu)

7. updates the windowing mode setting to that of the selected calendar (see Section 2.3.6.2.4 )

8. updates the current host to be that of the current calendar, if any (see Section 2.6.6.1 for explanation of calendar-to-host association)

9. updates the banners of all windows that contain the name of the current calendar (see Sections 2.3.6.5 and Section 2.7.4.2 for explanation of window banner contents and viewing options related to showing the current calendar in window banners)

An other-user or group calendar can be current but is not editable. When an other-user or group calendar is current, all calendar modification commands are disabled. Section covers details of command enabling and disabling.

The association between a calendar and its windows is based the commands that display the windows and the order in which the commands are executed. From the time the Calendar Tool is initially invoked, calendar-to-window association is established as follows:

1. Zero or more initial view windows are displayed for a calendar when the user executes one of the following commands: `File->New', `File->Open', `View Other User,' or `View Group'. The calendar created or opened by these commands becomes the current calendar; all windows displayed as a result of these commands are associated with the created or opened calendar.

2. While a calendar remains current, all windows created as a result of non- administrative command execution are associated with that calendar.

3. When the user creates, opens, or makes current another calendar, all subsequent non-administrative windows are associated with that calendar.

4. The current calendar remains so until the user executes a `New', `Open', `Other User', `or Group' command, or until the user makes current a different calendar by selecting one of its windows or selecting its name in the `Calendars' menu.

At all times, the name of the current calendar is displayed in the banner of the command menubar and is listed at the top of the `Calendars' menu. The calendar name may also appear in other window banners, depending on the setting of the window-viewing options described in Section 2.7.4.2.

2.3.6.5. Window Banner Syntax

As described throughout the functional requirements, the banners of Calendar Tool windows contain text that is appropriate to the window contents. The banner of the command menubar window has a format that is distinct from all other windows. For the Calendar Tool regular user interface, the menubar banner format is the following:

Calendar: calendar name [ , Host: host name ] [, filtering ]

The following is the banner format for all Calendar Tool windows except the menubar:

content description [ , filtering ] [ , calendar name ]

For the Calendar Tool Administration program, the menubar banner format is the following:

Calendar Tool Administration: host name