||||||||l|lll|Illllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
`US005564048A
`
`United States Patent
`
`n91‘
`
`Eick et al.
`
`[11] Patent Number:
`
`5,564,048
`
`[45] Date of Patent:
`
`Oct. 8, 1996
`
`[54] OBJECT-ORIENTED FUNCTIONALITY
`CLASS LIBRARY FOR USE IN GRAPHICS
`PROGRAMMING
`
`Emily Leinfuss, “Managing Class Libraries Takes Disci-
`pline”, Software Magazine, vol. 13, No. 2, Jan. 15, 1993, pp.
`15-19.
`
`[75]
`
`Inventors: Stephen G. Eick; Paul J. Lucas, both
`of Naperville; Graham J. Wills, Lisle,
`all of I11.
`
`[73] Assignee: Lucent Technologies Inc., Murray Hill,
`NJ.
`
`[21] Appl. No.: 260,133
`
`[22]
`
`Filed:
`
`Jun. 15, 1994
`
`Int. Cl.6 ...................................................... G06F 17/30
`[51]
`[52] U.S. Cl.
`........................ .. 395/600; 395/700; 395/155;
`395/156; 395/157; 364/282.3; 364/674;
`364/977.2; 364/DIG. 2
`[58] Field of Search ................................... .. 395/600, 700,
`395/375, 650, 155, 156, 157, 158, 159,
`160, 161
`
`[56]
`
`References Cited
`U. S. PATENT DOCUTVIENTS
`
`5,220,500
`5,379,432
`5,404,529
`5,446,902
`
`............................. 364/408
`6/1993 Baird et al.
`....... ..
`395/700
`1/1995 Orton et al.
`
`4/1995 Chernikoifet al.
`345/700
`8/1995 Islam ..................................... .. 395/700
`
`FOREIGN PATENT DOCUMENTS
`
`2661525 10/1991
`
`France .
`
`OTHER PUBLICATIONS
`
`Anonymous, “The World of 0-0”, Computer Conference
`Analysis Newsletter, No. 296, Mar. 17, 1992, p. 4.
`Korson et al., “Understanding Object-Oriented: a Unifying
`Paradigm”, Communications of the ACM, vol. 33, No. 9,
`Sep., 1990, pp. 40-60.
`Olferman et al., “Objects to the Rescue”, Personal Work-
`station, vol. 3, No. 6, Jun., 1991, pp. 50-53.
`
`Allen Holub, “Visual C++: Its Compiler, Language Imple-
`mentation and Code Quality”, Microsoft Systems Journal,
`vol. 8, No. 6, Jun., 1993, pp. 65-75.
`Steve Mann, “The Beta Programming Language: an 0-0
`Language With Simula Roots”, Dr Doob ’s Journal, vol. 18,
`No. 11, Oct., 1993, pp. 56-63.
`Ted Faison, “Putting the Owl 2.0 Class Library for Windows
`Through Its Paces”, Microsoft Systems Journal, vol. 9, No.
`2, Feb., 1994, pp. 45-62.
`'
`“Class Libraries for user interface managment”, Gonzalez,
`R. E., Collegiate Microcomputer, Nov. 1992, USA, vol. 10.
`No. 4, ISSN 0731-4213, pp. 233-238.
`“Zinc Interface Library”, Entsminger, G., Computer Lan-
`guage, Dec. 1990, USA, vol. 7, No. 12, ISSN 0749-2839,
`pp. 73-74, 76.
`
`Primary VExaminer-Thomas G. Black
`Assistant,Examiner—Paul R. Lintz
`Attorney, Agent, or Firrn—Gordon E. Nelson
`
`[57]
`
`ABSTRACT
`
`A library of C++ classes for use in writing data visualization
`programs. The library embodies a general design principle
`for classlibraries: that the classes are partitioned into entity
`classes and functionality classes. Entity classes in the library
`specify properties of areas in a display and the functionality
`classes specify functionalities which the areas may have, for
`example, being responsive to the mouse or the keyboard or
`being capable of executing drawing commands. The classes
`are narrowly defined, and when the C++ programmer speci-
`fies a class for an object, he or she can give the object exactly
`the desired properties by selecting from among the area
`classes and the functionality classes. Because properties are
`acquired by inheritance, code generated using the libraries is
`shorter and faster than code generated using conventional
`class libraries.
`
`12 Claims, 5 Drawing Sheets
`
`ENTITY CIASSES 201
`
`FUNCTIONALITY CLASSES 203
`
`
`
`
`
`T
`
`CLASS
`LIBRARY
`21 1
`
`OBJECT SPEC
`105(N)
`
`GOOGLE-1005
`
`1
`
`GOOGLE-1005
`
`

