7.7. Framework Agents
7.7.1. Action event queue
As seen in Chapter 5, action events in DAL fall into one of three categories:
i) Primitive events, eg; Mv.
ii) Primitive events in a specified context, eg; [ ]Mv.
In implementing a run time kernel for DAL on a Macintosh the events obtainable from the Macintosh toolbox event manager are mapped onto the corresponding DAL events. In the case of primitive events (i), there is a direct mapping from one to the other. In the case of primitive events in a defined context (ii), the mapping is the same, but the event requires further evaluation when presented to a J.I.dialogue. The corresponding widget needs to assess if the event does in fact fall into its context.
In the case of the Macintosh, there is a small group of primitive DAL events that have to be derived from other events generated by the toolbox event manager. These are events associated with the depression or release of modifier keys (SHIFT, OPTION and COMMAND). In the case of these keys, separate toolbox events are not generated, but the state of these keys is recorded in a modifier mask associated with all other events. In order to generate these
extended
Macintosh events the Action Event Handler needs to maintain a simple finite state machine for each of these keys. A change in the state of a modifier flag between successive events causes a change in the corresponding FSM and the production of an appropriate DAL event.The production of these extended Macintosh events can give rise to activation races. It is undefined as to whether they are produced before the event from which they were derived. It is also undefined as to the order in which such events are generated with respect to each other in the case where multiple extended Macintosh events are produced from a singl� toolbox event. Any circumstance that can cause non-deterministic event ordering can give rise to race conditions (Chapter 6). Although such races are possible, in practice they are unlikely and generally not serious.
Events i n the final category (ill) are more difficult to obtain. All events produced by the Macintosh event manager contain the global coordinates of the curser at the time of the event. It follows that in order to generate a Change of Context (CoC) event, it is necessary to use this information from
all
events, so that the curser path can be traced. To establish a change of context the spatial context of every event to the specified widget must be established and the appropriate CoC event issued when the context is observed to change in the specified direction. Essentially the event coordinates are used to drive a finite sta temachine (Figure 7.7), transitions in which cause the corresponding CoC events to be generated.
Event in context
Event not in context Generate [ ]-
Event in context
Figure 7.7: Generation of CoC events.
Since every primitive event has to be examined in order to generate CoC events,
if the change of context was determined local to the Jldialogue requiring the CoC, every event would need to be passed down the Jldialogue, a nd the propagation and processing overhead would be considerable, and possibly u nacceptable. In order to overcome this problem, CoC generation in PIPS is handled at the highest possible level.
If
a J!dialogueis interested
in a CoC event, then its interest is registered with the Action Event Handler (AEH). In registering a CoC, the type of CoC ( move_into_context or move_out_of_context) and a pointer to the corresponding widget are recorded. A widget is a C++ object that has a Boolean 'Hit' method that for a specified global coordinate returns true if the coordinate falls inside the widget.When a CoC event is initially registered the context of the cursor is unknown. As shown in figure 7.7, the approach taken in PIPS is to maintain three current context states, with . the initial state being UNKNOWN. Only transitions between known context states cause CoC events to be generated. The corresponding handler is described in structured English in Figure 7.8.
FOREACH ( CoC interest record ) DO IF ( state is UNKNOWN ) THEN
IF ( if event coordinates within widget ) THEN set state to IN_ CONTEXT
ELSE
set state to NOT_IN_CONTEXT END IF
ELSE ... we know the previous context ... IF ( interested in a MOVE_INTO _CONTEXT ) THEN
IF ( state is NOT _IN_ CONTEXT AND
event coordinates within widget ) THEN set state to IN_CONTEXT
emit a MOVE_INTO _CONTEXT event
END IF
ELSE ... interested in a MOVE_OUT_OF _CONTEXT event ... IF ( state is IN_ CONTEXT AND
event coordinates are not within widget ) THEN set state to NOT_IN_CONTEXT
emit a MOVE_OUTOF _CONTEXT event END IF
END IF END IF
END FOR
Figure 7.8: CoC Handler.
It is possible for a JJ.dialogue to be interested in both a
move into context
andmove
out of con text
events. This is achieved by each event type being registered separately, and hence generated by the firing of a separate FSM.Because a single primitive Macintosh event may give rise to several corresponding DAL events, this may in turn lead to non-determinism in the resultant system since the order in which these events are generated is undefined. This can cause activation races (see Chapter 6). This is a major
implementation problem for DAL, although in practice it is perhaps not as
severe as may first be imagined. In processing a single Macintosh event, the
AEH can produce a single primitive event, and any number of CoC events. To
get around the order problem the convention is followed that if a primitive
event is issued, then this is done first, and only then are any CoC events issued.
Any CoC events will be generated in a undefined order. Hence, a JJ.dialogue
hierarchy with CoC activators or deactivators
m ay
be non-deterministic. ForA ( - [ ] } ( ) {
}
B ( - [ ] ) ( ) { }
Figure 7.9: CoC activation race.
In practice the need for such systems is rare and the spatial relationships of A
and B may well be such that the actions of - [A ] and - [B ] are mutually exclusive, a nd cannot be generated in the same event cycle. Consider the widgets shown in figure 7.10. The curser has to be moved into the context of A
in order to move into the context of B . Only after we have moved into the context of B, and that fact has been recorded by the AEH can a [B ]- event be generated. Hence -[A] and -[B] must be generated on separate event cycles. In this case the system is perfectly deterministic and there is no problem.
Figure 7.10: A spatial relationship between widgets A and B that would ensure that -[A] would be generated before -[B].
Only in the case of disjoint or spatially dynamic display object groupings can undefined CoC event sequences be generated.
B
y
(a) (b)
Figure
7.11:
CoC non-determinism due to spatially disjoint object groupings.Consider the widget groupings depicted in figure
7.11
(a) and (b). X and Y in these diagrams represent possible cursor tracks. In both (a) and (b), if the events[A]� and [B)� were registered as being of interest, the order in which these events would be generated would be reversed in the case of track X compared with track Y. This may be of use to the designer, since it offers a means for determining the direction of a simple gesture command . However, if these events were used to activate a hierarchy of the type shown in figure 7.9 without regard for the fact that the outcome would be dependent on the direction of the users actions, then this would lead to a faulty design.
A potential problem with CoC events is that they are generated as a result of a spatial assessment of coordinates of the current primitive event at the time the CoC event is generated. Since this event may be queued for processing on some subsequent execution cycle, and that the corresponding widget may have been moved between the event being generated and its subsequent presentation to a Jldialogue for processing, the CoC event could be out of synchronisation with the rest of the system. This is unlikely, but not impossible.
Another purpose of the AEH is to deal with display refreshes when windows become exposed . The widgets used by PIPS all make use of the normal Macintosh toolbox routines. When the content of a window needs updating due to the window being resized or a window in front of it being moved or resized, the toolbox event manager generates an update event that identifies the Macintosh window concerned. The AEH picks up this event in its normal event cycle a nd maintains a mapping of Macintosh window identifiers to the corresponding dialogues. On receiving an update event, the AEH tells the corresponding dialogue to update its display. The dialogue tree from this point down is then scanned, with each dialogue making its corresponding widget redraw itself. The recursion is terminated either at a terminal dialogue or at a dialogue with a widget which is itself a Macintosh window.