D X-WINDOWS implementation notes

 D.1 GWM interface
 D.2 Memories
 D.3 Overlays
 D.4 Writing to the memories
 D.5 Zoom
 D.6 Look-up tables
 D.7 Interactions
 D.8 Cursors
 D.9 Text
 D.10 Deficiencies

D.1 GWM interface

IDI uses the Graphics Window Manager to look after the creation and management of the display window. When IDI opens (IIDOPN or IDI_ASSOC) it first looks for an existing GWM window with the given name, and if it finds one it attaches to that, otherwise it creates a new window with the default characteristics. The window pixmap, which is used by GWM to store the picture, is then read by IDI and stored in an internal memory. The purpose of this is to enable existing displays to be manipulated by IDI, for example a picture drawn with GKS can be scrolled using IDI. In an ADAM application ’READ’ or ’UPDATE’ mode should be used in IDI_ASSOC if an existing display is to be manipulated.

If an application wants to start with a clean sheet then the display should be reset. In an ADAM application this is done by specifying ’WRITE’ mode in IDI_ASSOC. In a non-ADAM application the routine Reset Display should be called immediately after Open Display.

D.2 Memories

When an X-window device is opened one memory is made available (identifier 0) which corresponds to the window pixmap. The size of the memory is equal to the size of the pixmap, which can be different to the size of the window.

D.3 Overlays

If a GWM window contains an overlay plane then this can be accessed as if it were a separate memory (identifier 1). The overlay memory depth is only one bit but it can be accessed like any other image memory. It can be written to with Write Memory, Polyline or Plot Text. It can be scrolled and zoomed separately to the base memory. It has a separate look-up table (identifier 1) to the base plane. Although the memory is only one bit deep the overlay LUT has as many entries as the base LUT, however every entry contains the same overlay colour. If the overlay colour is to be changed then the new colour should be sent to all the pens in the overlay LUT.

D.4 Writing to the memories

Most workstations running IDI will have an 8 bit display, but the full 8 bit capability of the device is not normally available. The X-windows driver will reserve a number of pens for its exclusive use and GWM will not normally allocate all the available pens to one window. The look-up table length is adjusted by IDI to match the number of pens allocated to the GWM window. The default intensity transformation table is adjusted, so that data values going from 0 to 255, map linearly onto the look-up table going from 0 to the allocated length. For instance, if the look-up table contains 64 entries then a data value of 0 will be assigned to pen 0 and a data value of 255 will be assigned to pen 63, with intermediate values scaled appropriately. The number of pens allocated to the window can be inquired using Query Capabilities Integer with capability number 18 (INLUTC), or can be inquired from GWM using GWM_GETCI.

The input to the image display routines Write Memory, Read Memory is an array of integers, and the arguments packing factor and data depth control how the data to be displayed is packed into a single integer word.

D.5 Zoom

The X driver does not support hardware zooming and so the zooming has been implemented in software. The current implementation allows zooming by factors of up to 32 times. The zoom factors go from -31 to 31, with 0 as no zoom. Negative zooming (zoom factors less than 0) is not currently supported for interactive operations.

D.6 Look-up tables

Each window has one look up table (LUT) and one intensity transformation table (ITT) per memory. The intensity transformation table is used to translate pixel numbers into entries in the look up table.

D.7 Interactions

The X-windows interface supports two interactor types; locators and triggers. Two types of locator are supported: the mouse interactor identifier = 0 and the keyboard arrows interactor identifier = 1. The action of the keyboard arrows can be speeded up by simultaneously depressing the SHIFT key. When using the keyboard as an interactor the window focus has to be shifted to the display window by clicking in the window or on the title bar.

The number of available triggers can be inquired using capability code 55 (INTRIG) in Query Capabilities Integer. Triggers can be either the mouse buttons (identifiers 0, 1, 2), or keys on the keyboard (identifiers 3 to 54). The table lists the current set of triggers and the corresponding identifiers.







