A presentation has a name, and a prototype presentation from which the newly defined presentation inherits information (defined via the is_like link). In addition, a presentation has parameters to define its visual appearance (visual_parameters), its layout (layout_parameters), options (primitive_parameters) and parameters that define the application data to be presented (data_parameters).
The replications are used to specify whether a presentation that is used as a part of another presentation should be replicated many times, in order to present variable amounts of data. The conditionals specify alternative ways of adjusting a presentation depending on the current context.
The visual parameters are used to specify the visual appearance of a presentation. The values of these parameters can be fonts, colors, etc. (see definition of Visual_Parameter).
The layout parameters are used to specify the layout of a presentation. The values of these parameters can be Guides and Grids.
The primitive parameters are used to specify various options of a presentation whose values are primtive values such as integers, strings, booleans, etc. (see definition of Primitive_Parameter).
The data parameters are used to specify the data to be displayed in a presentation.
The parts of a presentation are other presentations, so that presentations are defined as a hierarchy of presentations.
A sequence of replications, each (if any) corresponding to a different part of the presentation, defining a replication for these parts (see documentation on Replication).
The conditionals support the specification of alternative presentations depending on characteristics of the data being displayed, or on characteristics of the display, such as the amount of space available. Conditionals can override any element of the specification where they appear (e.g., the position of grids, the prototype for a part), and can also add and remove parts.
Color models colors of graphical objects. All colors must be modeled as sub-classes of Color: RGB_Color, HSV_Color and Named_Color.
RGB_Color models colors in the Red/Green/Blue format.
A real number between 0 and 1.
A real number between 0 and 1.
A real number between 0 and 1.
HSV_Color models colors in the Hue/Saturation/Value format.
A real number between 0 and 1.
A real number between 0 and 1.
A real number between 0 and 1.
Named_Color models colors by giving their name. Note: this method of modeling colors might be machine dependent.
The name of the font, e.g., Helvetica.
The set of styles available for this font. The value of this attribute must be a subset of all the elements of the Font_Style enumeration.
The particular style of this font (e.g., italic).
The size of the font in points. Note: if on a given platform the requested size is not available, and the system will substitute another font.
The color of the font.
Whether the text should be underlined.
Specified whether the grid is vertical of horizontal.
The distance between gridlines. The distance between two particular gridlines can be overriden explicitly by specifying exceptions.
If the grid is stretchable, the distance specified here refers to the distance when the grid is not stretched. The actual distance of stretchable grids can vary at run-time depending on how much the grid is stretched.
The number of lines in the grid.
If the grid is not stretchable, then this attribute can be ommitted, and the number of grid lines is computed based on the start and end of the grid: as many gridlines are defined as necessary to span the distance between start and end.
The location of the first grid line. This location can be a constant, or a Magnitude expression that depends on a guide or application data of a presentation. Typically, the expression is just a reference to a guide, which causes the grid to start at the location of the guide.
If the grid is not stretchable, then this attribute can be ommitted, and it will be computed based on the num_lines and end attributes.
The location of the last grid line.
If the grid is not stretchable, then this attribute can be ommitted, and it will be computed based on the num_lines and start attributes.
A stretchable grid is one where the distance between the gridlines will be adjusted so that the number of grid lines specified in num_lines can be placed between start and end. Space is proportionally divided between grid spaces, taking into account the excpetions.
If the grid is not stretchable, the number of lines is adjusted.
The exceptions allow the specification of irregular grids, where the distance between particular gridlines is different from the distance specified in the distance attribute.
The index of the grid space for which the exception is being defined. The first space has index 1.
The distance between the two lines that define the gridspace.
Part to which the replication applies. The part belongs to the same presentation that contains the replication.
The data_sequence is a parameter whose value is the collection of elements to be displayed. Typically this value is computed with an expression that invokes an application routine (e.g., a routine that extracts from a mailbox object the collection of messages it contains).
The references specify how to lay out the multiple replicas of the part using grids or using other parts as a reference.
The anchor and generic provide an alternative to references for specifying the layout of replicated parts. This mechanism is used for layouts that cannot be defined appropriately in terms of grids or other replications. The basic idea is to define the layout by defining the position of the first element (anchor), and then defining the position of the nth element (generic) based in the position of the nth minus one element (generic). The anchor is a presentation skeleton that defines how the first replica should be laid out. Typically the skeleton presentation only contains definitions for two guides (e.g., left and top), in terms of guides and grids of the parents. The generic is a list of presentation skeletons that defines how all the other elements are laid out. Typically two generic presentations are defined, corresponding to the nth (n) and nth minus one (n-1) replicas. Expressions for guides in the nth presentation define the layout with respect to the guides for the n-1 presentation. More than two generic presentations can be defined to define layouts that depend on the n-1, n-2, etc. replications.
See documentation on anchor.
The on_demand attribute specifies whether all replicas of the part should be generated in advance, or only as needed. This attribute gives developers the flexibility to define presentations where all elements of a collection are displayed at once (e.g., in a scrollable window), or presentations where the display of the elements is constructed incrementally (e.g., a display composed of multiple pages, where pages are added only as needed).
This attribute is used to specify that each element of the replication is a conditional part (the elements of the replication can use different presentations), as opposed to first define a conditional for a part, and then replicate the part (all elements of the replication use the same presentation). To get the latter effect, place the conditional in the containing presentation of the conditional part
It is possible to specify multiple references in a replication object. A common case is to use two references, containing a vertical and a horizontal grid. The effect is that elements are laid out in rows according to the vertical grid. When the columns in the vertical grid are exhausted, the next row in the horizontal grid is used. In general, the use of multiple references supports the specification of a large variety of layouts.
Specifies the grid on which the layout is based. The set of parts will be placed on the grid lines according to end_condition and init_procedure attributes.
Specifies that the set of parts should be laid out according to the parts of another replication (e.g., to the right of each part in the other replication).
The init_index specifies which grid line or replication element should be used to place the first element in this reference, which by default is the first one.
The end_condition specifies when to stop using this reference for placing objects (e.g., when reaching the last column in a vertical grid).
The init_procedure is an advanced feature that provides more flexibility for specifying the init_index by allowing a procedure to be called, rather than always using the same init_index.
A presentation can have several sequences of conditionals. Each sequence act as a case statement, consisting of several conditional clauses. MASTERMIND evaluates each conditional independently: it evaluates the condition expression of each conditional in the sequence until one returns true, and then uses the skeleton associated with the specifications of the successful clause.
The condition is an expression that depends on presentation or task parameters, guides and grids of the containing presentation and its ancestors. When it is true, the features of the Presentation specified in the skeleton of each element of the specifications attribute are applied to the presentation being constructed.
When MASTERMIND evaluates conditionals, it records the dependencies of all the condition expressions it evaluates, so that if any of the application data, guides or grids on which the predicates depend changes value, MASTERMIND will re-evaluate the appropriate predicates, re-apply the appropriate specifications, and update the display.
A conditional may affect several components of the display, other than the presentation itself where the conditional is stored. Each specification contains a skeleton to be applied and a pointer to the presentation where the specification has to be applied.
Where specifies the part of the display to which the Specification is to be applied.
The skeleton is a partially filled in presentation. When the corresponding conditional is true, all the attributes filled in in the skeleton are applied to the presentation beign constructed.
Currently a magnitude is simply a real number, but we expect to extend this concept to include additional information, such as stretchability. This information will be used to define the behavior of layouts the during negotiations that can take place for dividing up screen space between multiple parts.
The value is a real number.
Grids and guides are design time elements, i.e., they are used by developers to define the layout of the display, but they don�t appear in the final interface that the end-user sees. However, it is possible to define tasks that manipulate the guide position, thus giving the end-user a way to adjust the layout of the display.
The positions and margins of a guide can be defined using Expressions that depend on other guides, on Grids, and on Application_Data. These expressions allow the definition of layouts that are dynamically updated when the values of the elements that the expressions depend on change.
The direction of a guide specifies whether the guide is horizontalor vertical. Currently oblique directions are not supported.
The position of a guide specifies the offset from the left or top of the presentation where the guide is defined.
The margin1 specifies the left margin for vertical guides, or the top margin for horizontal guides. The margins are useful for defining gaps between objects.
The margin2 specifies the right margin for vertical guides, or the bottom margin for horizontal guides.
An integer that specifies the thickness of the line.
The color of the line.
How the end-points of the line look. This parameter is relevent for thick lines.
How the elbows of polylines look.
Whether the line is solid, dashed, dotted, etc.
Allows the specification of new dash patterns, by specifying the lengths of the line segments and the gaps as a sequence of numbers.
The color of the fill.
The fill can be solid, or defined using a pattern in several different ways.
Not documented yet.
The name of a file that contains a bitmap to be used to fill an area.
The coordinate along the X axis.
The coordinate along the Y axis.