2.3.6. Viewing in Different Windows

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


Figure 69: Windows submenu with chronological list of active windows.



The top segment of the menu is a list of all active windows currently displayed on the screen. The contents of the menu in Figure 69 represent the windows as they have been displayed in the requirements scenarios up to this point. The order of the windows is chronological, from the most current to least the current. "Most current" is the window most recently made current by the user selecting it or by the system displaying it. "Least current" is the window least recently made current or displayed.

The windows are listed by the title strings that appear in the window banners. When the title is longer than the default menu width, the " ..." suffix is added. The window titled "Calendar Tool" is the command menubar. It is listed explicitly since it is indeed a physically separate window.

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

  1. moves the selected window to the front on the screen, so it is in front all other windows;
  2. defines the window as current;
  3. moves the window's title to the top of the windows menu list.
The same actions are performed when the user physically selects a window through the normal means of the underlying operating environment, such as clicking on its banner, border, or body.

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. After the current window is closed, the next window in the list becomes current. Any window except the command menubar can be closed.

The action perfomred 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 contast, the close operation fully removes a window from the screen, leaving no icon of any form. An underlying operating environment may provide both iconify and close opertions. 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.

2.3.6.1. 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 70.


Figure 70: Windowing mode submenu.



The windowing mode determines how the system displays the results of certain commands in the `View' menu. Specifically, Figure 71 shows precisely which commands are affected by the windowing mode setting.


Figure 71: Commands affected by the setting of Windowing Mode.



The commands are those that display items in calendar and list format.

2.3.6.1.1. Per-Level Windowing Mode

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 this point.

In per-level mode, there are up to eleven separate viewing windows active on the screen. Table 7 describes each of these windows.



Window Title Command Results Displayed
"Scheduled item-type" View Item
"Daily Agenda" View Day
"Weekly Agenda" View Week
"Monthly Agenda" View Month
"Yearly Calendar" View Year
"Appointments, sorted by ..." View Lists Appointments
"Meetings, sorted by ..." View Lists Meetings
"Tasks, sorted by ..." View Lists Tasks
"Events, sorted by ..." View Lists Events
"All Items, sorted by ..." View Lists All Items
custom list name View Lists Custom custom list name

Table 7: Windows used in per-level windowing mode.



At the item level, the item-type in the title is one of "Appointment", "Meeting", "Task", or "Event". At the week level, the results of the two styles of `View Week', i.e., `Table' or `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.1.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 will be 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.
The same two actions apply to the six list viewing commands and the single list-viewing window.

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.1.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 72 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 a smaller sizes and move them next to each other on the screen



Figure 72: Side-by-side three-month display.



2.3.6.2. 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. The user can change this value with an option command, as described in Section 2.7.3.

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 73 through 79 illustrate the series actions taken by the user to produce the side-by-side display in Figure 72.


Figure 73: Initial unaligned positions of three magnetized windows.






Figure 74: User moves right side of August window near left side of September window.






Figure 75: System snaps windows into left-to-right alignment.






Figure 76: Holding shift key, user moves top of August window near top of September window.






Figure 77: System snaps windows into top alignment.






Figure 78: Without shift key, user moves top and right of August/September window pair near top and right of October window.






Figure 79: System snaps windows into top and left-to-right alignment.



Figure 73 is the initial state of the three windows as created by the `View Month', `View Previous', and `View Next' commands. The windows are positioned per an assumed policy of the underlying operating environment, which in this case positions new windows down and to the right relative to earlier windows. In Figure 73, the user has set the magnetize property on for all three windows. In Figure 74, the user moves the August window so its right side is in close proximity to the left side of the September window. In response, the system snaps the August window into left-to-right alignment with the September window, as shown in Figure 75. The default left-to-right spacing is one screen pixel, which value can be changed with an option command. Whenever the system snaps windows into alignment, the window being moved by the user is that which changes position. The position of the other window, that is the one the user is not moving, remains fixed.

In Figure 76 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 77.

To complete the side-by-side window 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 ( Figure 78 ). 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 79

Magnetic connection is only made between windows that do not overlap. That is, magnetic connection is only made between the outside edges of windows. The magnetic connection effect is disabled between two windows whenever any part of the windows overlaps. In total, there are six possible types of window alignment, as described in Table 8.



Type of Alignment Description
top The top sides of two windows are at the same vertical position on the screen.
bottom The bottom sides of two windows are at the same vertical position on the screen.
left The left sides of two windows are at the same horizontal position on the screen.
right The right sides of two windows are at the same horizontal position on the screen.
top-to-bottom The top side of one window is one pixel below the bottom side of the other window.
left-to-right The left side of one window is one pixel to the right of the right side of the other window.

Table 8: Types of alignment between windows.



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. When the magnetic effect is initially established, the moving window continues to move independently until the user discontinues the move. At that point, the windows are connected, such that they will move together on all subsequent moves that are not augmented with the shift key or until all connected windows are demagnetized. 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.

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, 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 78 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 79 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.




Prev: viewing-other-users | Next: [none] | Up: viewing | Top: index