The software architecture of Elastic Windows supports extensibility by its object-oriented design. Windows are modeled as views on objects of various types such as text, URL, e-mail, etc. By inheriting any of the object classes it is possible to extend Elastic Windows for a variety of applications. In this design, desktop and window hierarchies are also modeled as objects that can be saved, viewed and manipulated. The architecture provides a clean separation of the window handling components from the content handling components, making the Elastic Windows easily adopted for different applications.
The software architecture of Elastic Windows consists of the following five main components (Figure ):
The desktop, as the main processing component, handles event propagation and display update. It has also direct access to the window hierarchy cache to support display module and event propagation. Besides, this component also drives the desktop menu operations by making the appropriate calls.
The window handler component receives events from the desktop. It either propagates them to the content handler for processing or handles them by itself for window widget events such as window border drag, menu selection events, etc. The window handler also deals with drawing of window decorations such as window borders and widgets. Window menu operations are also handled by this component.
The content handler upon receiving events from the window handler takes appropriate action according to the object type. For example, a drag operation in the content area of a window might select text if it is a text object, or icons if it is an icon object. Each object implements its own content handler. Another significant role of the content handler is to draw the view of the associated object on the screen implemented by the draw module of the object. The content handler also deals with input/output of object data through the object store.
The object store is a secondary storage where object definitions and their associated data are stored permanently. The window hierarchy cache is, on the other hand, in the primary memory storing information on the current window hierarchy.