Previous: Structural overview Up: Structural overview Next: Polygon representation

View-Model representation

The main X window is divided up into eight portions. The majority of the window is the masterEquationView sub-window (upper right), with the right hand side devoted to six auxiliary equation view windows ( stackEquationViews). Finally, the area below the masterEquationView window is for control buttons, and instructional text. The two types of windows are actually just trivial specializations of an equationView types (not shown here). The later is what will be described. The best way to understand the structures presented is probably to follow the process arrived at to create them. When an equation is attached to a given window, the window asks the equation structure to produce a structure for it. This structure for the equation can be seen at the right of the figure. The structure described the relative placement of the various components and is based mostly on the box described by Knuth in [], in the chapters on Glue and Building boxes.

Once the structure is built, the sizes of the various pieces is filled in by queries to the X font primitives. This section is necessarily X windows specific. The sizes returned are used to set up the minimum sizes of the actual letters and symbols. This means that position calculations are done in terms of X screen locations, which is just fine, since that is the also the system used to position items in a window.

In a future version of the code, the sizes will be determined for several different fonts in order that appropriate selection of smaller fonts for exponents, etc.. can be done.

At this point, the structure has had all the positions of its displayable parts determined, and a request is made for it to generate light weight view objects. These are depicted on the left hand side of figure . The light weight views differ from heavy weight views in the following ways:

1. they do not have their own coordinate system
2. they do not have event masks, nor do they receive events unless explicitly delegated by their heavyweight parent.
3. they do not have any structures associated with them in the X server, so all drawing must be delegated to a heavyweight parent.

The structure labeled boiteSubViews needs a little bit of explanation. It should be noted that not all elements have a light weight view associated with them. Only things that are actually drawn on the screen are given representation at this level, and that representation is a flat one. The serves as the views' model, and during redraws, the view requests its model to draw a representation of itself on the view.

This link is unidirectional, and in the interest of future structure sharing a reverse link is implemented by means of a dictionary indexed by the elements themselves.

The reverse link is used, for instance, when expanding a selection to include parts of the enclosing equation. New view structures must be added to a set of highlighted views, so a connection is needed to find them. The highlighting of an equation is considered a modification of the view not of the model. The model calls methods in the view it is handed in order to draw, and it is these methods that determine how and whether to highlight.