The previous Chapters in this book have described the facilities for graphical output in PHIGS and for controlling the appearance of graphical output, both in terms of geometric and non-geometric content. PHIGS, as the name indicates, is a graphical system that provides support for interaction, and in this Chapter and the next the functionality in PHIGS which supports graphical input is described, together with the mechanisms which relate graphical input to the central structure store.
PHIGS shares the same model of input as GKS, and readers familiar with GKS will note that the differences lie in the choice of measure values for the input device classes.
Input in PHIGS is accomplished through logical input devices. The idea behind logical input devices is that they provide an abstraction from specific hardware input devices, for example, mouse, tablet, keyboard, lightpen, and enable applications to be written in such a way that they are portable across a wide range of input device hardware. The application is only concerned with the values delivered by logical input devices, for example a position in world coordinates and view index, not with the specific details of how the value is derived from the values generated by the physical input devices.
PHIGS provides six classes of logical input devices. The types of values returned by each class are:
As in GKS, there are three operating modes for logical input devices. They differ in whether the operator or the application has the initiative to generate logical input values. The three operating modes are:
PHIGS allows the application to control some characteristics of logical input devices, for example the forms of prompting to be used to indicate to the operator that input is required. The logical input device classes and operating modes are explained in detail in the following sections.
Before describing the logical input device classes, the default operating mode, REQUEST, is outlined. The logical input device classes are then described for REQUEST mode input. The functions which support the other operating modes are described in Chapter 10.
In REQUEST mode, input is produced by the operator in direct response to a request by the application program. This corresponds very closely to the forms of input provided by programming languages such as Fortran, Pascal and C. In Fortran, when a READ statement is executed, the program is suspended and waits for the values requested to be provided by the input sub-system. Execution of the Fortran program continues when the values have been provided. This is exactly the effect of REQUEST mode input in PHIGS. The application requests input from a particular logical input device. The application is then suspended until the logical input device has obtained the input from the operator. In this mode, either the application is active or the logical input device is active, but never both. A consequence of this is that never more than one logical input device can be active at a time in REQUEST mode.
The form of the function for REQUEST input is:
REQUEST XXX(WS, DV, ST, ....)
XXX identifies the class of logical input device (VALUATOR, CHOICE, etc), WS and DV identify the particular device of that class from which input is requested and ST is an output parameter which is a status indicator providing information on the completion of the request. WS identifies the workstation with which the logical input device is associated and DV identifies the particular device of the class on that particular workstation. It is possible for a workstation to provide more than one logical input device in a class, thus a workstation might provide three LOCATOR devices.
The form of the remaining parameters to the REQUEST function varies between the different logical input device classes, and is described in the following sections.
The LOCATOR input device returns a single position to the application program together with information that relates the point on the display with the view associated with this point. Two functions are provided in PHIGS to request input from a LOCATOR device:
REQUEST LOCATOR 3(WS, DV, ST, VI, XPOS, YPOS, ZPOS) REQUEST LOCATOR (WS, DV, ST, VI, XPOS, YPOS)
REQUEST LOCATOR 3 returns a position (XPOS,YPOS,ZPOS) in world coordinates and a view index VI. REQUEST LOCATOR returns a 2D position in world coordinates (XPOS,YPOS) and a view index VI. The 2D position is obtained by discarding the Z-coordinate of the 3D position which is the intrinsic value of the LOCATOR logical input device irrespective of how it is invoked.
It is worth stressing that all LOCATOR devices in PHIGS are 3D devices. The REQUEST LOCATOR 3 and REQUEST LOCATOR functions can be used to access any LOCATOR device.
Referring to the viewing pipeline depicted in Figure 7.2, it will be seen that to generate an input value in world coordinates from a value in the workstation dependent device coordinate system, it is necessary to apply the inverse of the workstation and viewing transformations. Each workstation has a single workstation transformation (see Section 11.3), but may have multiple viewing transformations. The parameter VI identifies which of the viewing transformations was used to transform the logical input value. This transformation will be one whose view clipping limits contain the position. The mechanism for selecting the viewing transformation is discussed shortly, after an example has been described.
For illustration of LOCATOR input, a simple 2D example will be given, based on a part of the structure network defining a work environment given in Figure 5.6 (Section 5.4.5). A work environment consisting of the large desk, blotter, calculator and chair is defined by:
OPEN STRUCTURE(WKNV)
MVRP(0.2, 0.6)
EXECUTE STRUCTURE(LG)
MVRP(0.325, 0.525)
EXECUTE STRUCTURE(CHAIR)
CLOSE STRUCTURE
POST STRUCTURE(WS, WKNV, PR)
The MVRP function defines a single SET LOCAL TRANSFORMATION structure element which is a translation that replaces any local transformation currently in force. It can be thought of as a shorthand form of the SET LOCAL TRANSFORMATION structure element.
The structure created is shown in Figure 9.1.
The large desk and its contents are positioned at the point (0.2, 0.6) in the modelling coordinate system of the work environment. As this is the only transformation applied to the structure, this is also the point (0.2,0.6) in world coordinates.
The example is to use a LOCATOR device to reposition the desk in the unit square coordinate system. The operator selects the position in world coordinate space at which the bottom left hand corner of the desk is to be positioned, using a LOCATOR device. Assuming the structure WKNV above has already been created and posted, the following program would accomplish this. This is the first example of editing using REPLACE mode which is particularly appropriate in this case.
OPEN STRUCTURE(WKNV)
SET EDIT MODE (REPLACE)
SET ELEMENT POINTER(1)
100 CONTINUE
REQUEST LOCATOR(WS, DV, ST, VI, X, Y)
MVRP(X, Y)
GOTO 100
The key idea is to use the position input by the LOCATOR device to construct a transformation matrix which will position the bottom left-hand corner of the desk at the position input. The structure editing facilities in PHIGS are then used to replace the local modelling transformation defined by MVRP (at element position 1 in the structure) with the new one. This program then loops forever requesting new positions for the desk.
The structure WKNV is posted after creation. Subsequent edits to the structure result in the modified structure being displayed on the workstation, and so the effect of editing the structure will be immediately visible. A typical movement is shown in Figure 9.2. The intersection of the cross hairs define the point to which the desk is to be moved.
The major difficulty with this style of programming is to relate LOCATOR input in world coordinates to the modelling coordinate systems in which the components of a scene are specified. In the worst case this can involve the application in considerable work maintaining details of the coordinate systems used and the transformations between them.
Typically, several views will be in use on a workstation, for example in Figure 9.3 the desk is drawn with view index 1, and the word STOP with view index 2.
The operator needs to be able to input LOCATOR positions in either view and the application program needs to be able to differentiate between the views in use. This is the purpose of the view index parameter of the REQUEST LOCATOR function.
For this example, a program which will move the desk to a new position if a LOCATOR input is received in view 1, and will terminate if a position is received in view 2 is the following:
OPEN STRUCTURE(WKNV)
SET VIEW INDEX(1)
MVRP(0.2, 0.6)
EXECUTE STRUCTURE(LG)
MVRP(0.325, 0.525)
EXECUTE STRUCTURE(CHAIR)
CLOSE STRUCTURE
POST STRUCTURE(WS, WKNV, PR)
OPEN STRUCTURE(STOP)
SET VIEW INDEX(2)
DRAW STOP
CLOSE STRUCTURE
POST STRUCTURE(WS, STOP, PR1)
OPEN STRUCTURE(WKNV)
SET EDIT MODE(REPLACE)
SET ELEMENT POINTER(2)
100 CONTINUE
REQUEST LOCATOR(WS, DV, ST, VI, X, Y)
IF(VI .NE. 1) GOTO 110
MVRP(X, Y)
GOTO 100
110 CONTINUE
CLOSE STRUCTURE
SET EDIT MODE(INSERT)
STOP
The view transformation selected to transform the LOCATOR position from NPC to world coordinates is that whose view clipping limits contain the position in NPC coordinates.
In the example in the previous section, view representation 1 and view representation 2 were defined so that the areas defined by the view clipping limits of the two views do not overlap. In general the areas may overlap with the result that an NPC position may fall within the view clipping limits of more than one view transformation. The view transformation associated with view index 0 maps the unit cube in world coordinates into the unit cube in NPC, and the associated view clipping limits define a unit cube. For 2D working, the view clipping limits of view index 0 are the unit square, and since the representation of this view index cannot be changed, any position in NPC space will always fall into the view clipping limits of view index 0, and possibly the representations of other view indices also.
To resolve conflicts between view representations, PHIGS has a view transformation input priority mechanism which is very similar to the viewport input priority mechanism in GKS used to resolve conflicts between normalization transformations in the GKS LOCATOR input mechanisms. A view transformation input priority is associated with every view representation defined on a workstation. If a LOCATOR position falls within the view clipping limits of more than one view representation, the view by which the position is transformed is that with the highest view transformation input priority.
The view representations are ordered by view transformation input priority. Workstations are initialized so that view representation 0 has the highest view transformation input priority, and view representation N (where N denotes the maximum view index) has the lowest. This is illustrated in Figure 9.4.
All input is returned with view index 0 until the default view representation ordering is changed. Thus the examples given so far were not strictly correct. View transformation input priority is changed by the function:
SET VIEW TRANSFORMATION INPUT PRIORITY (WS, VI, RVI, RP)
The effect is to set the view transformation input priority of view index VI on workstation WS, either immediately higher (if RP has the value HIGHER) or immediately lower (if RP has the value LOWER) than that of the reference view index (RVI).
For the example in Section 9.3.1 to work correctly, the priority of view transformation 0 needs to be lower than those of view transformation 1 and 2. Since the view clipping limits of view transformations 1 and 2 do not overlap, the relative priorities of these two transformations is not important. A satisfactory ordering can be achieved by the function invocation:
SET VIEW TRANSFORMATION INPUT PRIORITY(WS, 0, 2, LOWER)
This produces the priority ordering:
1 > 2 > 0 > 3 > ..... > N
The position of view transformation 0 is moved to immediately below that of view transformation 2. This method of setting priorities ensures that no two view transformations have the same priority.
A more complex example is shown in Figure 9.5. Here view 0 overlaps views 1 to 5. Views 1, 2 and 3 do not overlap, but views 4 and 5 overlap view 3. To obtain LOCATOR input positions in view transformations 1 to 5 can be achieved by the view transformation input priority ordering:
4 > 5 > 1 > 2 > 3 > 0
This can be achieved by the following invocations of SET VIEW TRANSFORMATION INPUT PRIORITY:
SET VIEW TRANSFORMATION INPUT PRIORITY(WS, 0, 3, LOWER)
SET VIEW TRANSFORMATION INPUT PRIORITY(WS, 4, 1, HIGHER)
SET VIEW TRANSFORMATION INPUT PRIORITY(WS, 5, 4, LOWER)
The first invocation produces the ordering:
1 > 2 > 3 > 0 > 4 > 5
The second produces:
4 > 1 > 2 > 3 > 0 > 5
and the final invocation produces the desired ordering.
Whereas the LOCATOR logical input device returns a single position in world coordinates and a view index, to the application program, the STROKE logical input device returns a sequence of positions and a view index. Two PHIGS functions are provided to request input from a STROKE device:
REQUEST STROKE 3 (WS, DV, N, ST, VI, NPTS, XPOSA, YPOSA, ZPOSA) REQUEST STROKE (WS, DV, N, ST, VI, NPTS, XPOSA, YPOSA)
The parameters WS, DV, ST and VI have the same meanings as the corresponding parameters in REQUEST LOCATOR 3 and REQUEST LOCATOR. The parameter N is the dimension of the arrays XPOSA, YPOSA (and ZPOSA). The output parameter NPTS returns the number of points in the STROKE value input, and the remaining parameters are arrays of coordinate values which contain the coordinates of the points in the STROKE. The provision of STROKE input as well as LOCATOR input is to allow a sequence of positions to be input without placing too much load on the PHIGS system and, in consequence, producing a faster response to the operator's input of positions.
All the points in the STROKE are transformed by the inverse of the view transformation corresponding to view index VI. The view transformation selected is that with highest view transformation input priority whose view clipping limits contain all of the points in the STROKE. This is illustrated in Figure 9.6. The view transformation input priorities are the same as in Figure 9.5.
The view index associated with each STROKE is shown in the table below.
| STROKE | View Index |
|---|---|
| A | 1 |
| B | 2 |
| C | 5 |
| D | 4 |
| E | 3 |
| F | 3 |
| G | 0 |
The points in STROKE's A, B, C, D, and E all lie within the clipping limits of a single view transformation. STROKE F overlaps the clipping limits of transformations 3 and 5, but all the points falling in the clipping limits of transformation 5 also fall within the clipping limits of transformation 3. The points also all fall within the clipping limits of the view transformation 0. The priority of transformation 3 is greater than that of transformation 0 and so view index 3 is associated with the STROKE.
STROKE G overlaps the view clipping limits of transformations 1 and 3, but only the view clipping limits of transformation 0 contain all the points, and hence the view index associated with STROKE G is view index 0.
LOCATOR and STROKE input are conceptually 3D in PHIGS. If the physical input device generating LOCATOR and STROKE values is a 2D device, a third coordinate value is appended either internally from the PHIGS state tables, or externally, for example by requesting the operator to type the Z-value from a keyboard device.
Section 9.3 and Section 9.4 have described LOCATOR and STROKE input concentrating on the 2D form of the REQUEST functions. The same principles apply to the 3D form of the functions, with some additional complications. LOCATOR 3 and STROKE 3 logical input values are obtained by applying the inverse of the workstation transformation and the inverse of the selected view transformation.
In 3D, it is possible that these transformations do not have inverses. These situations are handled as follows. If the workstation transformation does not have an inverse, the Z-component of the LOCATOR position, and the Z-components of all the STROKE positions are set to the minimum Z-value of the workstation window.
In the case of the view transformation, the only view transformations considered are those which are invertible. Any view transformation, which does not have an inverse, is rejected. View transformation 0 is invertible, so it is guaranteed that a view transformation can always be found which can back transform LOCATOR and STROKE positions from NPC to world coordinates.
The PICK logical input device provides a link between the image displayed on a workstation and the central structure store. The operator can pick a portion of the display. The value returned by the pick logical input device identifies the structure element in the central structure store which generated the picked primitive. The PHIGS function to request input from a PICK device is:
REQUEST PICK(WS, DV, DEPTH, ST, PPD, PP)
DEPTH is an input parameter which specifies the maximum depth of pick path to return. PPD is the depth of the actual pick path returned and PP is the pick path which identifies the primitive picked. This will be explained in the example below.
A pick path defines the traversal path through the central structure store, which generated the output primitive picked. A pick path is a list of items, each item consisting of:
Pick identifiers will be described shortly.
The following example illustrates the idea of a pick path. Figure 9.7 illustrates a work environment and Figure 9.8 the structure network from which it is generated.
Suppose the operator wishes to indicate items on the desk on which some action is to be performed. In the case of the telephones, the information required may be which phone it is, which desk it is sitting on and so on. The operator input will normally result in the need to edit the relevant part of the picture. The information returned is aimed at giving the application all that is required to edit the structure at a required level of detail.
The border of the blotter is generated by the structure element at position 1 in the structure BLOT. If the operator indicates the border in response to a REQUEST PICK, the pick path returned by the application program will be a list of items as follows:
| Structure | Pick Identifier | Element Position |
|---|---|---|
| WKNV | 0 | 2 |
| DESK | 0 | 1 |
| LG | 0 | 3 |
| BLOT | 0 | 1 |
The last entry in the list identifies the structure element which generated the primitive picked; in this case, it is the element at position 1 in structure BLOT. The remaining items describe the path taken by the traverser through the central structure store to that element. In this case, traversal starts in the posted structure WKNV, then through structures DESK and LG to BLOT. The element position in each of the first three items is the position of the execute structure element which invokes the next structure in the list. In this case there is only one path through the central structure store to the structure element generating the primitive picked. However, for the output primitives generated by the structure PHON, there are three alternative paths, corresponding to the three instances of the phone in the scene.
In Fortran, PP is an INTEGER array of dimension (3, DEPTH). The (1, *) components contain the structure identifiers, the (2, *) components the pick identifiers and the (3, *) components the element positions.
If the border of the left-most phone in Figure 9.7 is picked, the pick path returned is:
| Structure | Pick Identifier | Element Position |
|---|---|---|
| WKNV | 0 | 2 |
| DESK | 0 | 3 |
| CN | 0 | 3 |
| PHON | 0 | 1 |
In this instance, the structure PHON is invoked by the structure element at position 3 in structure CN. If the border of the centre phone is picked, the pick path returned is:
| Structure | Pick Identifier | Element Position |
|---|---|---|
| WKNV | 0 | 2 |
| DESK | 0 | 3 |
| CN | 0 | 5 |
| PHON | 0 | 1 |
This example illustrates how pick paths are used to differentiate between different instances of an output primitive generated by different traversal paths through the central structure store.
Another method for differentiating between several instances of a primitive is to give the instances different pick identifiers. A pick identifier is a primitive attribute which provides an additional level of naming of primitives for the application program to use. The pick identifier attribute is bound to a primitive on creation. The function:
SET PICK IDENTIFIER(ID)
creates a structure element in the currently open structure, which, on traversal, results in the value ID being bound to subsequently created output primitives until a further set pick identifier structure element is traversed.
The following program:
OPEN STRUCTURE(BLOT)
SET PICK IDENTIFIER(l)
POLYLINE(4, XBRD, YBRD)
will associate pick identifier 1 with the output primitives in the blotter. If the border of the blotter is now picked by the operator, the last item in the pick path will be:
| Structure | Pick Identifier | Element Position |
|---|---|---|
| BLOT | 1 | 2 |
The pick identifier has the value 1 and the element position is now 2, because of the insertion of the extra item into the BLOT structure.
When a structure is traversed, the pick identifier is inherited from its parent structure as other attributes are inherited. Thus different pick identifiers can be associated with the three instances of PHON, in the following way:
OPEN STRUCTURE(CN)
------
SET PICK IDENTIFIER(1)
EXECUTE STRUCTURE (PHON)
-------
SET PICK IDENTIFIER(2)
EXECUTE STRUCTURE(PHON)
-------
SET PICK IDENTIFIER(3)
EXECUTE STRUCTURE (PHON)
If the border of the left-most phone in Figure 9.7 is picked, the last item in the pick path returned is now:
| Structure | Pick Identifier | Element Position |
|---|---|---|
| PHON | 1 | 1 |
If the centre phone is picked, the item is:
| Structure | Pick Identifier | Element Position |
|---|---|---|
| PHON | 2 | 1 |
and for the right-most phone, it is:
| Structure | Pick Identifier | Element Position |
|---|---|---|
| PHON | 3 | 1 |
Thus the object picked can be uniquely identified by examining the name of the structure in the last item in the pick path and the pick identifier.
For many applications it is not desirable that all primitives in a scene are able to be picked by a PICK logical input device. Using the work environment as an example, an application for constructing work environments might want to allow the operator to select a desk by picking. It should therefore be possible to pick the border of the desk, but not the accessories on it. Namesets and pick filters in PHIGS allow the application program to control which primitives can be picked by a particular PICK logical input device.
Each PICK logical input device has an associated pick filter, consisting of a pair of sets of names, called the inclusion set and the exclusion set. By default, the inclusion set and the exclusion set are empty and as a consequence, primitives are by default not pickable. Pick filters operate in the same way as the invisibility and highlighting filters described in Section 4.7.2. The examples of PICK input given above require namesets and pick filters to be set up before the primitive can actually be picked.
All primitives in the work environment can be made pickable in the following way. A nameset consisting of the single name NWKNV is associated with every output primitive in the scene. This may be accomplished by the program:
OPEN STRUCTURE(WKNV)
NMSETA(1)=NWKNV
ADD NAMES TO SET(1, NMSETA)
------
EXECUTE STRUCTURE(DESK)
------
The effect of the ADD NAMES TO SET function is to insert an add names to set structure element at the head of structure WKNV. On traversal, the name NWKNV is added to the current name set which is bound to primitives created subsequently. The current nameset is inherited by a child structure from the parent, and in this example will result in the nameset containing the single name NWKNV being bound to each primitive.
To make all primitives pickable by a particular pick device requires the pick inclusion set for that device to be set to a nameset which contains the single name NWKNV, and the exclusion set to the empty set. Pick filters are set by the function:
SET PICK FILTER(WS, PDEV, NIS, IS, NES, ES)
WS and PDEV identify the PICK logical input device, NIS and NES are the number of names in the inclusion and exclusion sets respectively, and IS and ES are arrays of names. For the example here, the pick filter is set to the required value by:
INS(1 )=NWKNV
SET PICK FILTER(WS, PDEV, 1, INS, 0, ENS)
A more complex example which illustrates the power of the nameset and filter mechanism is to make only the phones pickable, and then to make all but one of the phones pickable. The name PHONES will be included in the nameset of the primitives of each phone. The names PHONEL, PHONEC and PHONER respectively will be included in the namesets of the individual phones (the names denote the left, centre and right phones respectively). This enables the three phones to be manipulated individually. These manipulations to the name sets can be accomplished with the following structure:
OPEN STRUCTURE(CN)
POLYLINE(12, XC, YC)
NMSETA(1)=PHONES
ADD NAMES TO SET(1, NMSETA)
NMSETA(1)=PHONEL
ADD NAMES TO SET(1, NMSETA)
MVRP(0.01, 0.025)
EXECUTE STRUCTURE(PHON)
REMOVE NAMES FROM SET(1, NMSETA)
NMSETA(1)=PHONEC
ADD NAMES TO SET(1, NMSETA)
MVRP(0.058, O.0998)
EXECUTE STRUCTURE(PHON)
REMOVE NAMES FROM SET(1, NMSETA)
NMSETA(1)=PHONER
ADD NAMES TO SET(1, NMSETA)
MVRP(0.123, 0.023)
EXECUTE STRUCTURE(PHON)
CLOSE STRUCTURE
The function invocation:
INS(l)=PHONES
SET PICK FILTER(WS, PDEV, 1, INS, 0, ENS)
sets the inclusive set for the PICK logical input device PDEV to the single name PHONES, and the exclusion set to the empty set. All primitives which contain the name PHONES in their namesets will be pickable by the device.
Suppose the left and right-most phones are to be pickable and the phone in the centre is not to be pickable. One way to achieve this is to set the inclusion name set to contain the names PHONEL and PHONER and the exclusion set to be empty:
INS(1)=PHONEL
INS(2)=PHONER
SET PICK FILTER(WS, PDEV, 2, INS, 0, ENS)
The namesets of the primitives representing the left-most phone contain the names PHONES and PHONEL. These primitives will be eligible for picking because their namesets have at least one element in common with the inclusion set of the pick filter (in this case the single name PHONEL), and no names in common with the exclusion set. Similarly the primitives representing the right-most phone will be pickable because their namesets have the name PHONER in common with the inclusion set and no names in common with the exclusion set. The primitives representing the centre phone contain the names PHONEC and PHONES in their nameset. None of these primitives will be eligible for picking because they have no names in common with the inclusion set.
An alternative way to achieve the same effect is to set the pick filter as follows:
INS(1)=PHONES
ENS(1)=PHONEC
SET PICK FILTER(WS, PDEV, 1, INS, 1, ENS)
The inclusion set contains the name PHONES and the exclusion set contains the name PHONEC. The primitives representing the left-most phone have the names PHONES and PHONEL in their nameset. The name PHONES is common with the inclusion set and no names are in common with the exclusion set and so the primitives representing the phone are pickable. The primitives representing the right-most phone have the names PHONES and PHONER in their namesets and similarly these primitives are pickable also. The primitives representing the centre phone have the names PHONES and PHONEC in their namesets. The name PHONES is in common with the inclusion set, but the name PHONEC is in common with the exclusion set, and so these primitives are not eligible for picking.
An earlier section (Section 4.7.2) has described the filter mechanisms for controlling visibility and highlighting of primitives. If an application wishes to indicate to the operator which primitives are eligible for picking by a particular PICK logical input device, this may be achieved by setting the highlighting filter to the same value as the PICK device pick filter. Any nameset accepted by the pick filter will also be accepted by the highlighting filter and so the primitive will be highlighted; any name set which does not satisfy the pick filter will also fail to satisfy the highlighting filter and so the primitive will not be highlighted.
In the last example above, the primitives representing the left-most and right-most phones which are eligible for picking can be highlighted as follows:
INS(1)=PHONES
ENS(1)=PHONEC
SET HIGHLIGHTING FILTER(WS, 1, INS, 1, ENS)
The inclusion filter would allow all the phones to be highlighted but the exclusion filter stops the highlighting of the central phone.
The VALUATOR logical input device returns a real value to the application. The function to request input from a VALUATOR logical input device is:
REQVEST VALUATOR(WS, DV, ST, VAL)
The application can specify the range within which the value may be; the mechanism for achieving this is described in a later section (Section 10.2.4).
The most natural physical input device to map onto the VALUATOR logical input device would be a potentiometer, but in common with the other logical input devices, the logical device can be supported by a wide range of physical input devices. PHIGS input devices are most likely to support input of values from a mouse at the very least. Many workstations provide a set of dials which will normally be mapped into a set of VALUATORs. At the other extreme, inputting the value from a keyboard may be provided.
An example of the use of a VALUATOR logical input device is to control the orientation of the lamp base in the example of Figure 5.8 (see Section 5.4.5). A program that allows the operator to input a new orientation of the base is:
OPEN STRUCTURE(LMP)
SET EDIT MODE(REPLACE)
SET ELEMENT POINTER(1)
100 CONTINUE
REQUEST VALUATOR(WS, DV, ST, V)
RTRP(V*(2*PI)/360)
GOTO 100
It is assumed that the VALUATOR logical input device returns values in the range 0 ≤ V ≤ 360, Thus the angle of rotation provided to RTRP will be in the range 0 to 2π. The input value provided by the operator is used to construct a transformation matrix which replaces the local modelling transformation at the head of the structure LMP.
A typical interaction is shown in the sequence from Figure 9.9 to Figure 9.12. Figure 9.9 shows the work environment with the lamp in a standard orientation.
In Figure 9.10, input has been requested from the operator; the state of the VALUATOR is echoed by the position of the pointer on the dial. Initially the value is 0. The logical input device could be presented to the operator as a dial. Alternatively, the operator might be required to point with a mouse at the tick mark on the dial or have the pointer follow the mouse as it moves around the circumference of the dial.
Figure 9.11 shows the state just before the operator terminates the interaction. The value of the logical input device echoed by the dial is 108° anticlockwise.
In Figure 9.12, the interaction has terminated and the lamp is redrawn in the new orientation. The application has regained control and the dial echoing the logical input device has disappeared.
The only feedback given to the operator during the interaction is the position of the pointer on the dial indicating the current value of the logical input device. The operator does not see the effect of a particular logical input value on the lamp until the interaction has terminated. A later section (Section 10.1.5) will show how the lamp can be made to move under direct operator control using SAMPLE mode input.
The CHOICE logical input device returns an integer (greater than 0) which indicates which of a number of possibilities has been chosen by the operator. The PHIGS function to invoke a CHOICE logical input device in REQUEST mode is:
REQUEST CHOICE(WS, DV, ST, CH)
where CH returns the integer representing the selection made.
The example in the previous section showed how a VALUATOR logical input device could be used to allow the operator to define the orientation of an object, in this case the lamp base in the work environment. The structure network which models the lamp also allows the arm and light to be rotated (see Section 5.4.5). A program which allows the operator to select the lamp, arm or light and then define the orientation of the component selected, could use a CHOICE logical input device to select the component, and a V ALUA TOR logical input device, as in the previous section, to define the orientation. A program to do this is:
SET EDIT MODE(REPLACE)
50 CONTINUE
REQUEST CHOICE(WS, CHI, ST, CH)
IF(CH .GT. 3) GOTO 400
REQUEST VALUATOR(WS, LOCI, ST, ROT)
ROT=ROT*(2*PI)/360
GOT0(100, 200, 300), CH
100 CONTINUE
C LAMP
OPEN STRUCTURE(LMP)
SET ELEMENT POINTER(1)
RTRP(ROT)
CLOSE STRUCTURE
GOTO 50
200 CONTINUE
C ARM
OPEN STRUCTURE(LMP)
SET ELEMENT POINTER(3)
RTPR(ROT)
CLOSE STRUCTURE
GOTO 50
300 CONTINUE
C LIGHT
OPEN STRUCTURE(ARM)
SET ELEMENT POINTER(3)
RTPR(ROT)
CLOSE STRUCTURE
GOTO 50
400 CONTINUE
SET EDIT MODE(INSERT)
STOP
Choice number 1 corresponds to changing the orientation of the base and, therefore, the whole lamp, choice number 2 to the arm (and light) and choice number 3 to the light. Changing the orientation of a component is achieved by replacing the structure element which controls the orientation.
CHOICE logical input devices can be realized by many different physical input devices. One obvious way to implement a CHOICE device is as a menu of items selectable by a mouse. The application program needs to be able to associate menu items with choice numbers; the mechanism for doing this is described when the logical input device initialization is discussed (see Section 10.2).
The STRING logical input device returns a character string to the application program. The PHIGS function for requesting input from a STRING logical input device is:
REQUEST STRING(WS, DV, ST, NCHARS, STR)
STR returns the character string that was input and NCHARS returns the number of characters it contains. STRING input is useful for inputting items such as filenames and labels.
STRING logical input devices would normally be mapped to a physical keyboard but hand-drawn characters or clicking with a mouse on a displayed pseudo-keyboard would be equally valid. As with the STROKE device, it is necessary to define the completion of the input by specifying an event which terminates the input.