Text and Image Windows

Text Windows

Unlike line drawing for which we have a separate definitive notation, we are yet to define a definitive notation for text processing. Part of the Scout notation is therefore designed to cope with simple text layout. To this end, Scout incorporates a text window subtype. This text window subtype differs from other window subtypes in that the content of the text window subtype is a string defined within Scout rather than a virtual screen described outside Scout by another definitive notation. As a result, string becomes one of the Scout data types.

Associated with the string data type is a set of operators useful for displaying a text string. String concatenation (//), string length function (strlen) , sub-string function (substr) and integer-to-string conversion (itos) are the basic Scout string manipulation functions. There are two postfix operators - .r and .c: since the basic geometric unit in Scout is the pixel but the size of a block of text is more conveniently specified as "number of rows by number of columns", it is convenient to introduce functions returning the row height and the column widths in pixels. .r is the function meaning "multiply by the row height" and .c is the function meaning "multiply by the column width". These functions are appropriately represented by postfix operators because they work very much like units. For examples, {10.c, 3.r} refers to a point 3 rows down and 10 columns right to the origin. A similar consideration influences the design of a box, a data type for defining regions. The region associated with a box is sufficiently defined by its top-left corner and its bottom-right corner, and this is a convenient method of definition in the case of graphics. For a block of text, however, the bounding box is more conveniently defined by specifying the top-left corner and the dimensions of the box in terms of number of rows and columns. For instance, [{0,0},3,10] refers to a box with the origin as its top-left corner which is suitable for displaying three rows by ten columns of text.

Because displaying a string is different from displaying an image, the way of specifying a region for displaying text is different from that for displaying an image. As attested by the fact that the earlier releases of the X Window system had only primitives for creating rectangular windows, a simple box is adequate for display purposes in most applications. But, when considering the possible application of text display to desktop publishing, we know that a piece of text may be displayed across several regions; defining a region by a box is simply not sufficient. Our solution is to define a region by an ordered list of boxes. A string should be filled in the first box first, then the second, and so on. Therefore we define a data type frame which is a list of boxes. Operators for lists can be applied to frames.

Textbox Windows

Textboxes contain strings that may be edited by the user. An example definition is shown below:

window fromText = {
    type: TEXTBOX
    frame: ([{60, 20}, {30, 1}])
    border: 1
    sensitive: ON
};
screen = <fromText>;

Note that sensitive must be ON for the user to be able to edit the contents of the box. Also note that the second "point" given for frame is not actually a point - for TEXTBOX only, the example above means a box 30 characters long, and 1 character deep. The same effect can be achieved in TEXT windows by specifying two integers rather than a point, for example frame: ([{60, 20}, 1, 30]), or perhaps calculating the point using the .c and .r operators: frame: ([{60, 20}, {60, 20} + {30.c, 1.r}]).

When the contents of a textbox is changed (actually, when the key is released), a variable is automatically redefined. The name of this variable is "~" // name of the window // "_TEXT_" // display box number: for the above example, it would be fromText_TEXT_1. Definitions or triggered procedures can be used to deal with input as shown below.

%eden
fromTextAppendHi is fromText_TEXT_1 // " hi";
proc p : fromText_TEXT_1 { writeln(fromText_TEXT_1); }

Note that data read from a text box may contain an extra appended newline (or two). This may be changed in future versions of Eden.

An alternative interface is available, which is not recommended for new models (if possible) due to its procedural nature. When a TEXTBOX is created, two Eden procedures are automatically created to enable access to the text in the box. The procedures names start with the name given to the window, and are followed by _getText and _setText. The Scout example given above could be used with the following Eden code:

%eden
test = fromText_getText();
fromText_setText(test // " and hi mum");

Image Windows

real xscale = 0.5;
real yscale = 0.5;
image source = ImageFile("gif", "logo.gif");
image sy = ImageScale(source, xscale, yscale);
window firstImage = {
    type: IMAGE
    box: [{10,10}, {490,240}]
    pict: "sy"
    border: 5
    relief: "raise"
};
window secondImage = {
    type: IMAGE
    box: [{10,260}, {490,490}]
    pict: "source"
    border: 5
    relief: "raise"
};
screen = <firstImage/secondImage>;

will give you two windows. The upper one shows a mini version of the image of display in the lower one.

As of now, the functionality is very limited. Only two functions are defined: ImageFile() and ImageScale(). And the images have to be centred in the window.