 |
Description  |
|
|
FIELD OF THE INVENTION
This invention generally relates to improvements in display systems and
more particularly to global notification of changes occurring in a system.
BACKGROUND OF THE INVENTION
Among developers of workstation software, it is increasingly important to
provide a flexible software environment while maintaining consistency in
the user's interface. An early attempt at providing this type of an
operating environment is disclosed in U.S. Pat. No. 4,686,522 to Hernandez
et al. This patent discusses a combined graphic and text processing system
in which a user can invoke a dynamic object at the location of the cursor
and invoke any of a variety of functions from the object. This type of
natural interaction with a user improves the user interface and makes the
application much more intuitive.
For a system to be intuitive to a user, system changes must be communicated
in a consistent manner regardless of what application is currently active.
None of the prior art references applicant is aware of provides the
innovative hardware and system software features which enable all
applications to obtain system changes through a generic framework for
notification.
SUMMARY OF THE INVENTION
Accordingly, it is a primary objective of the present invention to provide
an object based system with a generic framework for notification. Each
object contains status information determinative of the object's state
(enabled/disabled), its name, its associated graphic, and whether its
appearance is currently valid.
Next, the invention queries a command object for notification. Each command
object has four methods to connect for different types of notifications:
i) notifications that affect it's name,
ii) notifications that affect is graphic,
iii) notifications that affect whether it's active, and
iv) notifications that affect any data it provides.
in this case, the object item just created for the command connects for
active notification. It does this by passing a connection object to the
notification system. The command is then responsible for connecting the
connection object to notifiers affecting whether the command is active.
Then, the object system queries the command for the enabled state before
presenting the object item on the display. This processing is accomplished
by examining the current system state to ascertain if the function is
active in the current context. Then, the internal state of the object item
is updated and the object item is displayed based on the appropriate
appearance state (grayed out or normal).
When a user invokes a command from an object item, control or direct
manipulation of an object, a document state is modified and notification
of the event is sent to the system. This event automatically informs any
active object items and assures current status information is consistent
across the operating environment. The notification message includes the
name of the change and a pointer to the object that sent the notification
message.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1A is a block diagram of a personal computer system in accordance with
the subject invention;
FIG. 1B is a display in accordance with the subject invention;
FIG. 2 illustrates the tools used to create an application in accordance
with the subject invention;
FIG. 3 is a flow diagram of a command process in accordance with the
subject invention;
FIG. 4 a checkbox control in accordance with the subject invention;
FIG. 5 is a checkbox control activation in accordance with the subject
invention;
FIG. 6 is a checkbox update in accordance with the subject invention;
FIG. 7 is a summary of checkbox control processing in accordance with the
subject invention;
FIG. 8 an illustration of a control panel in accordance with the subject
invention;
FIG. 9 is an illustration of a dialog box in accordance with the subject
invention;
FIG. 10 is an illustration of a dialog box color controller in accordance
with the subject invention;
FIG. 11 an illustration of a radio button in accordance with the subject
invention;
FIG. 12 is a detailed flowchart of menu state processing in accordance with
the subject invention;
FIG. 13 is a picture of a display in accordance with the subject invention;
FIG. 14 illustrates the detailed logic of atomic execution in accordance
with the subject invention;
FIG. 15 sets forth the detailed logic associated with smart label
processing in accordance with the subject invention;
FIG. 16 presents the detailed logic of smart window label processing in
accordance with the subject invention;
FIG. 17 illustrates how objects are created and how the objects communicate
with each other during a typical interaction with an object that can be
moved and selected in accordance with the subject invention;
FIG. 18 is an object generating notification flowchart for a notification
source object in accordance with the subject invention;
FIG. 19 presents a flowchart illustrating the detailed logic associated
with selecting the proper user interface element in accordance with the
subject invention;
FIG. 20 is a flowchart illustrating the detailed logic associated with
scrolling in accordance with the subject invention; and
FIGS. 21A, 21B and 21C illustrate window scrolling in accordance with the
subject invention.
DETAILED DESCRIPTION OF THE INVENTION
The invention is preferably practiced in the context of an operating system
resident on a personal computer such as the IBM.RTM. PS/2.RTM. or
Apple.RTM. Macintosh.RTM. computer. A representative hardware environment
is depicted in FIG. 1A, which illustrates a typical hardware configuration
of a workstation in accordance with the subject invention having a central
processing unit 10, such as a conventional microprocessor, and a number of
other units interconnected via a system bus 12. The workstation shown in
FIG. 1A includes a Random Access Memory (RAM) 14, Read Only Memory (ROM)
16, an I/O adapter 18 for connecting peripheral devices such as disk units
20 to the bus, a user interface adapter 22 for connecting a keyboard 24, a
mouse 26, a speaker 28, a microphone 32, and/or other user interface
devices such as a touch screen device (not shown) to the bus, a
communication adapter 34 for connecting the workstation to a data
processing network and a display adapter 36 for connecting the bus to a
display device 38. The workstation has resident thereon an operating
system such as the IBM OS/2.RTM. operating system or the Apple
System/7.RTM. operating system.
The subject invention is a new object-oriented system software platform
comprised of an operating system and development environment designed to
revolutionize personal computing for end-users, developers, and system
vendors. The system is a complete, standalone, native operating system and
development environment architected from the ground up for
high-performance personal computing. The invention is a fully
object-oriented system including a wealth of frameworks, class libraries,
and a new generation object programming environment, intended to improve
fundamentally the economics of third party application software
development. The subject invention is a fully portable operating system.
Traditional operating systems provide a set of services which software
developers can use to create their software. Their programs are very
loosely integrated into the overall operating system environment. For
example, DOS applications take over the entire machine. This means that as
far as the user is concerned, the application is the operating system. In
Macintosh.RTM. and Windows operating systems, applications feel and look
similar and they typically support cutting and pasting between
applications. This commonalty makes it easier for users to use multiple
applications in a single environment. However, because the commonalty is
not factored into a set of services and frameworks, it is still very
difficult to develop software.
In the subject invention, writing an "application" means creating a set of
objects that integrate into the operating system environment. Software
developers rely on the operating system for both a sophisticated set of
services and a framework to develop software. The frameworks in the
subject invention provide powerful abstractions which allow software
developers to concentrate on their problem rather than on building up
infrastructure. Furthermore, the fundamental abstractions for the software
developer are very close to the fundamental concepts that a user must
understand to operate her software. This architecture results in easier
development of sophisticated applications.
This section describes four steps to writing software employing the subject
invention. A user contemplating the development of an application is
typically concerned with the following questions:
What am I modeling?
For a word processor, this is the text I am entering; for a spreadsheet, it
is the values and formulas in the cells.
How is the data presented?
Again, for a word processor, the characters are typically displayed in a
what-you-see-is-what-you-get (wysiwyg) format on the screen with
appropriate line and page breaks; in a spreadsheet it is displayed as a
table or a graph; and in a structured graphics program (e.g. MacDraw), it
is displayed as a set of graphics objects.
What can be selected?
In a word processing application, a selection is typically a range of
characters; in a structured graphics program it is a set of graphic
objects.
What are the commands that can operate on this selection?
A command in a word processor might be to change the style of a set of
characters to bold. A command in a structured graphic program might be to
rotate a graphic object. FIG. 1B is an illustration of a display in
accordance with the subject invention. A command is illustrated at 41 for
bringing a picture to the front of a display. A presentation of graphic
information is illustrated at 40. Finally, a selection of a particular
graphic object, a circle, is shown at 42.
A developer must answer the same four questions asked by the user.
Fortunately, the subject invention provides frameworks and services for
addressing each of these four questions. The first question that must be
answered is: What am I modeling? In a word processing program, the data
includes the characters that make up a document. The data in a spreadsheet
includes the values and formulas in the cells. In a calendar program, the
data includes the times and appointments associated with a given day. The
invention provides facilities that help to model data. There are classes
for modeling specific data types including: text, structured graphics,
sound and video. In addition to these specific classes, the invention
provides a number of other abstractions that support problem modeling,
including: collection classes, concurrency control, recovery framework,
and the C++ language. The class that encapsulates the data model for a
particular data type provides a specific protocol for accessing and
modifying the data contained in the data encapsulator, support for
overriding a generic protocol for embedding other data encapsulators and
for being embedded in other data encapsulators, generating notification to
all registered objects when the data changes, and overriding a generic
protocol for creating presentations of the data.
The next question that must be answered is: how is the data presented? In a
structured graphic program, the set of graphic objects are typically
rendered on a canvas. In a spreadsheet, it is typically a table of cells
or a graph; and in a presentation program it is a set of slides or an
outline. The subject invention provides a "view" of the data contained in
a data encapsulator. The view is created using a "view system" and graphic
system calls. However, playing a sound or video clip is also considered a
presentation of the data.
Next: what can be selected? In a word processing program, a selection is a
range of characters; in a structured graphics program, it is a set of
graphics objects; and in a spreadsheet it is a range of cells. The
invention provides selection classes for all of the fundamental data types
that the system supports. The abstract baseclass that represents a
selection made by a user provides an address space independent
specification of the data selected. For text, this would be a numeric
range of characters rather than a pair of pointers to the characters. This
distinction is important because selections are exchanged between other
machines when collaborating (in real-time) with other users. The baseclass
also overrides a generic protocol for creating a persistent selection
corresponding to this selection. Persistent selections are subclasses of
an anchor object and may be heavier weight than their corresponding
ephemeral selections because persistent selections must survive editing
changes. For example, a persistent text selection must adjust itself when
text is inserted before or after it. Anchors are used in the
implementation of hypermedia linking, dataflow linking and annotations.
The baseclass also provides an override generic protocol for absorbing,
embedding and exporting data contained in a data encapsulator. Baseclasses
are independent of the user interface technique used to create them.
Selections are typically created via direct manipulation by a user (e.g.
tracking out a range of text or cells) but can be created via a script or
as a result of a command. This orthogonality with the user interface is
very important. Baseclasses also provide specific protocol for accessing
the data encapsulator. There is a very strong relationship between a
particular subclass of the encapsulator class and its subclass of a model
selection class.
Finally: what are the commands that can operate on this selection? In a
word processing program, a command might change the style of a selected
range of characters and in a structured graphics program, a command might
rotate a graphic object. The subject invention provides a large number of
built-in command objects for all of the built-in data types as well as
providing generic commands for Cut, Copy, Paste, Starting HyperMedia
Links, Completing Links, Navigating Links, Pushing Data on Links, Pulling
Data on Links, as well as many user interface commands. The abstract
baseclass that represents a command made by the user is responsible for
capturing the semantics of a user action, determining if the command can
be done, undone, and redone. Command objects are responsible for
encapsulating all of the information necessary to undo a command after a
command is done. Before a command is done, command objects are very
compact representations of a user action. The baseclass is independent of
the user interface technique used to create them. Commands are typically
created from menus or via direct manipulation by the user (e.g. moving a
graphic object) but could be created via a script. This orthogonality with
the user interface is very important.
Benefits Of Frameworks
The benefits of plugging into the abstractions in the invention are greater
than providing a conceptual model. Plugging into the framework provides
many sophisticated features architected into the base operating system.
This means that the framework implements major user features by calling
relatively small methods. The result is that an investment in coding for
the framework is leveraged over several features.
Multiple Data Types
Once a new kind of data is implemented, the new data type becomes a part of
the system. Existing software that can handle data encapsulators can
handle your new data type without modification. This differs from current
computer systems, such as the Macintosh computer system. For example, a
scrapbook desk accessory can store any kind of data, but it can only
display data that has a text or quickdraw picture component. In contrast,
the subject invention's scrapbook displays any kind of data, because it
deals with the data in the form of an object. Any new data type that is
created behaves exactly like the system-provided data types. In addition,
the data in the scrapbook is editable since an object provides standard
protocol for editing data.
The scrapbook example highlights the advantages of data encapsulators. If
software is developed such that it can handle data encapsulators, an
application can be designed to simply handle a new data type. A new
application can display and edit the new kind of data without
modification.
Multi-level Undo
The invention is designed to support multi-level undo. Implementing this
feature, however, requires no extra effort on the part of a developer. The
system simply remembers all the command objects that are created. As long
as the corresponding command object exist, a user can undo a particular
change to the data. Because the system takes care of saving the commands
and deciding which command to undo or redo, a user does not implement an
undo procedure.
Document Saving, Reliability, and Versioning
A portion of the data encapsulator protocol deals with filing the data into
a stream and recreating the data at another place and/or time. The system
uses this protocol to implement document saving. By default, a user's data
objects are streamed to a file when saved. When the document is opened,
the data objects are recreated. The system uses a data management
framework to ensure the data written to disk is in a consistent state.
Users tend to save a file often so that their data will be preserved on
disk if the system crashes. The subject invention does not require this
type of saving, because the system keeps all the command objects. The
state of the document can be reconstructed by starting from the last disk
version of the document and replaying the command objects since that point
in time. For reliability, the system automatically logs command objects to
the disk as they occur, so that if the system crashes the user would not
lose more than the last command.
The invention also supports document versioning. A user can create a draft
from the current state of a document. A draft is an immutable "snapshot"
of the document at a particular point in time. (One reason to create a
draft is to circulate it to other users for comments.) The system
automatically takes care of the details involved with creating a new
draft.
Collaboration
As mentioned above, a document can be reconstructed by starting with its
state at some past time and applying the sequence of command objects
performed since that time. This feature allows users to recover their work
in the case of a crash, and it can also be used to support real-time
collaboration. Command objects operate on selections, which are
address-space independent. Therefore, a selection object can be sent to a
collaborator over the network and used on a remote machine. The same is
true of command objects. A command performed by one collaborator can be
sent to the others and performed on their machines as well. If the
collaborators start with identical copies of the data, then their copies
will be remain "in sync" as they make changes. Creating a selection is
done using a command object, so that all collaborators have the same
current selection.
The system uses a feature known as "model based tracking" to perform mouse
tracking on each collaborator's machine. The tracker object created to
handle a mouse press creates and performs a series of incremental commands
as a user moves the mouse. These commands are sent to collaborators and
performed by each collaborator. The result is that each collaborator sees
the tracking feedback as it occurs. The system also establishes a
collaboration policy. A collaboration policy decides whether users are
forced to take turns when changing data or can make changes freely. The
invention handles the mechanics of collaboration which removes the
responsibility from an application developer.
Scripting
Designing a system to manage the sequence of command objects also makes it
possible to implement a systemwide scripting facility. The sequence of
command objects is equivalent to a script of the local actions. The
scripting feature simply keeps track of command objects applied to any
document. The scripting facility also uses selection objects in scripts.
This feature provides customization of a script by changing the selection
to which the script applies. Since command objects include a protocol for
indicating whether they can apply to a particular selection, the system
ensures that a user's script changes are valid.
Hypermedia Linking
Persistent selections, also known as anchors, can be connected by link
objects. A link object contains references to the two anchors that form
its endpoints. To the system, the link is bidirectional; both ends have
equal capabilities. Certain higher-level uses of links may impose a
direction on the link. The single link object supports two standard
features: navigation and data flow. A user can navigate from one end of
the link to the other. Normally, this will involve opening the document
containing the destination anchor and highlighting the persistent
selection. The exact behavior is determined by the anchor object at the
destination end. For example, a link to an animation may play the
animation. A link to a database query may perform the query.
Links also facilitate data flow. The selected data at one end of the link
can be transferred to the other end to replace the selection there. In
most cases, the effect is the same as if the user copied the selection at
one end, used the link to navigate to the other end, and pasted the data.
The system takes care of the details involved with navigating from one end
of a link to the other (e.g., locating the destination document, opening
it, scrolling the destination anchor into view, etc.). Similarly, the
system handles the details of transferring data across the link. The
latter is done using the selection's protocol for accessing and modifying
the data to which it refers.
Annotations
The invention supports a system-wide annotation facility. This facility
allows an author to distribute a document draft for review. Reviewers can
attach posted notes to the document, and when done, return the document to
the author. The author can then examine the posted notes and take action
on each. (An author can also create posted notes in the document.) A
reviewer need not have the same software as the author. Instead, the
reviewer can use a standard annotation application. This application reads
the data from the author's draft, and creates an annotatable presentation
of the data. (Creating such a presentation is part of the standard data
encapsulator protocol.)
The reviewer can create selections in the document, and link posted notes
to the selection. The link between the posted note and selection allows
the system to position the posted note "near" the selection to which it
refers. The links also make the annotation structure explicit, so that the
system can implement standard commands to manipulate annotations. The
contents of the posted note can be any data type implemented in the
system, not simply text or graphics. The contents of a note is implemented
using a data encapsulator, and opening a note results in creating an
editable presentation on that data.
Data Representation
Data representation is concerned with answering the question of what is the
data that I am modeling? The subject invention provides facilities that
help to model data. There are classes for modeling specific data types,
including: text, structured graphics, sound and video. In addition to
these specific classes, the invention provides a number of other
abstractions that help to model a problem: the collection classes, the
concurrency control and recovery framework, and the C++ language itself.
In the subject invention, the class that encapsulates the data model for a
particular data type is a subclass of the encapsulator class.
The Encapsulator Class
A developer creates a container for a particular type of data
representation by creating a derived class of the encapsulator class. For
each type of data in the system, (e.g. graphic objects, styled text,
spreadsheet cells) a different derived class must exist which acts as the
container for a type's data. Each class of encapsulator provides a type
specific protocol for accessing and modifying the data contained therein.
This protocol is typically used by presentations for displaying the data
and by commands for modifying the data. In addition to type specific
protocol, the encapsulator class provides generic protocol that supports
the embedding of data encapsulators as "black-boxes" into other alien
types. This protocol must be implemented in the derived class to support
the creation of presentations, editors and selections for the encapsulated
data. A container need only understand this generic protocol to support
the embedding of any alien data type.
Choosing A Representation For Data
The data type designer has both the C++ object model, and a rich set of
standard classes to choose from when designing a representation for a
particular type of data. The classes provided by the invention should
always be considered before designing unique classes to represent the
data. This minimizes any duplication of effort which may occur by creating
new classes which provide similar or identical function to classes already
existing in the system. The most basic of these is the C++ object model. A
designer can create a class or classes which closely match the mental
model of the user to represent the classes the user deals with.
The invention's foundation classes provide many standard ways to represent
data. Collection classes provide a number of ways for collecting together
related objects in memory, ranging from simple sets to dictionaries.
Disk-based collections, providing persistent, uncorrupted collections of
objects, are also available. A data type requiring two (2D) and three
dimensional (3D) graphic modeling, such as a graphical editor, is also
supported. Numerous 2D and 3D modeling objects are provided along with
transformation, matrix classes and 3D cameras. Similarly, the invention
provides a sophisticated text data type that supports full international
text, aesthetic typography, and an extensible style mechanism. The
invention also provides support for time based media such as sound and
video. Sophisticated time control mechanisms are available to provide
synchronization between various types of time based media.
Presentation Protocol
The encapsulator class provides a protocol for the creation of various
classes of presentations on the data contained within the encapsulator.
The presentations include a thumbnail presentation, a browse-only
presentation, a selectable presentation, and an editable presentation.
There is also a protocol for negotiating sizes for the presentations and
fitting the data into the chosen size. Subclasses of the encapsulator
class are responsible for overriding and implementing this protocol to
support the embedding of the data in other encapsulators. The
presentations currently supported include:
Thumbnail--This presentation is intended to give the user a "peek" at what
is contained in the encapsulator. It is typically small in size and may
scale-down and/or clip the data to fit the size.
Browse-only--This presentation allows the user to view the data in its
normal size but the user is unable to select or modify any of the data.
Selectable--This presentation adds the ability to select data to the
capabilities provided by the browse-only presentation. It is used in
annotating to allow annotations to be tied to selections in the data
without allowing modification to the data itself. The selectable
presentation is typically implemented as a subclass of the browse-only
presentation.
Editable--This presentation adds the ability to modify data to the
capabilities provided by the selectable presentation. This is the
presentation that allows the user to create new data and edit existing
data. Currently, this presentation provides its own window for editing. It
is likely that in the future support will be added for presentations which
allow editing in place. The editable presentation is typically implemented
as a subclass of the selectable presentation.
Change Notification
When the data contained in an encapsulator class is changed, it is
necessary to provide clients (e.g. a view on the data) with notification
of the change. Encapsulators rely on a built-in class for standard
notification support to allow the encapsulator to notify clients of
changes to the data representation. A client can connect to an
encapsulator for notification on specific changes or for all changes. When
a change occurs the encapsulator asks the model to propagate notification
about the change to all interested clients.
Data Presentation
This section addresses how the system presents data to a user. Once the
data has been represented to the system, it is the role of the user
interface to present the data in an appropriate and meaningful way to a
user. The user interface establishes a dialogue between the user and the
model data. This dialogue permits a user to view or otherwise perceive
data and gives a user the opportunity to modify or manipulate data. This
section focuses on data presentation.
The User Interface
A developer creates a class to facilitate the presentation of data to
interact with a data encapsulator. By separating the data model from the
presentation, the invention facilitates multiple presentations of the same
data. Some applications, like the Apple.RTM. Macintosh Finder, already
support a limited form of multiple presentations of the same data.
Sometimes it is useful to be able to display different views of the same
data at the same time. These different views might be instances of the
same class--as in a 3D CAD program which shows four different view of the
same data. For each kind of presentation, a user was previously required
to write a view which can display the model and a set of trackers and
tracking commands which can select and modify the model.
Static Presentations
The simplest presentation type is the name of the data. The name is a text
string that indicates the data content or type. Examples include "Chapter
4", "1990 Federal Income Taxes", "To Do". Another simple presentation
type, an icon, is a small graphical representation of the data. It usually
indicates the data type. Examples are a book, a report, a financial model,
a sound or video recording, a drawing. However, they may also display
status, such as a printer that is printing, or indicate content, such as a
reduced view of a drawing. Finally, the thumbnail, is a small view of the
model data. This view may show only a portion of the data in order to fit
the available space. Examples are a shrunken drawing, a book's table of
contents, a shrunken letter, or the shrunken first page of a long
document. A browse-only presentation allows a user to view the data in its
normal size but the user is unable to select or modify any of the data.
Selectable Presentations
Selectable presentations allow a user to view, explore, and extract
information from the data. These presentations provide context: what the
data is, where the data is, when the data was. It may help to present the
data in a structured way, such as a list, a grid, as an outline, or
spatially. It is also useful to display the relationships among the data
elements, the data's relationship to its container or siblings, and any
other dependencies.
Selectable presentations may also display meta data. An example is the
current selection, which indicates the data elements a user is currently
manipulating. Another type of meta data is a hypermedia link between data
elements. The view may also indicate other users who are collaborating on
the data.
Selectable presentations are usually very specific to the type of the data.
They are made up of windows, views, and other user interface objects which
may be customized to best reflect the data type. Some examples are:
Sound recording--A control panel would facilitate an audible presentation.
Views would display the sound as a musical score or as a series of
waveforms. Views may include a sample number or time indications.
Financial model.--The model could be viewed as the set of formulas and
other parameters. It could display values from the model at a particular
instance of time or with specific input values as a spreadsheet or in
various graphical forms.
Book.--The model could be viewed as a table of contents, an index, a list
of illustrations. It could be viewed as a series of pages, a series of
chapters, or a continuous text flow.
Video recording--The model could be viewed as a series of individual frames
or as a continuous presentation. Views may include track marks, frame
number, and time indications.
Container containing other objects--The objects could be displayed
alphabetically by name, by type or other attribute, as a set of icons, as
a set of thumbnails.
Editable Presentations
Editable presentations are similar to interactive presentations except that
they also facilitate data modification. They do this by allowing
direct-manipulation of the data with the mouse or other pointer. They also
allow the data to be manipulated symbolically through menu items and other
controls.
Data Access
Presentations interact with data encapsulators in order to determine the
data and other information to present. Presentations query the model for
the data that is required. The presentation may present all or only part
of the data that is contained or can be derived from the data in the data
encapsulator.
Change Notification
Because there can be many presentations of a single model active at once,
the data can be changed from many sources, including collaborators. Each
presentation is responsible for keeping itself up to date with respect to
the model data. This is accomplished by registering for notification when
all or a portion of a model changes. When a change occurs to data in which
the presentation is interested, the presentation receives notification and
updates its view accordingly. Change notification can be generated in any
of the ways listed below. First, change notification can be generated from
the method in the data encapsulator which actually changes the model data.
Second, change notification can be generated from the command which caused
the change. As mentioned earlier, there are benefits to these two
approaches. Generating the notification from within the data encapsulator
guarantees that clients will be notified whenever the data changes.
Generating the notification from the command allows "higher-level"
notification, and reduces the flurry of notifications produced by a
complicated change.
NOTIFICATION FRAMEWORK OVERVIEW
The Notification framework provides a mechanism for propagating change
information between objects. The framework allows objects to express
interest in, and receive notification about changes in objects on which
they depend. A standard interface is provided for classes that provide
notification to clients. Notifier classes provide notification source
objects with the means to manage lists of clients and dispatch
notifications to those clients. Notifier objects require no special
knowledge of the class of objects receiving notifications. Connection
objects provide the dispatch of notifications from the notifier to
specific notification receiver objects. These connection objects allow
specialization of how notifications are delivered to different classes of
receivers. Finally, Notification objects transport descriptive information
about a change, and interests describe a specific notification from a
notification source object.
NOTIFICATION PROPAGATION FLOW CHART
FIG. 18 is an object generating notification flowchart for a notification
source object. Processing commences at terminal 1800 and immediately
passes to function block 1810 where a notification receiver object creates
a connection to itself. Then, at function block 1820 the notification
receiver object adds appropriate interests for one or more notifications
from one or more notification source objects. These interests are defined
by the notification source object(s).
The client object asks the connection object to connect to the notification
source(s) for notifications specified by the interests in the connection
in function block 1830. Then, in function block 1840, for each interest in
connection, the connection is registered as interested in the notification
with the notifier in the interest. Next, at function block 1845, the
system enters a wait state until a change is detected. When a system
change occurs, control immediately passes to 1850 where a notification
source object changes and calls notify on its notifier with a notification
describing the change.
For each connection registered with the notifier as interested in the
notification, at function block 1860, the connection is asked to dispatch
the notification. In turn, at function block 1870, the connection
dispatches the notification to the appropriate method of the notification
receiver. Finally, at function block 1880, the notification receiver takes
the appropriate action for the notification, and a test is performed at
decision block 1885 to determine if another connection is registered with
the notifier as interested in notification. If there is another
connection, then control passes to 1850. If there is not another
connection to service, then control passes to function block 1845 to await
the next change.
Data Specification
Data specification addresses the selection issue of data processing. If a
user must manipulate data contained in a representation, the data must be
able to specify subsets of that data. The user typically calls this
specification a "selection," and the system provides a base class from
which all selection classes descend. The invention also provides selection
classes for all of the fundamental data types that the system supports.
Model Selection
The object which contains the specification of a subset of data in a
representation is a model selection class. In the case of a text
representation, one possible selection specification is a pair of
character offsets. In a structured graphics model, each shape must be
assigned a unique id, and the selection specification is a set of unique
ids. Neither of the specifications point directly at the selection data
and they can be applied across multiple copies of the data.
Accessing Specified Data
A selection understands the representation protocol for accessing and
modifying data and knows how to find data in a local address space.
Command objects access a representation's data through data selection, and
therefore require no knowledge of converting from specification to the
real data in the local model. It is the job of the selection object to
provide access to the real data from the address space independent
specification. In a text encapsulator, this processing may require
querying the encapsulator for the actual characters contained in a range.
In a base model such as a graphical editor the selection will typically
hold surrogates for the real objects. The encapsulator must provide a
lookup facility for converting the surrogate to the real object.
Standard Editing Protocol
The model selection class provides a protocol for the exchange of data
between selections. By implementing the protocol for type negotiation,
absorbing, embedding and exporting data, derived classes provide support
for most of the standard editing commands. This means that the editing
commands (Cut, Copy, Paste, Push Data, etc.) provided by the system will
function for the represented data type and will not require
reimplementation for each application. The model selection class also
provides support directly for the exchange of anchors and links but relies
on the derived class's implementation of several key methods to support
the exchange of the representation's data:
CopyData must be implemented by the derived class to export a copy of the
specified data. The implementation creates and returns a new data
encapsulator of the requested type containing a copy of the specified
data.
AdoptData must be implemented by the derived class to support absorbing or
embedding data into the specification's associated representation. If the
data is to be absorbed it must be of a type which can be incorporated
directly into the receiver's representation. The absorbed data is added to
the representation as defined by the specification. It is common for many
data types to replace the currently specified data with the newly absorbed
data. Any replaced data is returned in a data encapsulator to support
Undo. If the data is to be embedded, the encapsulator is incorporated as a
black box and added as a child of the representation.
ClearData must be implemented by the derived class to delete the specified
data from the associated representation. An encapsulator of the
representation's native type containing the deleted data must be returned.
User Interface
The user interface for creating specifications is typically the
responsibility of a presentation on the data. A number of mechanism are
available depending on data type and presentation style. The most favored
user interface for creating a selection is direct manipulation. In a
simple graphics model, objects may be selected by clicking directly on the
object with the mouse or dragging a selection box across several objects
using a mouse tracker. In text, a selection may be created by as the
result of a find command. Another common way that selections are created
is as | | |
