Automatic interface layout generator for database systems5353401Abstract An automatic interface layout generator for database systems is disclosed herein. The automatic generator includes a specification tool for specifying a set of block descriptions representative of specified portions of a database. A block layout generator produces interface objects to be included within an interface of the database, wherein each of the interface objects corresponds to one of the block descriptions and includes a plurality of layout fields. A layout quality parameter is determined for each of the interface objects based on arrangement of the layout fields within the interface objects. A block placement generator arranges sets of the interface objects into block configurations within the interface. A placement quality parameter for each of the block configurations is derived based on a set of block placement rules and on the layout quality parameters, and a final block configuration is selected by comparing the placement quality parameters corresponding to particular block configurations. Claims What is claimed is: Description The present invention relates generally to layout planning systems for interface displays, and particularly to automatic methods and systems for generating user interface layouts.
______________________________________
Menu BDF
<operation 1>
<operation 2>
.
.
<operation N>
Data BDF
<entity.sub.-- name>
<field.sub.-- name.sub.-- 1> <type> <width> <height> <label>
<field.sub.-- name.sub.-- 2> <type> <width> <height> <label>
. . .
<field.sub.-- name.sub.-- M> <type> <width> <height> <label>
Relationship BDF
<relationship.sub.-- name>
<label> <width> <height> <cardinality>
<field.sub.-- name.sub.-- 1> <type> <width> <height> <label>
<field.sub.-- name.sub.-- 2> <type> <width> <height> <label>
. . .
<field.sub.-- name.sub.-- P> <type> <width> <height> <label>
______________________________________
There exists a unique menu BDF for each database structure specified using the interface specification tool 129. Similarly, the number of data and relationship BDFs associated with a specified database corresponds to the number of entities and relationships represented in the database schema generated using the specification tool 129. Since the interpreter module relies on information within the dictionary of the parent database (e.g., FIG. 2) in order to create the block description files 130 corresponding to the database selected using the specification tool 129 (e.g., FIG. 3), the manner in which the BDFs are synthesized may be more readily explained by making reference to the structure of such a database dictionary. Accordingly, FIG. 6 illustratively represents the structure of a typical database dictionary. An explanation of each of the records included within the dictionary of FIG. 6 is set forth below:
______________________________________
Directory
One record is created for each directory.
Id Directory number
Name Directory name
Parent Parent directory number
Area Default value for the area number
of the UNIX directory under which
files related to the database are
created.
Primary key (Id)
Secondary key (Parent, Name)
Database
One record is created for each database.
Id Database number
Name Database name
Parent Parent directory number
Note Comments
Area Default value for area in which
files related to this database
are created.
Primary key (Id)
Secondary key (Parent, Name)
Record
One record is created for each record type.
Id Record type number
Name Record type name
Parent Database number
Note Comments
File Record file number
Heap Heap file number
Key Array of field numbers comprising
primary key
Primary key (Id)
Secondary key (Parent, Name)
Field
One record is created for each field.
Id Field number
Name Field name
Parent Record type number
Note Comments
Order The logical field number within
the record
Type Encoded data type
Dim Number of elements in array
Offset Field position within record
Init Test representation of initial
value
Integ Integrity information
Null0k Allows or disallows null values.
Primary key (Id)
Secondary keys
(Parent, Name)
(Parent, offset)
Index
One record is created for each index.
Id Index number
Parent Record type number
Note Comments
File Index file number
Key Array of field numbers comprising
keys
Unique Allows or disallows duplicates.
Primary key (Id)
Secondary keys
(Parent)
(Key)
RLink
One record is created for each real-link type.
Id Real-link type number
Name Link name (null value for unnamed
inverse link types)
Parent Database number
Note Comments
File Real-link file number
Inverse Inverse link type number
Term Terminal record type number
Intog Integrity information
Primary key (Id)
Secondary keys
(Parent, Name)
(Term)
(Inverse)
VLink
One record is created for each virtual-link type.
Id Virtual-link type number
Name Link name (null value for unnamed
inverse link types)
Parent Database number
Note Comments
Inverse Inverse link type number
Term Terminal record type number
Termkey Array of field numbers comprising
key of terminal table
Integ Integrity information
Primary key (Id)
Secondary keys
(Parent, Name)
(Term)
(Inverse)
Area
One record is created for each area in which files
are created.
Id Area number
Name Absolute pathname within UNIX
filesystem
Primary key (Id)
Secondary key (Name)
File
One record is created for each file.
Id File number
Name Logical name of file (does not
match UNIX file name)
Parent ID number of the area in which
file is stored
Object ID number of the record type,
index or real-link type this file
defines
Db Database number
Type Classification as sequential file
or B-tree, and as fixed length or
variable length
FkSize Number of bytes in fixed-length
key section
VkSize Number of bytes in
variable-length key section
FvSize Number of bytes in fixed-length
data section
Vvsize Number of bytes in
variable-length data section
Primary key (Id)
Secondary keys
(Parent)
(Db)
User
One record is created for each user.
Id User number
Name User name
Type Classification as UNIX user, UNIX
group member or as user
administered solely by GraphBase
using password
Osid UNIX user number of group number
Passwd Encoded password
Primary key (Id)
Secondary keys
(Type, Name)
(Type, Osid)
Access Permissions
One record is created for each permission granted.
User User number
Object Access object number
Type Type of access indicated using
bit pattern
Primary key (User, Object)
Secondary key (Object, user)
Statistics
One record is created for each access object.
Object Access object number
Ctime Date and time that data
definition was first made for
access object.
Mtime Date and time that data
definition was last made for
access object.
Acount Array containing number of times
processing was carried out for
each access type.
Primary key (Object)
______________________________________
The database dictionary of FIG. 6 includes the following virtual links between the indicated records to facilitate queries made by the interpreter module during generation of the block description files 130: DirectoryDirectory Sub-directories belonging to directory DirectoryDatabase Sub-databases belonging to directory DatabaseRecord Record types belonging to database RecordField Record fields belonging to record type RecordIndex Indexes belonging to record type DatabaseRLink Real link types belonging to database DatabaseVLink Virtual link types belonging to database RecordRLink Real links connected to record type RecordVLink Virtual links connected to record type RLinkRLink Inverse link type corresponding to real-link type VLinkVLink Inverse link type corresponding to virtual-link type RecordFile Record file corresponding to record type IndexFile Index file corresponding to index RLinkFile Link file corresponding to real-link type AreaFile Files belonging to file area UserAccessRight Access rights belonging to user DirectoryAccessRight Access rights to directory DatabaseAccessRight Access rights to database RecordAccessRight Access rights to record type FieldAccessRight Access rights to field RLinkAccessRight Access rights to real-link type DirectoryStatistics Statistical information pertaining to directory DatabaseStatistics Statistical information pertaining to database RecordStatistics Statistical information pertaining to record type FieldStatistics Statistical information pertaining to field IndexStatistics Statistical information pertaining to index RLinkStatistics Statistical information pertaining to real-link type VLinkStatistics Statistical information pertaining to virtual-link type AreaStatistics Statistical information pertaining to file area FileStatistics Statistical information pertaining to file UserStatistics Statistical information pertaining to users. The interpreter module creates the menu, data and relationship block description files 130 by retrieving certain information from the database dictionary. The following pseudocode routines are representative of a particular manner in which the block description files 130 may be synthesized:
______________________________________
Menu BDF Generation
For each <op> in the Operations Table (FIG. 5)
if <selected?>=`y`
output <op.sub.-- name>
Data BDF Generation
For each <entity> in the Entity List (FIG. 4)
output <entity>, label
for each <attribute> in the Attribute List of <entity>
1) retrieve <type> <dim> from the Field table in
the Data Dictionary
2) output <attribute> label <type> <dim>
Relationship BDF Generation
For each <relationship> in the Relationship List
output <relationship>, label
output <relationship>, entity.sub.-- x
output <relationship>, entity.sub.-- y
output <relationship>, Cardinality
______________________________________
Methodology of Interface Generation Referring to FIG. 7, there is shown a functional block diagram representative of a preferred manner of generating an interface layout in accordance with the present invention. As shown in FIG. 7, a set of block description files 130 are generated by the interpreter module in accordance with a data structure defined by the specification tool 129. A set of interface object blocks for each block description file 130 are then created by the block layout generator 134 by varying the arrangement, spacing and graphical representation of data fields included within the object blocks. Each data field is defined by a segment of graphics software hereinafter denoted as a widget. Each interface object block has associated therewith a "quality" parameter based on predefined block configuration guidelines and constraints related to the selection and location of widgets within the object block. Guidelines are formulas which yield various scores used in computing the quality parameter, while constraints describe conditions which must be satisfied if a particular design is to be considered acceptable. Typical constraints include "two fields may not overlap", "the width and height must not exceed the space allocated", and "the number of fields within the object block must be less than N". FIG. 8 is a block diagrammatic representation of the components comprising the block layout generator 134. The layout generator 134 operates to create the set of interface object blocks corresponding to each block description file 130 based on information included within a corresponding set of templates 180. Each template 180 is a data structure which includes information enabling the generation of multiple interface object blocks. More specifically, each template 180 includes a Representation Section which assigns each data field within the object block to a particular widget class (e.g., Text, ScrolledText, Scale, Button). Attributes associated with each widget class (e.g., font size, dimensions, color) are defined within a Local Attributes Section. The Local Attributes Section also includes information relating to the size of the margins between the perimeter of the object block and the data fields, the spacing between data fields, and the like. The placement of data fields within each object block is performed in accordance with a Layout Plan stored within each template 180. For example, the Layout Plan included within a particular template 180 may specify that the data fields within a first object block associated with the template be arranged in a single column, that the data fields be arranged in two columns in a second object block, that the data fields be arranged in three columns in a third object block, and so on. In a preferred implementation each of the templates 180 will be structured as follows:
______________________________________
/* Representation section */
<obj.sub.-- 1> <widget.sub.-- type>
<obj.sub.-- 2> <widget.sub.-- type>
<obj.sub.-- N> <widget.sub.-- type>
/* Local attributes */
FontSize = #;
FontStyle = [P,B,I];
/* P=plain, B=bold,
I=italic */
UperMargin = ##; /* separation between the
upper border and topmost
widget */
LowerMargin = ##; /* separation between the
lower border and the
lowermost widget */
LeftMargin = ##; /* separation between the
left border and the
lowermost widget */
RightMargin = ##; /* separation between the
right border and the
rightmost widget */
FieldSeparation = ##;
/* distance between
fields */
FieldLabelSeparation = ##;
/* distance between a
field and its label */
ColumnSeparation = ##;
/* distance between
columns */
/* Layout plan */
<function>
______________________________________
Each template 180 is defined in a separate file. As is described more fully below, the template files are read and interpreted by a configuration generator 184 (FIG. 8). With the exception of the Layout Plan, the values of each parameter within a template file can be independently modified. In a preferred embodiment each Layout Plan will be written in C-code, then compiled and linked into software included within the configuration generator 184. A set of Layout Plans included within preferred implementations of the templates 180 are set forth below: ##SPC1## FIG. 9A shows an example of a template 180 which, together with a block description file 130, are utilized by the layout generator 134 to produce a set of three object blocks (FIGS. 9B-9D). In the example of FIG. 9A, the Layout Plan denoted as `column.sub.-- split ({1,2,3})` includes instructions specifying that each of the data fields (e.g., Name, Age, Street, . . . ) within the object block of FIG. 9B be configured in a single column, and that the data fields within FIGS. 9B and 9C be arranged in a pair of columns, and in multiple columns, respectively. As is indicated by FIG. 8, the configuration generator 184 utilizes the set of available templates 180 in order to create the set of object blocks associated with a particular block description file 130. In a preferred embodiment the configuration generator 184 operates to create several object blocks for each template 180 in accordance with the associated Layout Plan. Information relating to the set of object blocks corresponding to each of the block description files 130 is stored within a widget file 186. The widget file 186 specifies the location and type, i.e., widget type, of the data included within the object blocks defined by the widget file 186. The configuration generator 184 appends to the widget file 186 the object block information generated in response to the processing of each block description file 130. The following pseudocode routine is representative of a preferred manner in which the set of object blocks corresponding to one of the block description files (BDFs) 130 are generated by the configuration generator 184: For each BDF For each template For each field Generate a widget description using the information provided in the Representation Section of the template and the characteristics of the field included within the Data Dictionary. For example, the "Name" field within the template of FIG. 9A is assigned the widget TextField(N), where TextField is the type of widget associated with the descriptor "Text" and the value N is the length of the field defined in the Data Dictionary. Call the layout routine specified in the Layout Plan section of the template. The format of the widget file 186 is as follows:
______________________________________
<block.sub.-- description.sub.-- 1>
<widget.sub.-- description.sub.-- 11>
<widget.sub.-- description.sub.-- 12>
. . .
<widget.sub.-- description.sub.-- 1M.sub.1 >
<block.sub.-- description.sub.-- 2>
<widget.sub.-- description.sub.-- 21>
<widget.sub.-- description.sub.-- 22>
. . .
<widget.sub.-- description.sub.-- 2N.sub.2 >
<block.sub.-- description.sub.-- N>
<widget.sub.-- description.sub.-- N1>
<widget.sub.-- description.sub.-- N2>
. . .
<widget.sub.-- description.sub.-- NM.sub.N >
______________________________________
where <block.sub.-- descriptor.sub.-- X> denotes the Xth object block defined by the widget file 186, and where <widget.sub.-- description.sub.-- K> refers to the Kth data field within a given object block. Each <block.sub.-- descriptor.sub.-- X> is of the form:
______________________________________
<internal.sub.-- name> <configuration.sub.-- id>
<number.sub.-- of.sub.-- widgets>
______________________________________
The format of <widget.sub.-- description.sub.-- K> depends on the type of widget used to represent the associated data field. For example, the widget type defining a data field represented as a menu button is of the following format:
______________________________________
<t.sub.-- up>
<t.sub.-- down> <t.sub.-- left> <t.sub.-- right> <b.sub.-- up>
<b.sub.-- down> <b.sub.-- left>
<b.sub.-- right> <label>
______________________________________
where {<t.sub.-- up> <t.sub.-- down>} determine the position of upper and lower horizontal lines and <t.sub.-- left> <t.sub.-- right>} specify the position of left and right vertical lines which define the smallest rectangle capable of surrounding the label of the menu button icon. Similarly, {<b.sub.-- up> <b.sub.-- down> <b.sub.-- left> <b.sub.-- right>} define the rectangular button icon itself. The character string within <label> corresponds to the label identifying the button icon, e.g. INSERT. The following listing corresponds to a portion of a widget file 186 defining the object blocks (i.e., Menu, PREVIOUS TEAMS and PLAYER) depicted in FIG. 10.
__________________________________________________________________________
M*DESCR/MENU
0000
3
00012
00048 00012
00124
00008
00052
00008
00128
Retrieve
00068
00104 00026
00110
00064
00108
00008
00128
Update
00124
00160 00040
00096
00120
00164
00008
00128
Exit
T*DESCR/XXX01
0000
4
0052
0082 0002
0079
0052
0082
0083
0303
02*Name
0084
0114 0002
0079
0084
0114
0083
0127
02*From
0116
0146 0002
0079
0116
0146
0083
0127
02*To
0148
0178 0002
0079
0148
0178
0083
0138
02*Average
T*DESCR/XXX02
0000
7
0052
0082 0002
0090
0052
0082
0094
0314
02*Name
0084
0114 0002
0090
0084
0114
0094
0149
02*Age
0116
0146 0002
0090
0116
0146
0094
0314
02*Street
0148
0178 0002
0090
0148
0178
0094
0259
02*City
0180
0210 0002
0090
0180
0210
0094
0193
02*Zip
0212
0242 0002
0090
0212
0242
0094
0105
02*Photo
0244
0274 0002
0090
0244
0370
0094
0369
__________________________________________________________________________
02*Comments
The values in the widget file 186 are utilized by a constraint and guideline evaluator 190 to determine the value of a quality parameter indicative of the extent to which the arrangement of fields within a particular block comports with predefined guidelines and constraints. Included within a preferred set of guidelines upon which this quality evaluation is based are: (1) wasted space (WS), where WS=.SIGMA. widget.sub.-- area(i)/block area where block area corresponds to the area of the minimum rectangle capable of enclosing each of the data fields within the object block while maintaining a specified margin offset between each data field and the border of the minimum enclosing rectangle. (2) balance (B) of the fields within the object block, where B is computed by (i) dividing the block area into four quadrants, and (ii) comparing the area covered by the fields in each quadrant with the expected field coverage in a perfectly balanced layout, i.e. .SIGMA. widget-area(i)/4. (3) cursor movement (C), where C corresponds to the sum of the distance, i.e., number of display pixels, between the last position of field Fi and the first position of field Fi+1. Each guideline will preferably be implemented using object-oriented code (e.g., C++), and may be defined as a function of the form:
______________________________________
score function (block.sub.-- descriptor,
{widget.sub.-- descriptors}).
______________________________________
A set of constraints preferably used by the evaluator 190 include: (1) Fields cannot overlap, (2) the width of the block cannot exceed W, and (3) the height of the block cannot exceed H, where W and H are constants determined by the dimensions of the display area of display unit 128. Constraints may also be defined in terms of functions. However, constraint functions are formulated to return a value of zero if the constraint is satisfied and a value of K if the constraint is violated. K may be chosen to be arbitrarily large in order to guarantee that object block violating the constraint will not be considered during the block placement procedure described below. The quality (QI) of the Ith object block evaluated by the guideline and constraint evaluator 190 is determined in accordance with the following weighted sum: QI=.SIGMA.Sg(i)W(i)+Sc(i) where Sg(i) corresponds to the score of the ith guideline, Sc(i) corresponds to the score of the ith constraint, and .SIGMA. W(i)=1. The value of QI is inversely proportional to the degree to which the layout of an object block agrees with the set of guidelines and constraints. In addition, the values of the weighting coefficients W(i) are selected on the basis of the relative importance of each guideline to a desirable data field arrangement. The constraint and guideline evaluator 190 also determines values of global attributes (Ai) for each object block (e.g., width, height, font.sub.-- size, color). The values of Ai, together with the values of the associated quality parameters QI, are placed in a block file 194 organized as follows:
______________________________________
<block.sub.-- 1> <attr.sub.-- 1> <attr.sub.-- 2> <attr.sub.-- 3>. . .
<attr.sub.-- N> <QI>
______________________________________
Referring again to FIG. 7, the block placement routine 136 includes an initial block placement generator 210 for arranging a set of object blocks in an initial configuration. Each block description file 130 is represented by a single object block within the set of object blocks selected by the initial placement generator 210, which are stored within an initial block placement file 214. As is described below, during the block placement process other object blocks representative of a particular description file 130 may be substituted for the block initially chosen by the initial placement generator 210. Such substitutions will be made in accordance with a placement procedure effected by the final block placement generator 218 (FIG. 7), which is designed to optimize the final placement of blocks within the interface. The final block placement generator 218 operates to arrange a set of object blocks into an interface layout in accordance with an iterative improvement heuristic known as simulated annealing (see, e.g., S. Kirkpatrick, C. D. Gelatt and M. P. Vecchi, "Optimization by Simulated Annealing," Science, Vol. 20, No. 4598, May 1983, pp. 671-680). The simulated annealing procedure is based on the use of a probability function to randomly move through a solution space. In the present instance, the solution space corresponds to every potential arrangement within the database interface of a set of object blocks corresponding to the specified set of block description files 130. Subsequent to each iteration the "quality" of the solution is compared with that corresponding to the solution obtained during the previous iteration. In general, a new solution is accepted only if it represents an improvement over a prior solution. However, in order to avoid being constrained to the solution space proximate a local minimum the simulation annealing function accepts certain inferior solutions. The following pseudo-code is descriptive of the simulated annealing procedure:
______________________________________
Simulated Annealing
Initialize;
placement = GenerateInitialPlacement;
cost = Evaluate(placement);
while(loop.sub.-- count<MAX.sub.-- ITERATIONS and temperature >
MIN.sub.-- TEMPERATURE)
new.sub.-- placement = Perturb(placement)
new.sub.-- cost=Evaluate(new.sub.-- placement);
if (Accept(new.sub.-- placement, new.sub.-- cost, temperature))
placement=new.sub.-- placement;
cost=new.sub.-- cost;
loop.sub.-- count++;
temperature=NewTemperature(loop.sub.-- count);
return(placement, cost);
______________________________________
Referring to FIGS. 11A-C, in a preferred embodiment a slicing tree data structure is used to represent the block placements manipulated by the initial and final block placement generators 210 and 218. In particular, the leaves of the slicing tree structure of FIG. 11A represent the object blocks included within the block placement (configuration) of FIG. 11B. The interior nodes of the slicing tree are indicative of horizontal and vertical cuts which separate the interface layout into a configuration of adjacent rectangles. Information stored in memory locations corresponding to each leaf node includes the geometry and size of the corresponding object block, as well as a justification code describing the position of the object block within the rectangle formed by the surrounding cuts. FIG. 11C shows one set of acceptable justifications of an object block relative to the rectangle defined by the surrounding cuts. In a preferred implementation the following convention is used to interpret the left and right children of a horizontal (H) node: the left child of a horizontal node is always located above the right child. Similarly, the left child of a vertical (V) node is always to the left of the right child. The initial placement generator 210 will preferably be implemented so as to execute the GenerateInitialPlacement function in a manner resulting in the initial object block placement depicted in FIGS. 12A and 12B. In the arrangement of FIG. 12A there is included in the interface one object block corresponding to each of N block description files 130. The N object blocks are arranged in a vertical stack, with the corresponding sliced tree data representation being depicted in FIG. 12B. As is indicated by the pseudo-code description of the simulated annealing procedure given above, a perturbation step is performed prior to the evaluation conducted during each iteration. The purpose of this perturbation step is to produce a variation of the current placement by applying operations to alter its structure. The Perturb function for implementing this step is structured as follows:
______________________________________
Perturb(placement)
OP=SelectOperation;
if (BlockCount(OP)=1
B1=SelectBlock;
OP(B1);
else
B1=SelectBlock;
B2=SelectBlock;
OP(B1,B2);
______________________________________
where B1 and B2 are object blocks included within a current configuration of object blocks within the interface. SelectOperation and SelectBlock are random functions (using a uniform probability distribution), while BlockCount is a function that determines the number of object blocks affected by the one of the following OP operations:
______________________________________
Replace(b)
substitutes a second object block for object
block b.
Swap(b1,b2)
interchanges the position of two blocks b1 and b2,
Move(b1,b2)
places a block b1 next to block b2
______________________________________
FIGS. 13A and 13B depict changes occurring to a block configuration as a consequence of execution of the Replace operation. Similarly, FIGS. 14A-B and 15A-B depict the effects of the Swap and Move operations. The following sequence of steps may clarify the manner in which the Move operation is implemented: 1. Remove b1 and its parent from the tree. 2. Connect b1's sibling to its grand parent. 3. Disconnect b2 from the tree and connect it to b1's parent. 4. Reconnect b1's parent to the tree at the location where b2 was removed. The final block placement generator 218 implements the simulated annealing procedure by computing a cost evaluation function C(i), where C(i) corresponds to the "cost" of the block configuration existing after the ith perturbation operation. Four cost components are considered when determining the value of the cost evaluation function Evaluate: C1=.SIGMA.(BQ(i)/N) where BQ(i) is the quality score assigned to the ith of N object blocks included within the current configuration (placement) of object blocks within the interface; C2=Placement Wasted Space (PWS), where PWS is a recursive function that traverses the placement tree in order to determine the difference between the size of each block and its allotted area. C3=V if a placement constraint is violated and zero otherwise, where V is selected to be large enough to guarantee that the current placement will not be accepted. C4=.SIGMA.(G(i)/M), where G(i) is the guideline score associated with the ith object block configuration, and M is the number of placement guidelines. These factors are then combined by the final block placement generator 218 in the following manner in order to determine the cost Ci of the block configuration existing after the ith iteration of the simulated annealing procedure: C=C1W1+C2W2+C3W3+C4W4 where .SIGMA.Wi=1. The cost Ci is the value returned by the function Evaluate. In a preferred implementation of the simulated annealing procedure outlined above block configurations resulting in a cost reduction are always accepted. In addition, block configurations which result in cost increases are accepted with a probability that decreases over time. This aspect of the annealing procedure may be described by an acceptance function (Ac) of the form: Ac=e.sup.-.DELTA.C/Ti where .DELTA.C is the difference in cost between the previous and current block configurations, and Ti corresponds to a "temperature" of the ith iteration. The temperature function is defined as: Ti+1=.alpha.(T)*Ti where .alpha.(T) is a function that returns a real value in the range (0,1) when called. In a preferred embodiment the function .alpha.(T) is a step function of the type typically utilized in applications involving the simulated annealing procedure. As is indicated by the pseudo-code representation of the simulated annealing procedure set forth above, the block placement generator 218 produces a final block configuration after either: (i) a predefined number (MAX.sub.-- ITERATIONS) of iterations have been executed, or (ii) the temperature Ti becomes less than the temperature MIN.sub.-- TEMPERATURE. The final block configuration is then stored within the final block placement file 140. Referring to FIG. 16, there is shown a block diagrammatic representation of a particular implementation of the display code generator and compiler 122. Although the implementation of FIG. 16 is described with reference to the User Interface Language (UIL) developed by the Open Software Foundation, Inc., it is understood that in alternative embodiments other user interface languages may be utilized. A UIL code generator 300 produces UIL code on the basis of the final block configuration stored within the final block placement file 140. This UIL code describes characteristics of GUI widgets selected as on-screen representations of the interface objects. Such GUI widgets may be selected from among those included within, for example, the OSF/Motif user environment developed by the Open Software Foundation, Inc. The UIL code is merged with a series of application-independent UIL statements, denoted as fixed UIL code 310, which results in a complete UIL program. This UIL program is then processed by a UIL compiler 320 so as to yield UID code stored in display code memory 144. This display code is used by the interface driver 146 (FIG. 1) to generate the interface layouts displayed by the display unit 128. While the present invention has been described with reference to a few specific embodiments, the description is illustrative of the invention and is not to be construed as limiting the invention. Various modifications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims.
|
Same subclass Same class Consider this |
||||||||||