Id

Trigger

Id

Trigger

Id

Trigger







0

Mouse button left

20

G key

40

0 key

1

Mouse button centre

21

H key

41

1 key

2

Mouse button right

22

I key

42

2 key

3

Up arrow

23

J key

43

3 key

4

Up arrow shifted

24

K key

44

4 key

5

Left arrow

25

L key

45

5 key

6

Left arrow shifted

26

M key

46

6 key

7

Right arrow

27

N key

47

7 key

8

Right arrow shifted

28

O key

48

8 key

9

Down arrow

29

P key

49

9 key

10

Down arrow shifted

30

Q key

50

Period key

11

Keypad PF4

31

R key

51

Plus key

12

Space bar

32

S key

52

Minus key

13

Return key

33

T key

53

Shift key left

14

A key

34

U key

54

Shift key right

15

B key

35

V key

16

C key

36

W key

17

D key

37

X key

18

E key

38

Y key

19

F key

39

Z key







A user can be informed of the appropriate trigger by obtaining a description from the routine Query Interactor Description.

At present only a few of all the possible interactions have been implemented. A non-zero error status will be returned from Execute Interaction and Wait if the interaction has not been implemented. The table shows the implemented interactions with a cross ( + ).

X-windows Interaction Cross Reference
























Description

No effect

Cursor

ITT

VLUT

ROI

Memory

Display









Application specific code

+

.

.

.

.

.

.

Move object

+

+

.

.

+

+

+

Rotate object

+

.

.

+

.

.

.

Increase zoom

+

.

.

.

.

+

+

Reduce zoom

+

.

.

.

.

+

+

Set zoom to normal

+

.

.

.

.

+

+

Blink object

+

.

.

.

.

.

.

Modify object

+

.

.

.

+

.

.









Scrolling a memory or the display with the mouse begins as soon as the hardware pointer enters the display window, and the memory moves as if it were attached to the hardware pointer, however scrolling does not happen if the mouse is moved too quickly.

With the X-windows interface it is possible to display a fixed cursor and to scroll and zoom the memory under it, although the default hardware cursor should not be used in this case. A fixed crosshair cursor or region of interest is made visible at the required position, and an interaction to scroll the memory is set up. The example program can easily be converted to perform this operation. To do this replace the cursor scroll interaction with a memory scroll interaction. Thus

        INTTY = 0
        INTID = 0
        OBJTY = 1
        OBJID = 0
        INTOP = 1
        EXTRN = 2
        CALL IIIENI( ID, INTTY, INTID, OBJTY, OBJID, INTOP, EXTRN,
       :             STATUS )

becomes
        INTTY = 0
        INTID = 0
        OBJTY = 5
        OBJID = MEMID
        INTOP = 1
        EXTRN = 2
        CALL IIIENI( ID, INTTY, INTID, OBJTY, OBJID, INTOP, EXTRN,
       :             STATUS )

When rotating the look-up table the action is controlled by the left and right movement of the mouse, or with the left and right keyboard arrows.

D.8 Cursors

The default cursor (cursor shape = 0) is the hardware pointer. When it is activated, and in the display window, it is shown by an open cross.

The cross hair cursor (cursor shape = 1), cross cursor (cursor shape = 2) and regions of interest (ROI) are drawn onto the screen using an exclusive OR (XOR). When using the mouse to control the movement of one of these cursors the hardware pointer has to be brought close to the centre of the crosshairs. When close enough the crosshair cursor becomes attached to the hardware pointer and will remain attached as long as the mouse is moved slowly. If the mouse is jerked quickly the hardware pointer and crosshair will part. When using a region of interest the hardware pointer has to be brought close to the active corner.

D.9 Text

Text is drawn with one of the preset device fonts. The text sizes small, normal and large are distinct, but the very large text size is the same as the large size. Only the default text path and text orientation are supported.

D.10 Deficiencies