User interface

Previous: Structure of the system Up: Final report on the Algebra Assistant Next: User interface

User interface

The event handlers are the active part of the system. Certain events to equationView windows, are dispatched again to specialized, mode dependent event handler objects. The objects maintain state about what is happening with the event and modify the boiteView structure to reflect it.

The major event handler is the selectionEventHandler. This handler allows the user to click on a glyph and have it selected. The selection of the glyph is indicated by setting a flag in the associated boiteView. This flag causes the boiteView to draw things in a different way. Presently, it causes reverse video to be used. It could also switch to another colour, or use some other visual cues.

If the user clicks again on the same object, the area of selection is expanded upwards a level in the equation. For instance, if the equation was being displayed, and was selected, and the user clicked on again, then would be selected. Another click would result in the whole equation being selected.

If the user clicks on something that isn't an equation on its own, that is it is actually decoration (such as the + symbol, the line in the fraction, or parenthesis), then all of the equation associated with that decoration would be selected. In the above example, clicking on the + symbol would select .

Note, however, that in an equation such as where this is in fact an addition operation with three arguments rather than or , clicking on either + symbol would result in the entire equation being selected. A satisfactory solution to the case where the user really wants to select just has not been worked out yet. If the user wanted to select and , some kind of extended select (usually implemented by hold down shift when you select something else) could be implemented. The solution the problem is probably for the user to select the and the , and then perform some operation that converts into .

The above scenario presents a further problem: the user is likely to not realise that this transformation is required until after they have selected whatever tool they want to use.

In the painting program model, you select and tool and then you use it, but in the above case, it would probably be more convenient to select what you wanted and then tell the system what to do with it. This later model I call the stack, or forth model, since it is quite easy to implement it by pushing items on a stack, and then having the tool gadget pull them off and perform an operation on them. This is the original reason behind naming the auxiliary views stackEquationViews. It was supposed to show the top elements of the stack.

The dispatching of events to a separate event handler makes the painting program model easy to implement. As you select different tools, you just change the event dispatcher. However, since there are multiple windows involved, the only real effect of selecting a button is that the contents of topView's handlerForNextWindow is changed.

Every time an enterNotify event is received, the current type of handlerForNextWindow is checked. If it differs from the handler that is currently in place, the handler that is in place is replaced, and then the enterNotify is passed on to that handler..

The handlerForNextWindow variable can also be changed by an event handler in response to a user doing something. For instance, in the case of the substitutionSelectionEventHandler, once the user has selected the first equation, the variable is changed to make the substituteeSelectionEventHandler current. This allows the user to select what is to be replaced. When the user has made that selection, the substitution itself is made.

This process can be seen in figures -.