Window Persistence

From UW Center for Collaborative Technologies Wiki
Jump to: navigation, search

Window Location and Size Persistence

Users frequently conference with the same set of participants. At the beginning of each conference the user will size and position each window based on camera positions, available display space, relative importance of remote participants and other factors. Frequently users would like to have window size and location persisted between invocations. Following is a proposed design for window persistence.

A new menu entry will be added to the 'Actions' menu with text 'Persist Window Locations'. This entry will have a check to show whether it is enabled or disabled. The persistence information will be acquired when a window is disposed, whether due to local node leaving the venue, or remote node leaving the venue. This persistence information will be acquired only if the 'Persist Window Locations' menu item is checked, and if the window has been manually moved or resized by the user since it was created.

The information to be stored consists of the following:

  • Participant name and capability identifier (capability.Name)
  • Window location: coordinates of the upper left corner
  • Window size: height and width.

When the application is started, a hashtable is created, and populated with previously persisted entries. Initially the capability.Name will be the key to the hashtable. When the application is terminated, the existing hashtable is written back to the storage location.

When a new window is created, if the persistence menu entry is checked, the softare will look in the hashtable for the capability Name, and if an entry is found, it will check the size and location information for consistency with existing display configuration (to prevent placement of windows off-screen). If all looks good, we will use the persisted size and location to place the window. If the persistence menu entry is unchecked we will continue to operate as we currently do, using tiled or 4x window placement.

We will format the data for storage using the XML Serializer. The benefits of this approach are ease of use and transparency to the user. The most appropriate storage method is probably .Net Isolated Storage. This will cause the persisted data to be stored under "Application Data". This is consistent with our preference that the data be stored per-user.