HUMAN-COMPUTER INTERACTION SECOND EDITION
Dix, Finlay, Abowd and Beale

Search Results

Search results for screens
Showing 180 to 189 of 281 [<< prev] [next >>] [new search]

Chapter 10 Implementation support 10.2 Elements of windowing systems Page 379

Programmer's hierarchical interface to graphics (PHIGS) Another international standard, based on GKS but with an extension to model the screen as editable segments.

Chapter 10 Implementation support 10.2 Elements of windowing systems Page 379

PostScript A programming language developed by Adobe Corporation which models the screen as a collection of paths which serve as infinitely thin boundaries or stencils which can be filled in with various colours or textured patterns and images.

Chapter 10 Implementation support 10.2 Elements of windowing systems Page 380

When we discussed the WIMP interface as an interaction paradigm in Chapter 4, we pointed out its ability to support several separate user tasks simultaneously. Windowing systems provide this capability by sharing the resources of a single hardware configuration with several copies of an abstract terminal. Each abstract terminal will behave as an independent process and the windowing system will coordinate the control of the concurrent processes. To ease the programming task again, this coordination of simultaneously active processes can be factored out of the individual applications, so that they can be programmed as if they were to operate in isolation. The window system must also provide a means of displaying the separate applications, and this is accomplished by dedicating a region of the display screen to each active abstract terminal. The coordination task then involves resolving display conflicts when the visible screen regions of two abstract terminals overlap.

Chapter 10 Implementation support 10.2.1 Architectures of windowing systems Page 383

interprets requests from clients to perform screen operations or provide other information;

Chapter 10 Implementation support 10.2.1 Architectures of windowing systems Page 383

A separate client -- the window manager -- enforces policies to resolve conflicting input and output requests to and from the other clients. There are several different window managers which can be used in X, and they adopt different policies. For example, the window manager would decide how the user can change the focus of his input from one application to another. One option is for the user to nominate one window as the active one to which all subsequent input is directed. The other option is for the active window to be implicitly nominated by the position of the pointing device. Whenever the pointer is in the display space of a window, all input is directed to it. Once the pointer is moved to a position inside another window, that window becomes active and receives subsequent input. Another example of window manager policy is whether visible screen images of the client windows can overlap or must be non-overlapping (called tiling). As with many other windowing systems, the client applications can define their own hierarchy of subwindows, each of which is constrained to the coordinate space of the parent window. This subdivision of the main client window allows the programmer to manage the input and output for a single application similar to the window manager.

Chapter 10 Implementation support 10.2.1 Architectures of windowing systems Page 384

layout schemes for overlapping/tiled windows as screen regions.

Chapter 10 Implementation support 10.3 Programming the application Page 386

The program produces a window, or frame, with one button, labelled Quit, which when selected by the pointer device causes the program to quit, destroying the window (see Figure 10.7 for the screen image produced by the sample program quit.c). Three objects are created in this program: the outermost frame, a panel within that frame and the button in the panel. The output is shown in Figure 10.7. The procedure xv_create -- used on lines 17, 22 and 23 in the source code of Figure 10.6 -- is used by the application program to register the objects with the XView notifier. In the last instance on line 23, the application programmer informs the notifier of the callback procedure to be invoked when the object, a button, is selected. The application program then initiates the notifier by the procedure call xv_main_loop. When the notifier receives a select event for the button, control is passed to the procedure quit which destroys the outermost frame and requests termination.

Chapter 10 Implementation support 10.3 Programming the application Page 388

Control flow is centralized in the notifier, which relieves the application program of much of the tedium of processing every possible event passed to it by the window system. But this freedom from control does not come without a price. Suppose, for example, that the application program wanted to produce a pre-emptive dialog box, perhaps because it has detected an error and wants to obtain confirmation from the user before proceeding. The pre-emptive dialog effectively discards all subsequent user actions except for ones that it requires, say selection by the user inside a certain region of the screen. To do this in the read--evaluation paradigm is fairly straightforward. Suppose the error condition occurred during the processing of an event of type type_2. Once the error condition is recognized, the application then begins another read--evaluation loop contained within that branch of the case statement. Within that loop, all non-relevant events can be received and discarded. The pseudocode example given earlier would be modified in the following way:

repeat     

     read-event(myevent)

     case     myevent.type

          type_1 :     

               do type_1 processing

          type_2 :     

               Š

               if     (error-condition) then

                    repeat     

                         read-event(myevent2)

                         case     myevent2.type

                              type_1 :


                              .

                              .

                              .

                              type_n :

                         end case

                    until (end-condition2)

               end if

               Š

          .

          .

          .

          type_n :     

               do type_n processing

     end case

until (end-condition)

Chapter 10 Implementation support 10.4 Using toolkits Page 390

As we discussed in Chapter 4, a key feature of WIMP interfaces from the user's perspective is that input and output behaviours are intrinsically linked to independent entities on the display screen. This creates the illusion that the entities on the screen are the objects of interest -- interaction objects we have called them -- and that is necessary for the action world of a direct manipulation interface. A classic example is the mouse as a pointing device. The input coming from the hardware device is separate from the output of the mouse cursor on the display screen. However, since the visual movement of the screen cursor is linked with the physical movement of the mouse device, the user feels as if he is actually moving the visual cursor. Even though input and output are actually separate, the illusion causes the user to treat them as one; indeed, both the visual cursor and the physical device are referred to simply as 'the mouse'. In situations where this link is broken, it is easy to see the user's frustration.

Chapter 10 Implementation support 10.4 Using toolkits Page 393

A scrollbar is attached to the side of the window with arrows at the top and bottom. When the mouse is positioned over the arrow at the top of the screen (which points up), the window frame is moved upwards to reveal a part of the document above/before what is currently viewed. When the bottom arrow is selected, the frame moves down to reveal the document below/after the current view.

processed in 0.007 seconds