In Chapter 5, the different logical input devices were described using the REQUEST mode of input as an example. In this chapter, we will concentrate on the different modes of input available in GKS and show how they allow different styles of interaction to take place.
The interaction process, involving a logical input device, can be considered as taking place between two processes. One is the application program and the other is the input process, which looks after the input device and delivers data from this device to the application program. The relationship between these two processes can vary and, in so doing, will produce different styles of interaction which will affect the way that the operator sees the system. For example, a program may wish to read the operator's actions at any time or only at certain significant moments controlled by the operator.
The three operating modes of logical input devices specify who (the operator or the application program) has the initiative: SAMPLE input is acquired directly by the application program; REQUEST input is produced by the operator in direct response to the application program; EVENT input is generated asynchronously by the operator.
These three modes of interaction work as follows:
As was stated in Chapter 5, all logical input devices can operate in each of the three modes. Of those in REQUEST mode, at most one can actually be responding to a request at one time. However, any number can be active in SAMPLE mode at the same time, while others can be active in EVENT mode. This provides a rich environment for interaction within GKS.
Each device can be in only one mode of operation at a time. The mode is selected by calling a function of the type:
SET LOCATOR MODE(WS, DV, MODE, EC)
As was mentioned in Section 5.2, the first two parameters define the specific device of that type from which input is required. The third parameter defines the mode of operation and can take one of the three values REQUEST, SAMPLE and EVENT. The last parameter EC can have one of two values, ECHO and NOECHO. If ECHO is selected, the operator will get some indication of the input data that is being entered to the program. For example, a string device might echo the keys hit on a keyboard, by allowing the characters that have been hit to be displayed on the screen at some position.
The default mode of operating for all devices is REQUEST mode. For this reason, the examples in the previous chapter did not need to have mode setting functions included in them. Also, the default situation is to have devices in the ECHO state.
REQUEST mode was introduced in Section 5.2 and is described more precisely here. A program can only issue REQUESTs to a device when it is in the REQUEST operating mode. The exact form of the REQUEST function for each type of logical input device was given in Chapter 5. A typical example is:
REQUEST LOCATOR(WS, DV, STATUS, NORMTR, XPOS, YPOS)
The first three parameters are required for each device. As before, the first two define the specific device from which data is required while the third, STATUS, returns information concerning how successful the logical input device was in providing the requested data.
The call of REQUEST LOCATOR will cause the starting echo to appear on the screen, if echoing is selected. It will normally be apparent to the operator which physical device is to be used. The operator moves the physical device (rotates a trackerball, moves a tablet stylus) which adjusts the screen echo. When satisfied with the position of the echo, the operator can activate a trigger to signal that the input is complete. (The physical trigger may be a button or a key or even the tipswitch of a tablet stylus, depending upon the particular logical input device.) This is the normal way in which REQUEST LOCATOR terminates. Figure 6-1 shows one physical realization of what the operator sees. In the first of the five snapshots, no input is taking place. The picture of the duck is on the screen. An unlit button to the right of the screen shows that no button press is expected or required.
If the program now calls REQUEST LOCATOR, a pair of crosshairs appears as in the second snapshot to show that the locator input device is available. This is the prompt. The position of the crosshairs gives the initial value. The button is lit to show the operator that once he has moved the locator to the required position, he should press it to input the locator value.
The third snapshot shows how the operator has moved the physical device (possibly thumbwheels) to a new position and the crosshairs have moved echoing the operator's action.
If the operator presses the button, the locator position will be input. The cursor disappears and the button light goes out as in the fourth snapshot. This provides acknowledgement of the button press. REQUEST LOCATOR is now complete and the application program continues, reacting to the data input.
In the final snapshot, the program provides feedback to the operator by shifting the duck to the specified position. This will happen as fast as the system can allow. It is possible that the fourth snapshot picture is so transitory that it is not seen.
The STATUS parameter is returned by each REQUEST function to indicate success or failure. STATUS can return with a value OK or NONE. The value OK means that the operator completed the input in the normal way, by activating a trigger and that the input data (transformation number and position in the case of locator) are valid.
If STATUS returns with the value NONE, the input data are invalid because the operator indicated a break. A break could be interpreted by the program as the end of a series of input values.
How the operator indicates a break depends on the input device. If the operator selects an invalid locator position, that could be interpreted as a break. Another way the operator can signal a break is to hit an alternative button. The device could have 2 buttons: one to signal normal completion, the other to signal a break.
An analogy in a non-graphics context is when an operator makes use of a facility on some operating systems to indicate an end-of-file on a terminal. If the operator does this, the contents of the input string are usually undefined.
In the animation example in Section 5.3 where REQUEST LOCATOR was illustrated, there was no way of terminating the loop. The status parameter provides a means of doing that. Instead of the loop shown in Section 5.3, we can write:
100 CONTINUE
REQUEST LOCATOR(WS, DV, STATUS, NT, X, Y)
IF(STATUS .EQ. NONE) GOTO 200
NEW FRAME
DRAW BACKGROUND
DRAW DUCK AT(X, Y)
GOTO 100
200 CONTINUE
The function REQUEST PICK can return a status reply other than OK and NONE. The operator could cause a pick input (by activating a trigger) when he is not pointing at a segment at all. In this case, the STATUS parameter returns with the value NOPICK.
Similarly, the function REQUEST CHOICE can also return a status reply NOCHOICE as well as OK or NONE. The logical input device provides a method by which the operator can cause this to be returned.
We have seen how making a REQUEST for input from an input device causes our program to be suspended until the operator chooses to make the input available. By contrast, sampling returns a value immediately without waiting for a trigger. Sampling works for any of the logical input devices, but first we illustrate it for LOCATOR. The device is first put into SAMPLE mode by calling the function:
SET LOCATOR MODE(WS, DV, SAMPLE, EC)
Unlike REQUEST mode, echoing begins immediately as the mode setting function starts up the input process to deliver values from the device. To sample from the device requires the following function to be called:
SAMPLE LOCATOR(WS, DV, NT, X, Y)
Note that SAMPLE functions do not need to return a NONE status. Therefore only SAMPLE CHOICE and SAMPLE PICK have a status parameter, which can take the values OK or NOCHOICE and OK or NOPICK respectively. The SAMPLE function returns the current value of the locator device provided by the input process.
Rewriting the example in Section 5.3 but using SAMPLE mode, we would have:
SET LOCATOR MODE(WS, DV, SAMPLE, ECHO)
100 CONTINUE
SAMPLE LOCATOR(WS, DV, NT, X, Y)
NEW FRAME
DRAW BACKGROUND
DRAW DUCK AT(X, Y)
GOTO 100
Note that the style of interaction is rather different. As the operator moves the position of the locator, its value is sampled and the duck redrawn at that position. Consequently, the duck moves around as the locator position is changed, assuming that the redrawing speed is fast enough.
This differs significantly from the REQUEST mode where the operator moves the locator to a new position and activates the trigger before the picture is redrawn. The SAMPLE mode of interaction is much freer with the ability to respond in a more dynamic way to input from the operator.
One problem with the SAMPLE mode of input is that it does not have the status parameter to indicate that the input value is unavailable. As SAMPLE is a continuous process, there is always a last read value which is available. This means that it is not possible to break out of the loop in the above example by the operator indicating a break. One possibility would be to use the number of the normalization transformation to achieve the break. As the operator moves the locator within the viewport, the duck is redrawn. As soon as he moves outside the viewport, the interaction terminates:
SET WINDOW(1, XMIN, XMAX, YMIN, YMAX)
SET VIEWPORT(1, XVMIN, XVMAX, YVMIN, YVMAX)
SELECT NORMALIZATION TRANSFORMATION (1)
SET VIEWPORT INPUT PRIORITY(1, 0, HIGHER)
SET LOCATOR MODE(WS, DV, SAMPLE, ECHO)
100 CONTINUE
SAMPLE LOCATOR(WS, DV, NT, X, Y)
IF(NT .EQ. 0) GOTO 200
NEW FRAME
DRAW BACKGROUND
DRAW DUCK AT(X, Y)
GOTO 100
200 CONTINUE
This is not a very good way to terminate the interaction as it is difficult to indicate a final position, A better way of doing this will be given after EVENT mode has been described (see Section 6.7).
SAMPLE mode has been demonstrated with a locator device, but a device of any input class can operate in SAMPLE mode, Let us consider the example in Section 5.6 (see Figure 5-11) where REQUEST input was used to change the size of the duck and redisplay it. The operator could not see the effect of any input until the trigger had been pressed to input the next value, Only at this time would the program redisplay the duck at the new size, SAMPLE removes this difficulty, in the same way as we have already achieved for locator. Also, we can sample more than one device at the same time. This is not possible with any REQUEST function, because, in that case, the program is suspended until the input is terminated.
In the following example, one valuator device controls the size of the duck and one its orientation.
SET VALUATOR MODE(WS, DV1, SAMPLE, NOECHO)
SET VALUATOR MODE(WS, DV2, SAMPLE, NOECHO)
100 CONTINUE
SAMPLE VALUATOR(WS, DV1, SIZE)
SAMPLE VALUATOR(WS, DV2, ROT)
EVALUATE TRANSFORMATION MATRIX(FX, FY, 0, 0, ROT, SIZE, SIZE, WC, MAT)
SET SEGMENT TRANSFORMATION(DUCK, MAT)
GOTO 100
If an input device is put into EVENT mode, any input values are placed in the input queue for the application program to read. The application program reads each input value in order and deals with it before handling the next.
As the application program and input process are both active together, it is possible for the application program to look at the queue when no new inputs have been made. Alternatively, it is possible for the input device to fill the queue completely up before the application program examines it. The condition of input queue overflow is examined in more detail in Chapter 9.
Consequently, GKS needs functions to check the queue for events and to remove items from the queue.
It should be remembered that there is a single input queue for all devices. It is possible to have several devices active in EVENT mode at the same time. Input data from each device are added to the queue as they are generated, together with information indicating which device produced the input. The GKS function to check the queue is:
AWAIT EVENT(TIMEOUT, WS, DVCLASS, DV)
The queue is examined to see if it is empty. If it is, the application program is suspended until an event is generated or a maximum of TIMEOUT seconds have elapsed. In the latter case, DVCLASS returns the value NONE. TIMEOUT can be zero, in which case AWAIT EVENT always returns without suspending the application program.
If the queue is not empty, either when AWAIT EVENT is called or before the TIMEOUT occurs, information concerning the first event in the queue is returned. WS and DV specify the input device while DVCLASS specifies its input class (LOCATOR, PICK, etc). The input data are removed from the queue and transferred to the current event report.
Once it is known that an event has occurred from a particular class of device, the appropriate GET function is called to read the input data from the current event report. To read locator input data, the function:
GET LOCATOR(NT, X, Y)
is used, where NT is the transformation number and (X, Y) is the position. Note that it is only necessary to return the data values specific to the device. The class of device from which the data originated is known from the information returned by the call to AWAIT EVENT.
Let us consider a simple example where an operator uses a single locator device to input a set of positions defining a polyline. Each locator position that is input is indicated by a marker. The operator indicates that he has completed the polyline by inputting a position in a small top region of the screen. At this stage, the polyline will be drawn through the sequence of marked points that have been input (see Figure 6-2). The program might be:
SET WINDOW(1, XMIN, XMAX, YMIN, YMAX)
SET VIEWPORT(1, 0, 1, 0, 0.8)
SET WINDOW(2, X2MIN, X2MAX, Y2MIN, Y2MAX)
SET VIEWPORT(2, 0, 1, 0.8, 1)
SET VIEWPORT INPUT PRIORITY(0, 2, LOWER)
SELECT NORMALIZATION TRANSFORMATION(1)
SET LOCATOR MODE(WS, DV, EVENT, ECHO)
NPTS=O
100 CONTINUE
AWAIT EVENT(6000, WST, CLASS, DEV)
GET LOCATOR(NT, X(1), Y(1))
IF(NT .EQ. 2) GOTO 200
NPTS=NPTS+1
XLIST(NPTS)=X(I)
YLIST(NPTS)=Y(I)
POLYMARKER(I, X, Y)
GOTO 100
200 IF(NPTS .GE. 2)
POLYLINE(NPTS, XLIST, YLIST)
As there is only a single device active, any input data must be from the locator specified by WS and DV. Consequently, it has been assumed that the values of WST and DEV returned have these values. Similarly, it is assumed that CLASS has the value LOCATOR when an input is received. The only other possibility is NONE but we have set the TIMEOUT value very high so that the operator is bound to have input a value before the timeout occurs. Of course, a more precise program would do all the necessary checks.
This simple example does not really show the power of EVENT mode over REQUEST mode. The particular strength of EVENT mode is if the operator has a number of devices under his control or if the application program has other things to do between accepting events (like controlling a power station).
An example showing how more than one device can be used in EVENT mode illustrates the power of this type of input. Suppose we wish to input a number of points to be marked on the screen by one of several different representations. The particular representation can be selected using a CHOICE device. The representation selected will be used for all subsequent points input until another representation is selected:
SET POLYMARKER INDEX(1)
SET LOCATOR MODE(WS, DVL, EVENT, ECHO)
SET CHOICE MODE(WS, DV2, EVENT, ECHO)
100 CONTINUE
AWAIT EVENT(600, WST, CLASS, DEV)
IF(CLASS .EQ. NONE) STOP
IF(CLASS .EQ. LOCATOR) GOTO 200
GET CHOICE(STATUS, CH)
IF(STATUS .EQ. NOCHOICE) STOP
SET POLYMARKER INDEX(CH)
GOTO 100
GET LOCATOR(NT, X(1), Y(1))
POLYMARKER( 1, X, Y)
GOTO 100
The operator has the freedom to output a set of points marked with the same representation or to choose a particular representation, realize he had made a mistake, and select another before marking another point. This example gives a flavour of the flexibility available. The program terminates when the operator stops making any input before the timeout expires, or makes no selection with the CHOICE device.
A third GKS function exists to provide a housekeeping function on the queue. It is feasible for the operator to input more than one value from a device when only one was required by the program. In GKS, the following function exists to remove all unwanted input from the queue:
FLUSH DEVICE EVENTS(WS, DVCLASS, DV)
When called, it removes all inputs in the queue from the device whose class is DVCLASS and which is specified by WS and DV.
In Section 6.5, we saw how to achieve a much smoother interaction using SAMPLE mode rather than REQUEST mode. In the example, the duck moved around as the locator position was changed rather than waiting for the operator to indicate that the duck should be redrawn at a particular new position as happens with REQUEST mode. We also saw, however, that it was rather clumsy to terminate this style of interaction as it was impossible to indicate that an input value was unavailable. The solution suggested was to use a different normalization transformation but this necessitated moving the duck outside the viewport of the normalization transformation being used. This is not a natural termination and, in any case, makes it difficult to indicate a final position for the duck.
We can provide a much more elegant solution to the problem if we use a second input device in EVENT mode to indicate the end of the interaction. A button could be pressed or a key could be hit. In either case, this could be done using a choice device having a single choice, but any choice device would suffice. Thus:
SET LOCATOR MODE(WS, DV1, SAMPLE, ECHO)
SET CHOICE MODE(WS, DV2, EVENT, NOECHO)
100 CONTINUE
SAMPLE LOCATOR(WS, DV1, NT, X, Y)
NEW FRAME
DRAW BACKGROUND
DRAW DUCK AT(X, Y)
AWAIT EVENT(D, WST, CLASS, DEV)
IF(CLASS .NE. CHOICE) GOTO 100
FLUSH DEVICE EVENTS(WS, CHOICE, DV2)
Now, the duck will move around as the locator position is changed, assuming that the redrawing speed is fast enough, and when the desired position is achieved the operator may press the appropriate button or key to stop the process.
In this example, any choice value will suffice so that an event occurring will be taken as the terminating condition. To make sure that the sampling is not held up, we have used a timeout value of zero so that the application program continues to sample the locator immediately without waiting. Until the button is pressed, the CLASS value returned will be NONE.
We have used FLUSH DEVICE EVENTS just in case the operator pressed the button twice by accident and, therefore, left an extra event in the queue.
We may use a mixture of input devices in different modes for a more complex example. Suppose we wish the operator to define an area by use of a locator device and we wish to provide him with an up to date echo of the currently defined area. GKS does not provide such an echo and so we must provide the echo from the application program (this is called feedback). In the example, the operator moves a point around using a locator device, and the application program displays the current area, as feedback. When the operator is satisfied with that point he presses the key corresponding to the first choice. In a similar manner, he then uses the locator to decide on the next point pressing the key when he is satisfied. When he is satisfied with the complete area he presses the key corresponding to the second choice. If the operator indicates NOCHOICE, that is ignored. Thus:
SET LOCATOR MODE(WS, DV1, REQUEST, ECHO)
REQUEST LOCATOR(WS, DV1, ST, NT, XAR(1), YAR(1))
NP=1
SET LOCATOR MODE(WS, DV1, SAMPLE, ECHO)
SET CHOICE MODE(WS, DV2, EVENT, NOECHO)
CREATE SEGMENT(AREA)
CLOSE SEGMENT
100 CONTINUE
NP=NP+1
XAR(NP+1)=XAR(1)
YAR(NP+1)=YAR(1)
200 CONTINUE
SAMPLE LOCATOR(WS, DV1, NT, XAR(NP), YAR(NP))
DELETE SEGMENT(AREA)
CREATE SEGMENT(AREA)
FILL AREA(NP+1, XAR, YAR)
CLOSE SEGMENT
AWAIT EVENT(0, WST, CLASS, DEVICE)
IF(CLASS .NE. CHOICE) GOTO 200
GET CHOICE(STATUS, CH)
IF(STATUS .EQ. NOCHOICE)
GOTO 200
IF(CH .EQ. 1) GOTO 100
FLUSH DEVICE EVENTS(WS, CHOICE, DV2)
Figure 6-3 illustrates the situation when the operator is choosing the fifth point of the area. As we wish to display the current area, we have put the fill area in a segment. This allows us to delete the old area each time round the sampling loop.
Once again, we have used FLUSH DEVICE EVENTS to remove any extra unwanted events remaining in the queue.