`
`U.S. Patent
`
`Oct. 8, 1996
`
`'
`
`Sheetl of5
`
`5,564,048
`
`103 (3)
`—————
`
`y£_19z
`
`5
`
`F!C.
`
`7
`
`CIASS
`SPEC
`
`L~.4o5
`
`"F161"
`
`OBJECT SPEC
`1D5(A)
`
`‘°-5(9)
`
`103
`
`105
`
`
`
`COMPILER
`107
`
`
`
`
`
`FUNCTIONALITY CLASSES 203
`
`FUN. SPEC
`207(A)
`
`II
`
`'
`E
`EI
`I
`
`Fla
`
`2
`
`ENTITY CLASSES 201
`ENT.
`SPEC
`205(A)
`
`OBJECT cuss
`srfzc
`
`209
`
`3 i
`
`OBJECT SPEC
`105(N)
`
`2
`
`

`
`U.S. Patent
`
`Oct. 8, 1996
`
`Sheet 2 of 5
`
`5,564,048
`
`an
`
`:.m
`
`E:.,EamaEx~>
`
`3%:9~>
`
`Rm
`
`fimgomm~>
`
`mzazmx~>
`
`.M2552;5% %_
`.1M\
`M2555;
`
`Rm
`
`l-1-wmw......--
`
`gamma:9$32;§8;
`
`an
`
`an
`
`Smso~>
`
`ozisa~>
`
`3%
`
`m6E
`
`..._<m~>
`
`525
`
`E355~>
`
`02.3%._o~>
`
`5%
`
`3
`
`
`
`
`
`

`
`U.S. Patent
`
`Oct. 8, 1996
`
`Sheet 3 of 5
`
`5,564,048
`
`FIG.
`
`4
`
`E FLOAT rrxr
`
`KALA NAG, which means Black Snake, had served the indian
`government
`in every way fhai an elephant could serve if for
`forty-seven years, and as he was fu||y fwenfy years old when he
`was caught, fhai makes him nearly seven’ry- a ripe age for an
`elephant. He remembered pushing, wiih
`
`407
`
`401
`
`FIG.
`
`5
`
`V2 DRAWING
`
`AREA 59
`
`FLOAT DRAW
`
`
`CLASS
`
`
`4
`
`

