 |
Description  |
|
|
TECHNICAL FIELD OF THE INVENTION
This invention relates to computer processes, and more particularly to a
method of using a computer to provide a graphics interface, which displays
a graph of data and permits the user to modify the data by directly
manipulating the graph.
BACKGROUND OF THE INVENTION
The use of computers to generate graphical displays, which illustrate the
relationships of underlying data is well known. For example, a computer
might be used to generate a bar graph to illustrate the relationship
between a set of data values taken at different points in time.
A fairly recent development in computer applications is the integration of
database management capabilities and graphical displays. Both types of
applications deal with the same database. Various software tools have been
developed to provide dynamic linkages between these different
applications.
However, a common characteristic of these integrated systems is that data
is entered in text form, via conventional data entry means. Even when a
graphical user interface is available for permitting the user to directly
manipulate objects on a display screen, these user interfaces are limited
to invoking operating system tasks, such as file management, rather than
for changing application data.
SUMMARY OF THE INVENTION
A simplified aspect of the invention is a method of using a computer to
implement a graphical interface having a single view style for a single
type of graph. More specifically, the invention is a method of using a
computer to display a graph illustrating data and to permit a user to edit
the data by directly manipulating the graph. The computer stores a
graphics engine, comprised of a set of rules for displaying graphical
objects and graphical attributes that comprise the graph. The computer
also stores a local database comprised of user-specified records and
fields of data, accessible by the graphics engine. The computer receives
specification data from the user, in which data fields are matched to
graphical attributes. The computer receives configuration data from said
user specifying at least one record type of records in said local database
and at least one field of said record, which are to be illustrated with
the graph. The computer matches each data value of the record type with a
graphical object. It also matches each data value of the fields with a
graphical attribute of said graphical object. It displays a graph
comprised of the graphical objects, with corresponding attributes, on a
display screen. It then receives editing input from an end user,
representing a change to a value of a selected field within one of the
records. It matches the selected field to an attribute of a target
graphical object. It changes the target graphical object in response to
said editing input, and updates the local database, such that the value of
said selected field is reflects said change.
One enhancement of the invention involve storing more than one view style,
each having its own graphics engine. For each view style there could be
multiple objects and attributes, requiring the user to specify what data
values are to be matched with those objects and attributes. A message
passing protocol can be set up between the graphical interface and a
separate database system, which supplies data for the local database, and
is updated with new data values resulting from editing of the graph.
Commands may be specified so that tasks may be performed by other
applications during presentation of a graph.
One technical advantage of the invention is that its graphics engines
provide a degree of generality to the process of using a computer to
display graphic illustrations of data. For example, for a gantt chart, the
graphics engine may include certain routines that are common to all gantt
charts, so that for a specific illustration of data, the user need only
specify what data is to be presented.
Another technical advantage of the invention is that it permits direct
manipulation of a graph to edit the underlying data represented by the
graph.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates the basic components of programming for implementing the
method of the invention.
FIG. 2 is a computer system for executing the method of the invention.
FIG. 3 illustrates the objects comprising a view style,
FIG. 4 illustrates components of a graphics engine of FIG. 1.
FIG. 5 illustrates a display screen with a menu line, representing menus of
tasks performed by the master process of FIG. 1.
FIGS. 5A-5D illustrate menus of tasks represented by the menu line of FIG.
5.
FIG. 6 is a dialog box for specifying data to be illustrated by any one or
more view styles.
FIG. 7 is a dialog box for specifying the values of an enumeration field
type.
FIG. 8 is a dialog box for specifying associations between potential data
values and graphical attributes.
FIG. 9 is a dialog box for specifying linking instructions for the link
manager of FIG. 1.
FIG. 10 is a dialog box for specifying commands that may be executed during
presentation of a graph.
FIG. 11 is a dialog box for specifying controls that may be imposed during
presentation of a graph.
FIG. 12 lists the steps of using a computer to present a graph and to
accept user manipulations in accordance with the invention.
FIG. 13 is a dialog box for receiving a user's choice of view styles.
FIG. 14 illustrates a blank graph.
FIG. 15 illustrates a dialog box for specifying associations between data
fields and view-specific graphical objects and attributes.
FIG. 16 illustrates a graph generated by one of the graphics engine of FIG.
1.
FIG. 16A illustrates the "edit" tasks performable by a graphics engine
during presentation of a graph.
FIG. 16B illustrates the "view" tasks performable by a graphics engine
during presentation of a graph.
FIG. 16C illustrates the "commands" tasks performable by a graphics engine
during presentation of a graph.
FIG. 17 illustrates a graph with a graphical object having been selected
for editing.
FIG. 18 is a dialog box for receiving the user's editing input.
FIG. 19 is a second type of dialog box for receiving the user's editing
input.
DETAILED DESCRIPTION OF THE INVENTION
System Components
FIG. 1 illustrates the basic software components of a computer-based
graphics interface 10 for graphically illustrating data retrieved from a
database system 11. This software resides in the memory of a computer
system, and when executed, implements the method of the invention.
FIG. 2 is a block diagram of a computer system 20 for executing the process
of the invention. In general, the components of the system are
conventional computer components, and include a general purpose processing
unit 21, such as one based on the Intel 386 microprocessor. A program
memory 22 stores program code. A data memory 23 stores data, and may
include a mass memory for storing a database. The system 20 also has a
bit-mapped graphics display 24 and input devices, such as a keyboard 25
and a pointing means 26.
One example of a pointing device 26 suitable for use with the invention is
a trackball-type "mouse". A user moves the mouse to position a cursor on
the display screen. By depressing or releasing a switch on the mouse, the
user indicates to the computer when the cursor has a position that
corresponds to, i.e., "points to", the user's, selection of an object on
the screen. Other pointing means 26 could be used, such as a trackball
with separate selection keys, or a touch screen display. By "selection" of
an object or attribute as used herein, is meant to user's activity of
pointing to the object or attribute and indicated his selection.
The computer system 20 operates under a "windows" type operating system 16,
such as the Windows system manufactured by Microsoft Corporation. Another
example of a windows operating system 16 is the UNIX operating system.
A significant feature of the operating system 16 is that it permits
computer system 20 to generate multiple windows on display 24, each of
which corresponds to an independent application program. Thus, it permits
the graphics interface 10 and database system 11 to be in execution at the
same time.
The present invention relates to the use of a computer system, such as that
of FIG. 2, which stores and executes programming for the graphics
interface 10 of FIG. 1. As an overview of the method of the invention, a
graphics engine 12 generates a display that illustrates a set of data
delivered from database system 11. A link manager 13 handles message
passing between database system 11 and graphics interface 10. A local data
store 14 stores data that is the subject of the current display being
generated by graphics engine 12. The display is comprised of distinct
graphical objects, each representing an item of data. The graphical
objects have attributes, such as color and size, which also represent
data. If the user desires to change the data, he may either enter new data
in text form or use a pointing device to directly manipulate the
appropriate graphical object. Either type of input causes local data store
14 to update its copy of the data, and causes link manager 13 to send a
message to the database system 11 so that its data is updated. A master
process 15 handles interactions with the user, and also permits the user
to define how data will be organized in local data store 14 and to specify
associations between graphical objects and data.
Database system 11 can be any type of database system, such as one in which
data is organized as files, records, and fields. It is assumed that
database system 11 has mass memory for storing data and some sort of data
management programming. Database system 11 may be any one of a number of
commercially available database application programs. However, database
system 11 could be as simple as any collection of data with some means for
handling data exchanges via a message protocol.
For purposes of this description, an example of a database system 11 for
storing and processing employee data is used. Each employee record is
organized into fields of data, each field containing an item of data
relevant to that employee. Some examples of employee data fields are
salary, vacation time, and length of employment.
Graphics interface 10 has at least one graphic engine 12. Each graphics
engine 12 contains a description of a unique view style. Examples of view
styles are gantt charts, tree charts, or bar charts. A typical graphics
interface 10 will have a number of graphics engines 12, one for each view
style.
In general, a view style provides for an interactive presentation of data,
in which instances of user data are presented as graphical objects. Each
graphical object is a rectangular area on a logical display. The primary
concern of a view style is determining the size and position of these
graphical objects. Typically, this determination is on the basis of a data
field of a data record associated: with the graphical object. Because of
this relationship between position and size and user data, a view style
may constrain the kinds of data it can present. Another view style
constraint is that the relationship between objects and the data should
lead to some sort of intuitive means for manipulating the objects to
affect the data.
FIG. 3 illustrates an example of the objects of a gantt chart view style.
An example of a graphic object in the gantt chart 30 is each bar 31, which
represents an interval of time. Another object is each label 32, one each
of which is associated with a bar 31.
Using the example of employee data, the gantt chart of FIG. 3 is a chart of
vacation times. Each object of the graph, in this case a bar 31,
represents a vacation time of an employee, whose name is indicated by the
label 32 of that bar 31. The position and length of the bar 31 indicate
start and stop times of the employee's vacation. Thus, in FIG. 3, two
graphical objects represent each employee. If Employee B's vacation time
data is the value "week 2-week 4", the associated object, i.e., bar 31,
would have a position and length representing that data. As an another
example, a tree view style might have objects in the form of nodes in a
tree hierarchy.
Each graphical object, such as a bar 31 or label 32, has one or more
attributes. For example, a bar 31 of gantt chart 30 may have start
position, stop position, and color attributes. Labels 32 might have
attributes, such as its data string, font, or color. Each attribute is
associated in some manner with data. For example, an employee who is
currently on vacation might have his bar 31 displayed in a red color.
Thus, the graphics engine 12 for a view style includes a description of the
view style, in terms of rules for displaying objects comprising that view
style. In general, the rules for a view style determine layout, i.e.,
where objects go and how big they are. Appendix A sets out a number of
rules for a graphics engine 12 for a gantt chart view style. Rules for
other view styles may be similarly developed to create other graphics
engines 12.
Creation of an instance of a view style (herein referred to as a "graph")
is interactive. As explained below, the user specifies what data will be
mapped to the objects and attributes, and in response, the graphics engine
12 handles the layout in the display screen.
Referring again to FIG. 1, link manager 13 enforces a message exchange
protocol, which ensures the that data in local data store 14 and in
database system 11 are consistent. In other words, if an item of data in
one location is updated, the copy of that data in the other location is
also update. If the user changes a graph, whether by means of textual
input or by direct manipulation of a graphical object, link manager 13
sends a message to database system 11. This message contains the updated
data so that database system 11 can update its copy of that data.
Likewise, if, during presentation of a graph, the user changes data using
input means of database system 11, link manager 13 sends a message
containing the new data to local data store 14.
An example of a message passing protocol suitable for use with the present
invention is the DDE (dynamic data exchange) protocol, developed by
Microsoft Corporation, for windows operating systems. Another example is
the "pipes" means for interprocess communications, as implemented on the
windows interface for UNIX operating systems.
Messages communicated by link manager 13 are either data messages or
executive messages. As an example of a data message, if a user changes a
data value with input to graphics engine 12, a data message to database
system 11 would contain the new data and permit the data to be "poked"
into database system 11. Conversely, if a user changes a data value with
input to database system 11, a data message from database system 11 to
graphics interface 10 would contain that new data. As an example of an
executive message, if a user desires to a dialog box from database system
11 to appear on a graph, this could be accomplished with a command to
database system 11 and an executive message to graphics engine 12.
Local data store 14 stores data in accordance with a user-defined schema.
This data is a copy of some subset of data stored in database system 11.
The data in local data store are organized as record types, each record
having one or more fields, and each field being a certain type. At least
one field of a record type is a "key" field, whose value is unique for
each occurrence of a record type. For example, each employee's key field
might contain that employee's unique id number. As explained below, this
organization of data in local data store 14 permits the data to be mapped
to graphical objects and attributes.
A feature of local data store 14 is that it includes a routine for
receiving an indication from graphics engines 12 if the user changes data
of the graph, whether by textual input or by manipulating an object. If
such an indication is received, local data store 14 updates its copy of
the data represented by that object. Also, a particular data value might
be the subject of more than one view style. For this case, local data
store 14 provides notification tasks, such that when an object is changed
via one graphics engine 12, other graphics engines 12 are notified.
Master process 15 handles interaction with the user. It receives user
specification data, such as the organization of data in local data store
14 and directions for routing messages by link manger 13. The
specification process is explained below in connection with FIGS. 5-11, as
a result of which, the stored specification data 17 is accessed by master
process 15. The distinction between what is user-specified, as opposed to
being generated by stored programming, reflects the extent to which the
programming of graphics interface 10 is re-useable. Master process 15 also
handles, with the cooperation of a graphics engine 12, the presentation of
any instance of a view style. The presentation and editing of graphs is
explained below in connection with FIGS. 12-19.
FIG. 4 illustrates one architecture for implementing a graphics engine 12.
Each graphics engine 12 has its own executive 35, which opens a window
when the corresponding view style is selected by the user. It calls for
routines stored in root library 36 and in rule set 37. Root library 36 is
shared by all graphics engines 12, and contains routines that are common
to them, such as data sorting routines. Rule set 37 contains the rules for
the view style presented by that graphics engine 12.
Consistent with the architecture of FIG. 4, master process 15 calls for
services by a graphics engine 12. Master process 15 and the graphics
engines' executives 35 are separate but dependent processes. The root
library 36 and rule sets 37 are dynamically linked libraries. In a windows
environment, master process 15 and executive 35 each control their own
window. Alternatively, "custom controls" features of the windows
programming may be used, so that instead of a window being created by
executive 35, graphs are created in a window of database system 11, which
calls routines from graphics engine 12.
FIG. 5 illustrates a display screen 50, which presents to the user a
selection of tasks performed by master process 15. FIGS. 5A-5D illustrate
the pulldown menus, with selections that represent those tasks. "File"
tasks, listed in FIG. 5A, are like those of conventional applications
programs. "Edit" tasks, listed in FIG. 5B, are explained below in
connection with FIGS. 6-11. "Linking" tasks, listed in FIG. 5C, set up
links among subscribing applications. "Views" tasks, listed in FIG. 5D,
are explained below in connection with FIGS. 12-20. "Commands" tasks are
explained below in connection with FIG. 21. Each of these tasks is
interactive, in the sense that master process 15 acts in response to user
specifications. It then forwards these specifications to link manager 13,
local data store 14, or graphics engine 12. In FIG. 5, display screen 50
also displays a palette of graphs already created, which may be
manipulated to display those graphs.
Referring again to FIG. 1, specifications 17 represent stored input from
the user, entered via the interactive "edit" tasks of master process 15.
In practical use, the "user" who provides these specifications might be a
software developer, who adds a layer of functionality to the graphical
interface 10. This developer might be different from the "end user" who
actually views graphs via the "views" tasks and makes practical use of
user data from database system 11. However, for purposes of this
description, the word "user" may mean either of such persons.
Specification Tasks
FIG. 6 illustrates a dialog box presented by master process 15 when the
user selects the "Record Types" task from the "edit" menu of FIG. 5B. The
user's textual input to dialog box 60 permits the user to specify the
schema of data in local data store 14. More specifically, the user
specifies a record type, the fields within each record, and the data type
of each field.
In the example of FIG. 6, the user has specified an "employee" record type,
with a "manager" field, of type REF. This means that an employee's record
has a field that points to the record of that employee's manager, who is
also an employee. This type of data would be useful for illustrating
organization with a "tree" view style.
If the field type is "enumeration", the user may specify a closed set of
values that the field may have. For example, FIG. 7 illustrates a dialog
box 70 that is presented by master process 15 if the user selects the
field type "enumeration". The field type "badgecolor" is specified so that
the field may have a value that represents one of a set of colors. These
values will be constant for all instances of a view style presented by
that graphics engine 12.
FIG. 8 illustrates a dialog box 80 that permits the user to associate the
potential data values of a field type "enumeration" to graphical
attributes. Dialog box 80 is presented in response to selection of the
"associations" task from the "edit" menu of FIG. 5B.
Using dialog box 80, the user first matches the enumeration type to an
attribute type. Then, for each possible data value of an enumeration type,
the user specifies a different instance of an attribute. This mapping is
used by graphics engines 12 when presenting a graph. An object having the
specified attribute will display that attribute according to the data
values. For example, in a gantt chart, the bar 31 of an employee might
have a color attribute that corresponds to that employee's "badgecolor"
field value.
FIG. 9 illustrates a dialog box 90, presented by master process 15, if the
user selects the "links" tasks from the "edit" menu of FIG. 5A. This
dialog box 90 permits the user to specify the location of data, which is
currently stored in database system 11, so that it may be delivered to
local data store 14.
FIG. 10 illustrates a dialog box 100 presented by master process 15 if the
user selects the "commands" task of the "edit" menu of FIG. 5B. Using
dialog box 100, the user gives the command an identifier, and specifies
the application to which the command is directed. The user also enters a
command string, such as a DDE executive message, to be performed by that
application. Once a command has been defined, its identifier will appear
on the "commands" menus of either master process 15 and of all graphics
engines 12, or only on the "commands" menus of certain graphics engines
12. This depends on whether the user specifies that the command is related
to a specific data type. If not, the command identifier appears on all
"commands" menus. If the command is related to a certain data type, the
command identifier appears as a menu choice only during presentation of
graphs that use the specified data type, as explained below in connection
with FIG. 17. This is implemented by means of the association, during
presentation of a graph, of record types and fields to objects and
attributes, which in turns are associated with particular view styles.
Further details of commands tasks are explained below in the section
entitled "Link Manager Subscribers".
FIG. 11 illustrates a dialog box 110, generated by master process 15 when
the user selects the "update control" task of the "edit" menu of FIG. 5B.
This task permits a user to specify controls over editing of the data of
database system 11. For example, in FIG. 11 the user has indicated that
certain update controls are to be imposed for the record type "employee".
During presentation of a graph, these controls will prevent an end user
from performing the specified updates. Dialog box 110 also permits the
user to specify a remote command, such that if data is modified via
graphics interface 10, database system 11 will automatically respond with
some process rather than simply updating its data.
As a result of the various editing tasks described below, a user, typically
a developer user, has created a file of specifications data 17. This data
17 is stored in memory 23 for use by graphics interface 10 during
presentation of a graph for an end user.
Views Tasks
FIG. 12 illustrates the process of displaying a graph. For purposes of FIG.
12, it is assumed that the graphics interface 10 and the database system
11 of FIG. 1 are currently in execute mode on a computer system and that a
message passing protocol has been established between them. In general,
this protocol includes a reciprocal notification requirement, such that
when a data value is changed, link manager 13 ensures that local data
store 14 and database system 11 are updated. Specifications for this
message passing are supplied by a user, as discussed above in connection
with FIG. 9.
For purposes of example, to illustrate the steps of FIG. 12, the user
specification process of FIGS. 6-11 is assumed. The process of presented a
graph is initiated by master process 15 when the user selects the "create"
tasks from the "views" menu of FIG. 5D. However, it should be understood
that simpler version of the invention might have view styles with single
objects and/or single attributes, or predefined mappings from objects and
attributes to records and fields, such that less user specification is
required.
As indicated by step 100, it is assumed that at least one graphics engine
12 has been provided with the rules for a view style.
In step 101, local data store 14 is set up with user-specified record types
and fields. This may be accomplished by user specification as discussed
above in connection with FIG. 6. If the local data is to be supplied from
database system 11, step 101 includes a data exchange from database system
11 to local data store 14.
In step 102, the user initiates a graphics engine 12 for the desired view
style. This causes executive 35 of the corresponding graphics engine 12 to
open a "window".
FIG. 13 illustrates a dialog box 130, generated by master process 15 in
response to the user's selection of the "create" task of the menu of FIG.
5D. This dialog box permits the user to select a view style from a menu of
available view styles, as stored in various graphics engines 12. The user
may select any view style, such as by means of pointing device 26.
As a result of step 102, executive 35 takes over processing tasks from
master process 15. The graphics engine 12 corresponding to the selected
view style generates a "blank" graph. FIG. 14 illustrates a blank graph
140, which was generated after the user selected a gantt chart view style.
The blank graph 140 has a time line 141, but the user-data area 142 is
blank. A menu line 143 has a menu heading for "configure" tasks.
In step 103, the user configures the view style by specifying at least one
record type and at least one field of the specified record types. Data
values for this record type and field are the data to be illustrated by a
graph having the selected view style. It is assumed that the specified
record type and field are already part of local data store 14. However,
means could be provided for dynamically passing data to local data store
14 during graphing.
FIG. 15 illustrates a dialog box 150, by means of which the computer
accepts the user's configuration data in step 103. This dialog box has
been generated by graphics engine 12, in response to the user's selection
of the "configure" task from the menu represented in FIG. 14. Using the
example of employee vacation times, the user has entered a record type,
"employee". Each instance of a record type, i.e., each record, represents
a different employee. As explained above in connection with FIG. 3,
graphics engine 12 has stored associations between the instances of each
record type and one or more objects. For a gantt chart view style, each
instance of a record type is associated with a bar and a label. Vacation
stop and start times are fields within each record. Graphics engine 12
also has stored associations between field data and graphical attributes.
For a gantt chart, the relevant attributes are the right and left
positions of each bar, which are associated with start and stop fields. By
means of the dialog box 150, the user specifies that the start and stop
fields are vacation start and stop fields.
In step 104, graphics engine 12 matches each record specified in step 103
to a graphics object. Using the gantt chart example, graphics engine 12
matches each instance of the specified record type (each employee) to a
bar 31 and a label 32. It also matches field values to attributes. For
example, vacation start and stop fields (data values) are matched to left
and right edge positions (attributes) of each bar 31.
In step 105, graphic engine 12 assigns each graphics object a rectangular
area on the display. The attributes of the object are determined by the
data in the field that belongs to the corresponding record. Graphics
engine 12 thereby generates a graph of the selected data.
FIG. 16 illustrates a gantt chart 160 generated by graphics engine 12 in
step 105. The gantt chart 160 has a menu line 161, whose selections are
used to invoke pulldown menus of tasks performed or initiated by graphics
engine 12, during presentation of the current graph. The "configure" tasks
permit the user to repeat step 103, so as to change the data being
displayed. For example, the user might desire to see a different gantt
chart, such as one that illustrates each employee's length of employment.
The "edit" tasks, illustrated in FIG. 16A, permit the user to change data
via textual input, and are explained in detail in connection with steps
106-109. The "view" tasks, illustrated in FIG. 16B, permit the user to
control the display, such as by re-sizing and scrolling. The "view" tasks
may also be used to call various data analysis routines, such as sorting
and filtering. The "commands" tasks, illustrated in FIG. 16C, permit the
user to select commands that have been previously specified, as explained
above in connection with FIG. 10. The "windows" tasks provide a means for
accessing other windows of graphics interface 10, such as displays of
other view styles.
Steps 106-109 are performed if the user desires to edit the data being
illustrated by the currently displayed graph. As stated above, a feature
of the invention is that the user may edit an item of data either by
textual input or by manipulating the graphical object that represents that
data. In either case, in step 106, the user first identifies the data item
to be changed. For example, the user may select the graphical object
representing that item with pointing device 26. Step 107a is performed if
the user desires to edit the data by textual input. This can be
accomplished by selecting the "edit" menu from menu line 161, and
selecting an appropriate "edit" task. This results in placing graphics
engine 12 in a state for accepting textual user input.
FIG. 17 illustrates a gantt chart 150 with employee "Travis Hills" selected
for editing, in accordance with step 107. The "edit" menu is displayed in
accordance with step 107a.
A feature of the invention is that editing by means of textual input can be
accomplished by input means of either graphics interface 10 or of database
system 11. Thus, in one embodiment of the invention, when the "edit"
choice is invoked, graphics engine 12 generates a dialog box into which
the user enters the new data. FIG. 18 illustrates a dialog box of this
type. In an alternative embodiment of the invention, selection of the
"edit" command causes link manager 13 to send an executive message to
database system 11, which then generates its own dialog box. FIG. 18
illustrates a dialog box of this type. In either case, graphics engine 12
responds by updating the graph. Other type of textual input might include
selection from a menu. This latter input is "textual" in the sense that
the new data is represented by text rather than a change to the appearance
of the graph.
Step 108 is performed to change the display by direct manipulation of a
graphic object. The user moves the cursor to the object that represents
the data to be modified.
Referring again to FIG. 17, for this type of editing, the edit menu would
not be selected. Instead, in accordance with step 107, a specific record,
i.e., Travis Hills, would be selected. This activates "hot" areas on the
corresponding object, i.e., a gantt bar, to which the cursor may be moved
to signify which attribute is to be changed. The user then manipulates the
object, such as by moving pointing device 26.
For example, to add more time to Travis Hills' vacation, the user points to
the right end of the corresponding bar, and drags the right end of the bar
to lengthen it. The use of a pointing device, such as a mouse, to redraw
an object on a display screen is performed by known graphics input
techniques.
Other types of direct object manipulation could be used to change an
object's attribute. For example, positioning a cursor on a "color" spot
could result in display of a color menu to change the color of the object.
Although this type of manipulation does not involve movement of the
object, it is a "direct manipulation" in the sense that the object changes
in response to a change to an attribute, rather than in response to a
change to underlying data in text form. Appendix B describes a number of
other view styles and how their graphical objects may be manipulated.
In step 109a, when the input is complete, graphics engine 12 declares a new
value for the data represented by the object and writes that value into
local data store 14. In response, local data store 14 notifies other
graphics engines 12 that use the same data so that they will update the
appearance of their graphs.
In step 109b, link manager 13 sends a data message to database system 11,
informing it that its copy of the data item needs to be updated. This
activity by link manager 13 is automatic as a result of its constant
monitoring of local data store 14. If a value is changed, a "flag" is
detected by link manager 13.
Referring again to the "edit" menu of FIG. 16A, other tasks permit the user
to select other data editing tasks, such as adding a new data item or
deleting a data item. These tasks can be performed by direct manipulation
or by means of dialog boxes, and in either case, result in an update of
local data store 14 and a message to database system 11.
Link Manager Subscribers
As indicated above in connection with steps 107-109 of FIGS. 12, link
manager 13 is automatically invoked after a user edits data during
presentation of a graph. It transmits an update messages to database
system 11 and to any graphics engine 12 that uses the data. Thus, database
system 11 is a "subscribers" to link manager 13, as are other graphics
engines 12 that use the same user data.
Another feature of the invention, discussed above in connection with FIG. 5
is that the user may specify commands to be performed by another
application, such as database system 11, during presentation of a graph.
Once a command has been specified, it is represented by a selection on the
"commands" menu of FIG. 5. As indicated by FIG. 10, the user may also
specify "include on menus", which causes the identifier to also appear on
the "commands" menu of the view styles of different graphics engines 12
and invoked during presentation of a graph. FIG. 16C illustrates an
example of a "commands" menu of the latter type.
Commands are preformed by means of executive message to the designated
application. This designated application is thus a "subscriber" to link
manager 13 for command purposes. In practical use, any type of application
program could be designated to perform a command. For example, a voice
synthesizer application could be commanded to generate a voice prompt if
it became aware of an event affecting a graph.
The combination of link manager 13, the commands stored in graphics engines
12, and the control commands, together comprise a communications protocol
for the graphics interface.
Other View Styles
Although the above description is in terms of a graphics engine 12 for a
gantt chart view style, Appendix B describes other view styles. The
operation of master process 15 is the same for each of these view styles.
Also, the same steps of FIG. 12 are applicable. Like the above-described
gantt chart view style, these view styles also permit direct object
manipulation for editing data.
Other Embodiments
Although the invention has been described with reference to specific
embodiments, this description is not meant to be construed in a limiting
sense. Various modifications of the disclosed embodiments, as well as
alternative embodiments, will be apparent to persons skilled in the art.
It is, therefore, contemplated that the appended claims will cover all
modifications that fall within the true scope of the invention.
APPENDIX A View | | |
