Skip to main content Skip to navigation

Department of Computer Science

Lab 5: More about the Scout notation

Preliminaries

For this lab, you can once again work in the personal directory called lab4 that you set up within your cs405practical directory in Lab 4. As in that lab, you begin by invoking the EDEN interpreter from the command line, navigating to the roomviewerYung1991 directory and executing the file Run.e.

For Exercises 1 and 2, you may find it helpful to remind yourself of the "instructive interactions" presented in the files scout1.s and sde3.eden that were introduced in Lab 4.

Further instructive interactions particularly relevant to Exercise 3 below can be found in the file Exercise0.eden in the ~empublic/teaching/cs405/lab5 directory. You are intended to reset the roomviewer model to its initial state before interpreting this file. Remember to enter the contents of Exercise0.eden definition-by-definition and pay attention to the comments embedded in it.

For background references relevant to this lab, refer to the online material associated with Lectures 6 and 7, which includes these Notes on Defiinitive Notations.

There are some known technical issues with tkeden-1.73, particularly in relation to the use of the todo() construct for implementing a clock (as illustrated in models such as racingGardner1999 and oxoGardner1999). Please report any such issues you encounter to the lab tutors, and - if you can do this conveniently - record the relevant history of interaction. In running older models with this feature you can use tkeden-1.67 (and tkeden-1.67A for the Mac), which is also an acceptable alternative for your practical model-building for WEB-EM-8. You can invoke this variant of EDEN using ~empublic/bin/tkeden-1.67. In implementing a clock using tkeden-1.73, you can use the edenclocks construct as documented in the Eden quick reference via the tkeden Input Window.

Note for advanced or impatient students

If you are already familiar with the material covered in these exercises, or feel that you can tackle these in your time, you may prefer - especially if you are an MSc student - to use the lab sessions to engage with the construal comprehension exercises. Even though MEng students are not required to do these exercises for credit, they are encouraged to check them out.

Exercise 1: How Scout describes screen layout

  • Trace the set (or a representative subset) of dependencies that determines the windows that make up the screen display.
  • Identify which observables determine the size and location of the lefthand window containing the Donald floorplan of the room.
  • Find the definition that determines the text displayed on the door button (as defined by the doorButton TEXT window in Scout).
  • How would you change the background colour and the colour of the text displayed on the door button?
  • How would you place a single rectangular window behind the windows displaying the floorplan and the enlarged floorplan in such a way as to provide a blue background?

Exercise 2: How Donald drawings are displayed in Scout windows

  • Inspect the definitions of the Scout windows that display the floorplan and enlarged floorplan. Explain why the pict field is the same in both windows.
  • How would you interchange the drawings displayed in the two Scout windows of type DONALD?
  • How can you determine the Donald coordinates of a point in the floorplan and enlarged floorplan displays solely by using mouse clicks?
  • By assigning new values to the observables zoomPos and zoomSize and observing the impact on the Scout window containing the enlarged floorplan, explore the role played by the xmin, xmax, ymin and ymax fields within the definition of the window.
  • Suppose that a Scout window of type DONALD displays a line drawing without any distortion. What relationship must there be between the dimensions of the window and the values of the fields xmin, xmax, ymin and ymax?
  • Make use of Donald variable of type shape to specify an image of the table rotated through an angle that can be freely specified via the input window (see Exercise 3 from Lab 4 and refer to the script fragment given in the Appendix to Lab 4). Revise the definition of the Scout window that presently shows the enlarged floorplan so that it instead displays the rotated table.

Exercise 3: How GUI agents are specified in Scout and Eden

  • Determine what Eden redefinition is executed when the door button is clicked. Confirm that this redefinition can be entered directly through the input window and explain why it has the effect of opening or shutting the door.
  • Modify the Eden action associated with the door button so that it toggles the colour of the door from red to green. Explain why this is a less satisfactory way of specifying the colour of the door than using a definition as proposed in Exercise 3 from Lab 4.
  • Adapt the Eden action associated with the door button so that it counts the number of times the door is opened. Modify the text on the door button so that it displays this count.
  • Identify the Eden action that is triggered by clicking the mouse in the Scout window displaying the floorplan. Explain how this action moves the table.
  • Explain why the buttons that relocate the table no longer work correctly when the rotating table mentioned in Exercise 2 is introduced. Fix this problem.

Footnote on the design of Scout

Querying the don1_mouse observable returns the following result:
don1_mouse ~> [don1_to_tableSW, don1_mouseButtonPress, ...];

This discloses that it acts a trigger for two actions: don1_to_tableSW() and don1_mouseButtonPress(). By querying these actions in turn, you will determine that the first of these actions has an effect on state (cf. Exercise 3 above), whilst the second action does nothing. The presence of the second action is the result of a well-intentioned but somewhat ill-conceived extension of Scout to allow VB-like actions to be automatically introduced - through specifying the procedure don1_click(). There were no such actions in the original design of Scout, and the roomviewerYung1991 predates their introduction. You can demonstrate the redundancy of the don1_mouseButtonPress() action by removing it using the Eden forget() command (though it will of course be re-introduced whenever the window don1 is redefined):

forget(&don1_mouseButtonPress);