 |
Description  |
|
|
BACKGROUND OF THE INVENTION
The present invention relates to a system that presents windows or other
workspaces on a workstation's display to provide a graphical user
interface. More specifically, the present invention relates to a window
system that can present plural windows at a time, each window providing a
user interface for a respective application.
A wide variety of graphical user interfaces are available for personal
computers and other computer workstations. Rao, R., "Towards
Interoperability and Extensibility in Window Environments via Object
Oriented Programming," Master's Thesis, Dept. of Electrical Eng. and
Computer Science, Massachusetts Institute of Technology, June, 1987,
examines existing window environments in chapters 1 and 2 and provides a
preliminary design for an object-oriented window environment in chapter 3.
Section 2.2 analyzes the functionality of a window system into window
management, input handling, output handling, and window environment
support; pages 32-33 discuss a hierarchical arrangement of windows, also
called a window tree, and the use of nesting of windows. Section 2.3
discusses issues in window environment design; pages 51-52 discuss how
Smalltalk, X, NeWS, and User Interface Management Systems (UIMS) separate
user interface from underlying services; pages 55-56 discuss window
placement, including the tradeoff between tiling and overlapping windows.
Section 3.2.1 discusses the windowing model of the proposed design,
describing at pages 66-67 a transformation mapping points in each child
visual plane to points in its parent visual plane and a hierarchy of
visual planes connected by visual worlds called a visual plane tree or a
visual universe; the parent, the children, and the transformations are the
elements of a visual world, and a set of constraints on how the elements
are related, together with policies for maintaining these constraints, is
called the visual world's contract. Section 3.2.2 discusses application of
the visual world model, with pages 72-73 comparing tiling and overlapping.
Section 3.3 discusses design issues, including the choice to design for
Common Lisp Object System (CLOS). Section 3.4 discusses window management;
section 3.4.1 describes visual planes; section 3.4.2 describes visual
worlds, explicitly representing a relationship between a parent visual
plane and a set of children visual planes; and section 3.4.3 describes
contracts distributed between the parent and the child visual planes,
considers whether contracts should be reified, and notes that explicity
representations of contracts could be useful as points to attach
functionality such as error recovery. Sections 3.7.1-3.7.4 describe
contracts for bordering a viewer, for managing overlapping viewers, for
managing tiling viewers, and for maintaining a scrollable viewer. Chapter
4 discusses obtaining flexibility through object-oriented programming.
Scheifler, R. W. and Gettys, J., "The X Window System," ACM Transactions on
Graphics, Vol. 5, No. 2, April 1986, pp. 79-109, describe the X Window
System's system substrate, which provides device-independent graphics. The
system includes a hierarchy of windows, described in section 4. Within a
window, its subwindows can be stacked in any order, with arbitrary
overlaps. Although a window can extend outside the boundaries of its
parent, those portions are never displayed.
NeWS Preliminary Technical Overview, Sun Microsystems, Mountain View,
Calif., October 1986, describes NeWS, another window system. Pages 37-38
discuss how clients with different conventions can coexist in NeWS. Pages
42-43 describe canvases that exist in a hierarchy, with a child of a
canvas having the capabilities of its parent.
"Window," ViewPoint Programmer's Manual, Xerox Corporation, September 1985,
pp. 50-1 to 50-16, describes a tree of windows, in section 50.1.2, within
which a window may have an ordered list or stack of its child windows.
Each window has a pointer to its parent, a pointer to the next sibling of
its parent, and a pointer to the window's topmost child. Section 50.2.4
describes window tree manipulation.
Bantz et al., EP-A 210,554, describe a method of windowing image data
maintained in a hierarchical data tree structure. The complete image is
defined at the root node and sub-images of the complete image are defined
at lower order nodes, with the primitive images being defined at the leaf
nodes. FIG. 4 shows a traverse function that searches the tree structure.
Kikuchi et al., EP-A 247,827, describe a computer system with a multiwindow
presentation manager that displays overlapping windows on a screen. As
shown and described in relation to FIG. 1, a section of memory connected
to the display device stored window coordinate data specifying the
positions and sizes of the independent windows on the screen; another
section of memory connected to a cursor display unit stores present-cursor
position data representing the latest coordinates of the cursor on the
screen. If the present-cursor position data and the window coordinate data
indicate that the cursor moves into one of the windows, that window is
automatically moved in front of the other windows, as shown and described
in relation to FIG. 3.
Noguchi et al., EP-A 249,399, describe multiwindow control techniques that
provide an icon window display area with precedence over other display
areas, as shown and described in relation to FIGS. 1 and 9. When a window
is concealed by one or more other windows, it is reduced to a
predetermined size and displayed in the icon window display area, as shown
and described in relation to FIG. 8. The windows are controlled in
accordance with a window control table and other tables and buffers as
shown and described in relation to FIGS. 3 and 4a-4d. The window control
table includes an item corresponding to each window and indicating its
position and other information.
Agarwal et al., U.S. Pat. No. 4,713,754, describe a data structure for a
document processing system, within which each page is subdivided into
nonoverlapping areas, each comprised of one or more types of layers. FIGS.
6 and 7 show the document files structure.
SUMMARY OF THE INVENTION
The present invention makes it possible to provide a window system in which
window functionality, including each window's input and output functions
and the functions that manage the relationship between related windows,
may be selected independently of the window hierarchy. This facilitates
the integration into a single user interface of applications with
graphical user interfaces that depend on incompatible sets of functions,
with the graphical user interface of each application being presented to a
user in its own window according to its own functionality. Furthermore, if
an application presents subwindows within its window, the relationships of
those subwindows to the application's window and to each other can be
governed by a set of functions that is incompatible with the sets of
functions governing the relationships of subwindows within other
application windows.
One aspect of the invention is based on the recognition of a basic problem
in managing multiple windows or other workspaces. Some conventional
systems provide multiple windows using a data structure that includes a
respective data unit corresponding to each window. Each window's
respective data unit conventionally has the same underlying structure as
other window data units, to facilitate production of the data structure,
and the underlying structure of window data units conventionally includes
or provides for inclusion of data relating to functionality, whether that
of a single window or of a set of related windows. A window data unit
having a particular structure can only be used with sets of functions with
which that structure is compatible. Therefore, the underlying structure of
window data units limits the extent to which functionality can be changed:
A different set of functions cannot be selected that is incompatible with
the structure of the window data units.
This problem can be solved by including data relating to window
functionality in data units that can be replaced independently of the
underlying structure of window data units and also independently of the
underlying structure of the data structure that includes the window data
units. This aspect is based on the discovery of techniques for including
functional data units in the data structure; each functional data unit
includes data relating to functionality of a set of windows and is
replaceably associated with the data units of those windows. The data in
each functional data unit can then be used in providing functionality of
the set of windows with whose data units it is associated. Functionality
can be selected by accessing and replacing a functional data unit by
another functional data unit that is compatible with a different set of
functions.
One technique according to the invention is applicable to data relating to
a single window's functionality, such as its sets of input and output
functions. A functional data unit that includes data relating to a
window's sets of input or output functions can be replaceably associated
with that window's data unit within the data structure. The window's data
unit can provide a placeholder within the data structure that has little
or no data that restricts the window's functionality. As a result,
functionality can be changed by replacing the functional data unit with
another functional data unit compatible with a different set of functions,
independently of the underlying structure of the window's data unit and of
the window system data structure.
Another technique according to the invention is applicable to data relating
to functionality of a set of windows, such as a windowing relationship in
which a set of windows called children are related by being nested in
another window called the parent. A functional data unit that includes
data relating to a set of functions that manage a windowing relationship
or other relationship between windows can be replaceably associated with
the data units of all of the related windows. Furthermore, if the data
structure includes an auxiliary data unit associated with the data units
of all the windows in the set, the functional data unit can be replaceably
associated with the auxiliary data unit. The auxiliary data unit can thus
provide a neutral relationship so that data units of the related windows
need not include data restricting the relationship. As a result, the
functionality can be changed by replacing the functional data unit with
another functional data unit compatible with a different set of functions
managing relationships, independently of the underlying structure of the
related windows' data units and of the window system data structure.
The following description, the drawings and the claims further set forth
these and other objects, features and advantages of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic diagram of a workstation presenting windows in
accordance with the invention.
FIG. 2 is a schematic diagram representing a data structure that includes
an auxiliary data unit and functional data units according to the
invention.
FIG. 3 is a schematic diagram showing components of a system including a
data structure according to the invention.
FIG. 4 is a schematic block diagram showing structure and relations between
data units within the data structure in FIG. 3.
DETAILED DESCRIPTION
A. General Features
General features of the invention can be understood from FIGS. 1 and 2.
FIG. 1 shows windows that can have independently replaceable functionality
on a workstation's display. FIG. 2 shows a data structure with an
auxiliary data unit to facilitate windows that can have independently
replaceable functionality.
FIG. 1 shows workstation 10 with display 12 and keyboard/mouse 14. Display
12 is shown presenting a number of windows. Window 20 is outermost, and
can, for example, present the graphical user interface provided by a
special purpose application called a desktop manager. Within window 20 are
windows 30 and 40, each of which is a subwindow of window 20 and each of
which can present the graphical user interface of a respective application
that makes use of the window system. In other words, the user can provide
inputs to the respective application of one of windows 20 and 30 through
signals directed to that window, with the respective application providing
output for display in that window.
FIG. 1 also illustrates how different sets of windowing functions could be
independently selected and used. The windowing functions governing windows
20, 30, and 40 could be different from the windowing functions governing
windows 30, 32, and 34 or governing windows 40, 42, and 44. For example,
the windowing functions of window 20 and its children could simulate the
windowing calls of the X Window System ("X"), so that a desktop manager
designed for X could be readily ported to this environment. On the other
hand, the windowing functions of window 40 and its children could simulate
the windowing calls of the Interlisp-D window system, which has a built-in
desktop manager. And the windowing functions of window 30 and its children
could be lightweight functions for providing tiled subwindows. Any of
these sets of windowing functions could be selected and used independently
of the other windowing functions.
In addition, each window in FIG. 1 could have different functionality.
Windows 34 and 44 could each have a simple output service capable only of
providing text output, for example a TTY output service, while windows 32
and 42 have a more complete output service that supports geometric shapes
and curves. Windows 34 and 44 could have input services that only notify
them of keyboard events, while windows 32 and 42 could have input services
that also notify them of mouse events. The input or output functionality
of each window could similarly be selected independently of the
functionality of other windows.
FIG. 2 is a schematic representation of data structure 50, which could be
used to provide windows with independently selected functionality as in
FIG. 1. Data structure 50 is hierarchical, with nodes corresponding
generally to each window in FIG. 1. The uppermost node in data structure
50 is workspace data unit 52, corresponding to window 20. Associated
between it and the next level of workspace data units is auxiliary data
unit 54, with which are associated workspace data units 56 and 58,
corresponding to windows 30 and 40, respectively. Auxiliary data units 60
and 62 are in turn associated with workspace data units 56 and 58,
respectively. Finally, auxiliary data units 60 and 62 are associated
respectively with workspace data units 64 and 66 and with workspace data
units 68 and 70, corresponding to windows 32, 34, 42 and 44, respectively.
In addition to this hierarchy of workspace and auxiliary data units, data
structure 50 includes associated data, some of which is shown in FIG. 2.
Workspace data unit 56 illustratively has associated functional data units
80 and 82, respectively including data relating to input and output
functions of window 30. Auxiliary data unit 60 has associated functional
data unit 84, illustratively including data relating to a first windowing
relationship among windows 30, 32, and 34. Similarly, auxiliary data unit
62 has associated functional data unit 86, illustratively including data
relating to a second windowing relationship among windows 40, 42, and 44.
Data units 80, 82, 84, and 86 are merely illustrative, of course, and each
workspace data unit and auxiliary data unit could have associated
functional data units similar to those shown associated with workspace
data unit 56 and with auxiliary data units 60 and 62.
The manner in which associated functional data units 80, 82, 84, and 86 are
shown in FIG. 2 also illustrates that any one of them could be replaced,
without other modifications to the data structure, whether workspace data
units, auxiliary data units, or other functional data units. Furthermore,
each of these functional data units can be successfully utilized by a
corresponding set of functions, and each could be replaced by a different
functional data unit that could be utilized by a different set of
functions. In other words, functional data units 80, 82, 84, and 86 are
independently replaceable.
Generalizing from the features illustrated in FIGS. 1 and 2, the following
conceptual framework is helpful in understanding the broad scope of the
invention. This conceptual framework is a modification and extension of
that set forth in the following copending, coassigned U.S. patent
applications, all of which are incorporated herein by reference
(collectively "the workspace applications"). Ser. No. 030,766, entitled
"User Interface with Multiple Workspaces for Sharing Display System
Objects," filed Mar. 25, 1987; Ser. No. 127,997, entitled "Multiple Shared
Virtual Workspaces," filed Dec. 2, 1987; Ser. No. 195,230, entitled
"Accelerating Link Creation," filed May 18, 1988, now issued as U.S. Pat.
No. 4,982,344; and Ser. No. 241,525, entitled "Private Regions within a
Shared Workspace," filed Sept. 7, 1988. The terms defined below have the
meanings indicated throughout the specification and in the claims.
A wide variety of display systems for data processing systems are available
including, for example, various graphical user interfaces, but, despite
their diversity, these systems tend to have certain common
characteristics. One fundamental common characteristic is that a display
produces human perceptions. In this application, the term "display
feature" refers to any human perception produced by a display.
A "workspace" is a display feature within which other display features
appear to have respective relative positions. A window is an example of a
workspace. A workspace can have a visible boundary on the display, as
windows 20, 30, 32, 34, 40, 42, and 44 illustrate. On the other hand, a
workspace need not have a visible outer boundary and need not be
contiguous. "Presenting" a workspace that includes plural display features
produces the human perception of the display features in respective
positions relative to each other.
As used herein, the term "workspace" includes a "virtual workspace,"
defined in some of the workspace applications as a workspace that is not
completely viewed at a given time. Presentation of a virtual workspace
produces the human perception of a workspace that exists but is only
partially viewed or is not always viewed. The size of workspaces within a
given display system may thus range from the smallest extent within which
the system's display can present other display features in respective
relative positions to the largest extent that can be managed by the
system.
A workspace or set of workspaces can have several kinds of "functionality."
For example, inputs directed to a workspace by the user can be delivered
in accordance with a characteristic input service. Similarly, outputs can
be presented within a workspace in accordance with a characteristic output
service. Also, a relationship between members of a set of workspaces can
be managed according to a characteristic service for managing that
relationship. In general, workspace functionality includes all of the
characteristic services a workspace or set of workspaces may have. Each
service could, for example, be a set of functions that can be called by an
application.
Workspaces can be "related" in various ways. One workspace can be
"presented within" another workspace, meaning that a display feature
within it appears to have a respective position relative to other display
features within that other workspace. Two workspaces can "overlap,"
meaning that a part of one of them obscures a part of the other. Two
workspaces can be "tiled," meaning that both are presented within some
third workspace, but in mutually exclusive parts of the third workspace,
one for each of the tiled workspaces. The workspaces in a set of virtual
workspaces can be "alternatives," meaning that one of the set can be
displayed even though the others are not visible. Two sets, each including
one or more virtual workspaces, can be "linked," in the sense that a user
viewing one set can make a request to view the other set. In short, the
variety of relationships between workspaces is practically unlimited.
A workspace is "nested" in another workspace when it is only presented
within the extent of that other workspace, with no part of it outside that
other workspace, and when, if presentation of the other workspace ceases,
presentation of the nested workspace also ceases. A special type of
relationship between workspaces is a "windowing relationship," meaning a
relationship that governs a workspace, called the "parent," and a set of
other workspaces nested within it, called its "children." A windowing
relationship, for example, governs how the space within the parent is
divided among the children, including the ordering, positioning, and
sizing of the children. An "ancestral relationship" is a relationship
among a set of workspaces, each of which is a parent of at most one other
workspace in the set and a child of at most one other workspace in the
set; for example, a grandparent, parent, and child could have an ancestral
relationship. A "sibling relationship" is a relationship between two or
more children that are in a windowing relationship.
Another common characteristic of display systems is a correspondence
between data within the data processing system and display features. In
this appli | | |
