Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
1996-10-29
2002-08-27
dela Torre, Crescelle N. (Department: 2174)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C709S241000
Reexamination Certificate
active
06441833
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention concerns object-oriented programming systems in general and object-oriented programming systems for generating graphical displays in particular.
2. Description of the Prior Art
Sharp declines in the cost of memory and processing power has made it possible for even low-cost computer systems to provide graphical user interfaces to their users. In typical systems with graphical user interfaces, the display is divided into a number of windows of varying sizes. Some of the windows show the output of programs being executed for the user; others display icons, menus, buttons, sliders, and the like. The user of the system can employ a pointing device such as a mouse to control the operation of the system by selecting icons or menu items or operating buttons or sliders and can employ a keyboard to input characters to windows.
While a graphical user interface makes it easier for a user to work with a program, the graphical user interface adds substantially to the program's complexity, and therefore to the difficulty of writing the program. Efforts to simplify the task of writing programs involving graphical user interfaces have led to the development of systems for programming graphical user interfaces. An example of such systems is the X Window System, described in Robert W. Scheifler, James Gettys, and Ron Newman,
X Window System, C Library and Protocol Reference
, Digital Press, 1988, and in Paul J. Asente and Ralph R. Swick,
X Window System Toolkit
, Digital Press, 1990(X Window System is a trademark of the Massachusetts Institute of Technology).
FIG. 1
shows a computer system
101
which employs the X Window System. The hardware components of computer system
101
are processor
121
, memory
103
, display
131
, keyboard
137
, and mouse
139
. Mouse
139
controls the position of pointer
133
in display
131
. Processor
121
is executing an application process
109
which is executing an application program
110
. Application program
110
is displaying two windows
135
, window
135
(
a
) and window
135
(
b
) in display
131
. During execution, data and instructions flow between memory
103
and processor
121
, as indicated by arrow
119
and outputs to display
131
flow from processor
121
to display
131
, as indicated by arrow
123
. Inputs flow from keyboard
137
and mouse
139
to processor
121
as indicated by arrows
125
and
129
.
Application program
10
has been implemented using the X Window System; consequently, program
110
has four major components: application code
111
, the specific code for the application program, and three components of the X Window System: widgets
113
, Intrinsics
115
, and XLIB library routines
117
. The XLIB library routines are what actually cause windows and their contents to appear in display
131
; when an XLIB library routine is executed by processor
121
, processor
121
sends a message specifying an operation on display
131
to another component of the X Window System, server process
105
, which executes X server code
107
. Server process
105
responds to the message by performing the actual operations which produce the windows
135
in display
131
. Server process
105
further detects events such as inputs from mouse
139
or keyboard
137
and sends messages specifying the events to application process
109
, which responds to the event messages by executing callback functions (CBF)
112
code in application code
111
.
While XLIB library routines can be invoked directly by application code
111
, the library routines are still too low-level to permit easy programming of graphical user interfaces. To deal with this difficulty, the X Window System has provided programmers with a toolkit for programming in the system. Intrinsics
115
and widgets
113
belong to the toolkil
FIG. 2
is an overview of a widget
201
. Functionally, widgets
201
mediate between application code
111
and X server code
107
. When application code
111
wants to change the state of a window associated with a widget, application code
111
writes values in the widget; in response to the change, widget
201
performs actions which result in messages being sent to X server
107
to change the state of the window. When X server code
107
receives an event concerning a window, X server code
107
sends the event to the widget
201
for the window. Widget
201
then performs the actions required for the event. Among the actions may be invocation of a callback function
112
. Once a class of widgets has been defined, any application program to which the definition of the class is available may create and use widgets belonging to the class.
Widgets
201
are compiled objects. An object is a data structure and a set of functions which represent an entity manipulated by a computer program. The data structure represents the state of the entity. Some of the functions permit the program to write and read parts of the data structure; others of the functions respond to changes in the data structure. The functions associated with an object determine how the object behaves and thus determine the object's class (type). The classes of widgets
201
are hierarchical. If a class is below another class in the hierarchy, it inherits the characteristics of the class above it, and widgets belonging to the class have the inherited characteristics as well as those particular to its own class.
A compiled object is an object whose class and data structures are defined at compile time, that is, when the code which describes the object is compiled. Objects may also be interpreted; with such objects, the class and data structures of the object are defined at run time, that is, when the program using the object is executed. Compilation permits better type checking and more efficient code generation than interpretation, and consequently, systems using compiled objects are generally more efficient and have fewer bugs than systems using interpreted objects; however, compiled objects are generally less flexible. When a compiled object is created and used at run time, the values contained in the object's data structures may vary, and what happens when a function is executed may depend on the values in the data structures, but the data structures and functions themselves cannot change. In terms of widget
201
, the fact that widget
201
is a compiled object means that widget
201
can be used only to represent the kind of window
135
corresponding to the widget's class, not to represent any window.
Returning to the details of widget
201
, the hierarchy of classes appears in
FIG. 2
as superclass field
203
, which contains the name of the class of which widget
201
is a subclass. Widget
201
inherits all of the functions of the class specified in field
203
, which inherits all of the functions specified for its superclass, and so on. Class
205
is the name of the widget's own class.
Methods
207
are functions which define the widget's class. All widgets belonging to a class employ the same methods
207
to carry out the operations which define the class. The methods may either be defined specifically for the class or inherited from classes higher up in the hierarchy. For example, windows are often hidden and exposed again in the course of operation of a windowing system, and consequently, most widget classes have methods which specify what is to be done when a window
135
associated with a widget belonging to the class is exposed. When a specific window is exposed, the widget for that window uses the expose method for its class to redraw the window. Of course, redrawing the window may require the method to call X functions in Intrinsics
115
and/or XLIB
117
.
Resources
209
are values in widget
113
which represent the state of the widget. What resources a widget
113
has is determined by its class. The values of the resources are of course determined at run time. Both application code
111
and routines in methods
207
can read and set values in resource
Anderson John Scott
Blewett Charles Douglas
dela Torre Crescelle N.
Lucent Technologies - Inc.
Oliff & Berridge
LandOfFree
Dynamically specifying invocations in compiled objects does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamically specifying invocations in compiled objects, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamically specifying invocations in compiled objects will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2898320