`
`U.S. Patent
`
`Oct. 8, 1996
`
`Sheet 4 of 5
`
`5,564,048
`
`FIG,
`
`(toy) - a text house:
`Float
`Graham J. Hill: (guills8resea:ch.att.com)
`
`Copyright ATET. All rights resetved
`
`Oinclude <string.h>
`tinclude <stream.h>
`
`linclude <avecto::h>
`Iinclude <cha::ca:.h>
`603
`Iinclude <vz/app.h>
`linclude <Vt/dtlvl-h> 605
`einclude <vz/d:ave:.h>807
`Oinclude <vz/mouse.h> 509
`static Vzcolor BACK, DRAHC, HIGHC:
`
`611
`.
`
`// Intelligent vectors
`// Intelligent stzings
`// Main window and initialization
`// An acea for drawing into
`// Drawing code
`// Mouse handling
`// Colocs
`
`class Floetbrau : public Vzbtavinghrea,
`public Vzntaver,
`public Vznouseable I
`
`public:
`
`613
`
`rloatD:av(VzNativeObject H)
`: VzD:ewingA:ea('Ploat', H),
`VzHouseable(VzAll),
`v:Functionality(thie)
`(
`I
`
`// Parent object is this
`// rhis is a drawing area
`// Han: all mouse motion:
`// Annoying C++ zequixement
`
`515
`‘
`
`fig]
`
`// Do tile match
`void Readri1e(cha: -name. char 'match);
`// All drawing areas must be eble to draw themselves
`viztual void Do:xpoee( int 1.
`int t,
`int n,
`int h ):
`
`517
`619
`
`// all nouaeables must be able to handle click:
`viztual void Doflouaet Vzuouaehctiona,
`int, vznativesvent const' ); 621
`private:
`AutoVecto:<Chaxst:ing> ln;
`AutoVector<ahorc> lnlen:
`Autovector<chax> lnnat:
`int naxlen:
`¢nr cwid;
`
`// Lines of text
`ll Their length:
`// A match?
`/I Haximum length
`// flidth of each column
`
`.
`
`Reads tile and peztozma matching
`void FloatD:aw::Read3ile(cha: ‘name, char 'match)
`‘
`ifatzeam tllnamn);
`
`,
`
`int maxlen - 0:
`
`char bu££er[9900]:
`. foztint line: - O: £l.getline(bu££ez, 9000);
`(
`
`line: ++)
`
`625
`
`lntlinea] - ‘butter ? buffer :
`
`“ ";
`
`// Blank lines become “
`
`"
`
`// width in pixel:
`lnlentlines} - Measurestringtbuttez);
`if (ln1en[1ines] > mexlen) maxlen - lnlen[1ines];
`lnmatllinesl - (chat)
`(stcstzlbuffez, match)
`5- 0):
`
`) v
`
`{
`
`oid Floetbrau::Do£xpoae(int,int,int,int)
`
`int ht - Height()-20:
`cwid I (Width()-20 + 2)/(1 + ln.Count()/ht) - S:
`if lcflid < 3) cwid - 3;
`
`int x - 10, y I 10:
`for (int i-0;
`i<ln.Count();
`I
`
`i++, y++)
`
`625
`
`if ( i 56 !(i\ht)) (
`x +- 5+cWid:
`y - 10:
`
`I P
`
`o:eColo:(lnmat[i]
`DrauLine( x, y,
`x+cHid'ln1eh[i)/maxlen. y):
`
`? HIGHC : DRANC):
`
`// choose appzopzinte ea or
`
`5
`
`

`
`U.S. Patent
`
`Oct, 8, 1996
`
`Sheet 5 of 5
`
`5,564,048
`
`FIG.
`
`(36
`void Floatbrau::DoMouso(VzMousaActions what,
`I
`
`in: wid - Hidth()-20:
`int ht - Height()-20:
`
`int x - MouseX()
`
`- 10; Y - MouseY()
`
`- 10;
`
`int which, VzNativ¢Event coast‘)
`
`Fo:aColo:(E:a:oover):
`Fi11Roc:(0, 0, width(), Hoight()):
`
`// Erase in-overlay layer
`
`return:
`II y < 0)
`it (x < 0
`if (x > vid [I y > ht) zocurn:
`
`// House outside area
`
`int at - x/(cHid+5)
`in: on - x/(cH1d+5I
`it (at < or at - 0;
`it (on >- Ln.Count()) on - 1n.Counc()-1:
`
`* ht + y-5;
`' ht + y+5:
`
`// Got start and and line:
`//
`to be drawn
`
`527
`
`int proceed - (which--1);
`int D381 ' lnlinllnl:
`I
`to: (in: 1-3::
`i<an: ++i)
`if (1n1an[i] > maxi) maxi i lnlenfil:
`if (lnmattil) pxocood - 1:
`
`// Shall we draw?
`// Max length £0: shown line:
`
`// Always draw if match
`
`1 i
`
`f (!p:ocoId) totuzn:
`
`// Calculate drawing position
`y - y+15 - 6'(an-st):
`12 (y + 12'(on-at) > Hai9ht()-10) y - Haiqhtt)-10-12'(an-3:):
`x - x+1O - mnxl/2;
`it (x+naxl > H1dth()-10) x - Hidth()
`it (x<1) x - 1:
`
`- maxl - 20:
`
`rorcco1o:(DznvOva:):
`I
`to: (i-st: 1<-an: ++i)
`Draws::inq(x. Y.
`(cons: chat -)
`y +- 12:
`
`// Draw text
`
`into overlay
`
`ln[i]):
`
`FIG.
`
`GD
`
`maxnxxnc azgc, cnar "a:qv)
`
`‘CV96: I!9V):631 // Start up application
`'PP(‘Float';
`V35PP1i€l¥1°“
`rloacbzav d:av(app.primoobjact);
`535
`// Pu: "draw" in main window
`d:Iv.R0IdFi1¢(Ir9VI2J. Izqvtll): 534
`// Read the data
`Vzcolor cola:
`// Allocate colors
`dxav.A11acColots(3,
`
`icola, rave;
`
`2- 3 )
`
`629
`
`'Bllck"):
`d!Iv.HlpCOlOt(BACK-cOl3++.
`'G:oy20');
`d:aw.MapColor(DRAHC-col:++,
`d:av.Hapcolo:(HIGHC-cola,
`'31ua'):
`drav.HapAl1ovazlays("White"):
`d:au.BackColo:(lACK):
`
`// Define cclozs
`
`rututn app.Go(); 539
`
`// co:
`
`6
`
`

`
`5,564,048
`
`1
`OBJECT-ORIENTED FUNCTIONALITY
`CLASS LIBRARY FOR USE IN GRAPHICS
`PROGRAMMING
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`
`The invention concerns object-oriented programming sys-
`tems generally and more particularly concerns libraries for
`use in object-oriented graphics programming.
`2. Description of the Prior Art
`Graphical user interfaces have made computer systems far
`easier to use. In a typical graphical user interface, the display
`is divided into one or more windows. Each window corre-
`sponds to an activity being carried on by the user of the
`system, and the user can manipulate the windows and theft
`contents by means of a pointing device such as a mouse
`and/or the keyboard. A system with a graphical user inter-
`face is easier to use than a system with the old command-line
`interface because there is no need for the user to remember
`commands and file names and type them in or to remember
`the context in which he is working. Instead,
`the entire
`context is visible in the display, and the user simply uses his
`pointing device to select items on the display and thereby to
`specify the desired operation.
`An important class of graphical user interfaces is graphi-
`cal user interfaces used to visualize data. For example, a
`program may permit the user to investigate how one or more
`sets of statistics are associated with states in the United
`States. The graphical user interface for the program consists
`of a map of the United States and a selector bar in which
`values of a statistic are mapped to colors. When the mouse
`is used to select an area of the selector bar, the states for
`which the statistic is in the selected range(s) take on the
`color corresponding to the value of the statistic for the state.
`Such a graphical user interface is disclosed in S. G. Eick, J.
`L. Steffan and E. E. Sumner Jr. “Seesoft—A Tool For
`Visualizing Line Oriented Software Statistics”, IEEE Trans-
`actions 0n Software Engineering, vol. 18 #11, November
`1992
`
`While a graphical user interface is easier to use than the
`old command-line interface, programs with graphical user
`interfaces are far larger and more complex than programs
`written for the old command-line interface. Developing
`programs with graphical user interfaces thus takes longer,
`the programs require more storage space, and fast execution
`requires a more powerful processor.
`Computer scientists have dealt with the problems of
`programming for the graphical user interface in two ways:
`by developing libraries of components of graphical user
`interface programs and by using object-oriented program-
`ming systems to write graphical user interface programs.
`When a library of components is available, the programmer
`can use components from the library in his program, and
`thus avoid having to write and debug them himself. An
`example of such a library of components is the X Window
`Tool Kit, which is part of the the X Window System,
`produced by the X Consortium ( X Window System is a '
`Trademark of the Massachusetts Institute of Technology).
`The system is described in 0. Jones, Introduction to the X
`Window System Prentice Hall, 1989
`Object-oriented programming systems employ program-
`ming languages which permit the definition of objects. An
`object is simply an entity which is manipulated by the
`program. Each object has a class, which defines all of the
`operations which are permitted on the object. There are
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`objects with built-in classes and objects whose classes are
`defined by the programmer. For example, an integer variable
`is an object with the built-in integer class. The operations of
`the integer class include addition, subtraction, multiplication
`and the modulus operation, but not division, since division
`may not have an integer result. The programmer may define
`his own classes in terms of the built-in classes and other
`previously-defined classes.
`In defining a class, the programmer specifies how each of
`the operations for the class is to be performed. For example,
`a programmer may define a class whose objects are win-
`dows. Operations for objects having such a class may
`include making and destroying the window, exposing the
`window on the display, resizing the window, and clearing the
`window, and the programmer must specify how each of
`these operations is to be performed.
`two
`Object-oriented programming systems provide
`important advantages: first, the entities which the program
`manipulates (for example, windows) appear directly in the
`program, so the program is both easier to write and easier to
`understand. Second, the class definitions permit the pro-
`gramming system to detect many programming errors which
`would otherwise only come to light when the program
`malfunctioned. An example of such an object-oriented pro-
`gramming system is the C++ language and compiler, as
`described in Stanley B. Lippman, C++ Primer, 2nd edition,
`Addison-Wesley Publishing Co., Reading, Mass., 1991.
`Of course, libraries may be used in object-oriented pro-
`gramming systems. Existing libraries such as the X Window
`Tool Kit mentioned above may be adapted for use in
`object-oriented programming systems and C-l-l- libraries for
`programming graphical user interfaces have also been devel-
`oped. A commercially—availab1e example of such a library is
`the the XVT Portability Toolkit from XVT Software Inc.
`Existing libraries for programming graphical user inter-
`faces are useful, but have a number of difliculties. First, they
`provide the programmer with a collection of predefined
`classes, rather than permitting the programmer to define his
`own classes. Second, because the classes are predefined,
`they must be general purpose. Each class must have many
`operations and a given operation must deal with many
`situations. As a result, the classes are hard for the program-
`mer to understand, the code for the operations is long and
`complex, and execution is relatively slow. Third, as complex
`as the operations are, they often still do not exactly fit what
`the programmer wants to do, and only limited tailoring is
`possible. This drawback is particularly important when the
`programmer is designing truly new graphical user interfaces,
`such as those used in data visualization, instead of imple-
`menting variations on existing graphical user interfaces.
`Fourth, libraries and programming tools are generally pro-
`vided as packages, and consequently, different libraries and
`tool sets are frequently incompatible. Finally, none of the
`existing libraries is well adapted to producing graphical user
`interfaces for visualizing data.
`It is an object of the invention disclosed herein to provide
`a solution to these and other difficulties of existing libraries
`for programming graphical user interfaces.
`
`SUMMARY OF THE INVENTION
`
`The invention solves the foregoing problems by means of
`a library of C++ classes called Vz. The classes in the library
`fall intotwo categories: area classes, which specify a kind of
`area of the display, and functionality classes, which specify
`functionalities which may be added to an object having one
`
`7
`
`

`
`5,564,048
`
`3
`of the area classes. Any user-defined class which inherits one
`of the library’s area classes may also inherit any of the
`library’s functionality classes. Each functionality class
`specifies only a small set of closely-related functionalities.
`Consequently,
`the properties of an object representing a
`display area such as a window may be precisely defined by
`inheriting only those classes which specify the needed
`functionalities.
`
`For example, one of the area classes provided by V2 is is
`VzDrawingArea, which defines a window for which no kind
`of content has yet been defined. One of the functionality
`classes is VzMouseable, which provides the functionality of
`responding to mouse inputs. An object which has a class that
`has inherited both VzDrawingArea and VzMousable would
`thus represent a window which was responsive to mouse
`inputs.
`the division of the
`As is apparent from the foregoing,
`classes in the V2 library into area classes and narrowly-
`defined functionality classes and the use of inheritance to
`define object classes permits objects to be precisely defined
`for the task at hand. Only those functionalities that are
`needed need be inherited, and changes in functionalities can
`be accomplished simply by Changing the inheritance.
`The
`combination of narrowly-defined functionality
`classes and inheritance is further easier to understand than
`the complexities of prior-art library classes. Moreover, the
`code for the object will include only the coder required for
`the object’s inherited area classes and functionality classes,
`and will thus generally be smaller and execute more quickly
`than that of objects made using classes from prior-an library
`systems. Finally, the classes of the library may be inherited
`along with classes defining objects used in particular graphi-
`cal user interfaces, and consequently, there are no compat-
`ibility problems like those with prior-an libraries.
`The approach described above for graphics libraries may
`be generalized. Class libraries for any prograrnrrring area
`may be divided into entity classes which specify the kinds of
`entities represented by the objects and functionality classes
`specifying functionalities which may be provided to the
`entities. The kinds of entities and the functionalities will of
`course depend on the application area.
`The foregoing and other objects and advantages of the
`invention will be apparent to one of ordinary skill in the art
`who pcruscs the following Drawing and Detailed Descrip-
`tion, wherein:
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`FIG. 1 is a block diagram of an object-oriented program-
`ming system;
`FIG. 2 is a block diagram of how a library made according
`to the techniques of the invention may be used to specify an
`object’s class;
`FIG. 3 is a diagram of the classes of the V2 library and
`their relationships to each other;
`FIG. 4 is a window produced by an example program
`made using the library;
`FIG. 5 is a block diagram of the class inheritance of the
`object which represents the window;
`FIG. 6A is a portion of the code of the example program;
`FIG. 6B is another portion of the code of the example
`program;
`
`FIG. 6C is a third portion of the code of the example
`program; and
`
`4
`
`FIG. 6D is a fourth portion of the code of the example
`program.
`
`The reference numbers employed in the Drawing and the
`Detailed Description have three or more digits. The two least
`significant digits are a number within a figure; the remaining
`digits are the figure number. Thus,
`the element with the
`reference number “305” is first shown in FIG. 3.
`
`10
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`DETAILED DESCRIPTION
`
`The following Detailed Description will begin with an
`overview of object-oriented programming systems gener-
`ally, will then provide an overview ofthe principles of the
`invention and of the V2 library and an example of how
`classes from the library may be used in writing a graphics
`program, and will conclude with detailed descriptions of the
`library’s classes.
`Object-Oriented Programming Systems: FIG. 1
`FIG. 1 is a block diagram of an object-oriented program-
`ming system 101 being used to produce code for a graphical
`user interface. Object-oriented programming system 101
`includes a compiler 107 for an object-oriented programming
`language which produces object code 109 for CPU 111.
`When CPU 111 executes code 109, the execution results in
`outputs 123 to display 113. In response to these outputs,
`display 113 produces window 115. A user of CPU 111 may
`employ keyboard 117 and/or mouse 119 to provide inputs to
`window 115. As shown by arrow 121, these inputs go to
`CPU 111, where they atfect the execution of code 109, and
`consequently may result in changes to window 115. The
`execution of code 109 may thus be interactive, that is, a user
`responds to the contents of window 115 with an input from
`keyboard 117 or mouse 119, which in turn changes the
`appearance of window 115. The change may of course result
`in a further input from the user. In a preferred embodiment,
`the object-oriented programming language is C-l—|-, compiler
`107 is the Unix Software Laboratories (USL) C++ compiler,
`running on an Iris Indigo (Silicon Graphics Inc.) with 64
`MBytes memory, system software version 5.2. The code
`generated by the compiler is for the above Silicon Graphics
`system.
`Because compiler 107 is a compiler for an object-oriented
`language, the source code from which compiler 107 pro-
`duces code l09 contains object specifications 105 and class
`specifications 103, as shown by the arrows 103 and 105
`indicating inputs to compiler 107. Every object must have a
`class, and consequently, each object specification 105 must
`include a reference to a class specification 103. Class
`specifications 103 may in turn be defined in terms of one or
`more other classes. The class defined by a given class
`specification 103 is said to inherit the classes used in its class
`specification 103. A class which does not inherit any other
`class is termed a base class.
`
`The above relationships are represented in FIG. 1 by the
`dotted arrows 106 connecting class specifications 103 and
`class specifications 103 to object specifications 105. Thus,
`class specification 103(d), which specifies the class of the
`object specified by object specification 105(a), inherits the
`classes specified by class specifications 103(c) and 103(a).
`Both of these class specifications specify base classes.
`Inheritance may of course go back more than one “genera-
`tion”. Thus specification 10S(b)’s class specification 103(2)
`may inherit the class defined by class specification 1030’),
`which in turn inherits the class defined by specification
`103(1)). Here, class specification 103(b) specifies a base
`class.
`
`8
`
`

`
`5,564,048
`
`5
`As already mentioned, an object’s class determines what
`operations can be performed on the object. The operations
`themselves are specified by means of function specifications
`in the class specifications 103. In C~t+, there are two kinds
`of function specifications: virtual function specifications 102
`and ordinary function specifications 104. An ordinary func-
`tion specification 104 specifies an interface for the operation
`and also contains code for doing the operation. A virtual
`function specification only specifies the interface. Code for
`doing the operation must be provided in a separate ordinary
`function 104, and different class specifications 103 which
`inherit a class having a virtual function may have different
`ordinary functions 104 for the virtual function. The only
`requirement is that all of the ordinary functions 104 have the
`interface specified for the virtual function 102. If there is an
`ordinary function 104 for a virtual function 102 in the class
`specification which defines the virtual function, the ordinary
`function 104 is a default. If another class inherits the class
`with the virtual function and does not have its own ordinary
`function 104 for the virtual function, it inherits the default
`ordinary function. The virtual function thus permits the
`programmer to define operations of an inherited class as
`required for a particular application of the class.
`An example of the above is provided by the Vz library’s
`class VzMouseable, which includes a virtual
`function
`DoMouse. The virtual function interface defines how infor-
`mation concerning the behavior of the mouse is passed to
`code 109, but does not define what action is taken in
`response to the information. A class which inherits VzMou-
`seable must provide an ordinary function 104 for DoMouse.
`For example, the ordinary function 104 might provide that
`if the mouse is used to select a portion of the text on display
`in a window,
`the selected portion is highlighted in the
`display and saved for use in a later operation such as moving
`or deleting the text.
`A Class Library Organized According to the Invention: FIG.
`2
`
`As mentioned above, many of the class specifications 103
`in an object-oriented programming system 101 may be
`provided by a class library. FIG. 2 is a diagram of a class
`library 211 organized according to the principles of the
`present invention. Class library 201 includes two kinds of
`class specifiers: those for entity classes 201 and those for
`functionality classes 203. The class specifiers for entity
`classes 201 define classes which specify the object as a
`thing, for example, a window 115 which has a certain form
`and kind of content. An example of such an entity class in
`the V2 library is VzDrawingArea, which is a class for a
`window whose kind of content is as yet unspecified. (The
`kind of content can be added by inheriting another entity
`class which inherits VzDrawingArea.) The class specifier
`205 for that class includes virtual functions 102 for actions
`to be taken in response to an expose or resize event involv-
`ing the window and ordinary functions 104 for actions to be
`taken when the window itself is created, destroyed, exposed,
`or resized.
`
`The class specifiers 207 for functionality classes 203
`define functionalities which may be provided to the entities
`defined by the entity classes 201. For example, in V2, the
`functionality class VzMouseable provides the functionality
`of responding to a mouse. Thus, using the principles of class
`library 211,
`the class of an object which represented a
`window 115 that had to respond to input from a mouse could
`be defined by inheriting VzDrawingArea and VzMouseable.
`Of course, the class for the object would have to provide
`ordinary functions 104 for any virtual functions 102 for
`which no ordinary functions 104 had been inherited or for
`which diiferent ordinary functions were required.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`The dotted lines 105 in FIG. 2 show how the inheritance
`works. Object class specification 209 defines the class of the
`object specified in object specification 105(n). Class speci-
`fication 209 inherits entity class 205(c) and functionality
`class 207(b) from class library 211. In the class library of the
`preferred embodiment, an object class specification 209
`which inherits from any of the entity classes 201 defined by
`class library 211 can inherit any and any number of the
`functionality classes 203 defined by class library 211.
`As the dotted lines show, inheritance is also used to define
`classes within class library 211. Entity class 205(d) inherits
`both the class specified by entity class specifier 205(b) and
`the class specified by functionality class specifier 207(a),
`that is,
`the entity class specified by functionality class
`specifer 205(d) has the functionality specified by function- .
`ality class specifer 207(a). Similarly,
`the 10 functionality
`class specified by functionality class specifier 207(b) inherits
`the functionality class specified by specifier 207(a) and
`includes all the functionality defined for both classes.
`An Example Class Library 211: FIG. 3
`In a preferred embodiment, the principles of class library
`211 are embodied in the V2 class library for data visualiza-
`tion. FIG. 3 shows the classes of Vz library 301 and their
`relationship to each other. Area Classes indicated by solid-
`line rectangles 304 are entity classes 201; each of these
`classes specifies that an object which inherits the class
`represents a particular kind of window 115; classes indicated
`by ovals are functionality classes 203; each of these classes
`specifies a functionality in an object whose class inherits the
`functionality class and one of the area classes. The classes
`indicated by dotted rectangles 302 are graphics engine
`classes which define objects representing graphics engines.
`As indicated by dashed arrow 317, the graphics engines
`actually perform the operations specified by VzDrawer
`functionality class 323.
`In the following, each of the classes of library 301 will be
`described in overview, beginning with VzFunctionality class
`327 and those functionality classes 306 which inherit from
`it. A detailed description of each class may be found at the
`end of the present application.
`Functionality Classers 306
`The class at the top of the hierarchy of functionality
`classes 306 is VzFunctionality 327. The class specifies a data
`member which is a pointer to an object whose class has
`inherited a functionality class 306. The constructor for the
`class sets the pointer, and there is a function which checks
`whether there actually is such an object. This class is
`inherited by all of the functionality classes.
`Continuing with VzColorManager 321, this functionality
`class specifies the functionality needed to control the use of
`colors in an area of a display 113. Operations added by this
`class include allocating colors, mapping colors to a scale of
`values, overlaying colors, turning colors off and on, and
`establishing foreground and background colors.
`VzColorManager 321 is in turn inherited by VzDrawer
`323, a functionality class which gives an area object the
`ability to respond to drawing commands. Added operations
`include outputting the area as a Postscript file, doing double
`buffering, convening between coordinate systems, specify-
`ing fonts and measuring the size of strings, and doing
`drawing operations such as drawing points, lines, rectangles,
`ovals, polygons, filling polygons, and the like.
`VzGC 321 is a class which gives an area object the ability
`to specify a graphics context of the kind required by the
`graphics system which provides the graphics primitives for
`program 109. The class essentially serves to “wrap” a class
`from library 301 around a graphics context object provided
`by the graphics system.
`
`9
`
`

`
`5,564,048
`
`7
`
`VzMouseable 335 is a class which’ provides an area object
`with the ability to respond to input from a mouse. The
`constructor establishes which types of mouse input will
`cause the methods of this class to be called, such as mouse
`clicking only, or clicking and dragging or all mouse motion.
`There are operations for getting and setting which types of
`mouse input will trigger a response, and there is a virtual call
`back function for specifying how the area object
`is to
`respond to input from the mouse.
`VzKeyable 339 is a class which provides an area object
`with the ability to respond to input from the keyboard. The
`constructor establishes a data structure for storing keyboard
`state, there are added operations for getting and setting the
`keyboard state, and there is a virtual call back function for
`specifying how the area object is to respond to input from
`the keyboard.
`The last functionality class 306 is VzKeyDispatcher 341,
`which inherits VzKeyable 339. This class provides an area
`object with the ability to define how it responds to input
`from the keyboard. Keys may be mapped to ordinary func-
`tions 104, and when a key is depressed, the function 104 to
`which it is mapped is executed. The constructor makes a
`map, and other added operations include mapping keys to
`functions and saving and restoring keymaps. One use for this
`functionality class is to permit a user to edit text in a window
`using the keystrokes for the user’s favorite text editor.
`Area Classes 304
`The area classes define operations on areas such as
`windows, sliders, buttons, menus, and so on in display 113.
`In many graphical user interface systems, these areas are
`represented by native objects provided by the graphical user
`interface system. For example, if the underlying system is
`the X Window System, then the native objects will be X
`Window widgets. A native object is made to behave like an
`object which inherits the area classes of the V2 library by
`“wrapping” an object which does inherit the area classes
`around the native object. Such objects are termed herein Vz
`objects.
`The base class for the area classes is VzObject class 303.
`Class 303 permits a Vz object which inherits the class to be
`wrapped around a native object. Data for the class is a
`pointer to the native object. Operations include the follow-
`mg:
`allocation and deletion operations for both creating a V2
`object by itself and creating a native object and wrapping
`the Vz object around it and deleting the Vz object and any
`native object it is wrapped around;
`Operations which return pointers to the Vz object and the
`native object,
`Operations which return information about the object hier-
`archy to which the native object belongs;
`Operations which get and set the dimensions of the area
`represented by the native object; and
`F