Previous: Boite inheritance tree Up: Hierarchy overview Next: Editor inheritance tree

View inheritance tree

Navel

provides a somewhat shallow layer above the primitive X objects. It offers a representation of the screen in terms of views, with a manager to actually receive X events, decode them pass them off to the proper window. James Noble wrote the original code as part of his tgim project.

originally had three major components: the view, the compoundView, and the viewManager objects. It has since been extended a bit. A compound view was a window that was intended to have other view (compound or simple) as subviews.

Originally a view was the highest level object in the hierarchy. Much of the higher level protocol has since been moved to a new object abstractView in order that the new lwView could inherit it as well. compoundView is currently a specialization of view. If it is desired to have compound light weight views, then compoundView should actually become a mixin object.

The motivation to have heavy weight views (which are real X object) and light weight views (which share their heavy weight parent's X object) is simple: a view provides a connection between the visual representation (the X protocol requests, etc) and the model (the abstract notion of what the thing is, and what is looks like).

If one wishes to have a huge number of different models on the screen, causing the X server to allocate resources for them all could be very wasteful.. Many models might be actually quite simple things: just a character For instance. The screen position of each object is still required though, and some kind of event handling and possibly a specialized screen representation is usually required. Further, a heavyweight window currently winds up getting a border around it.

As can be seen in figure , the light weight views have only been used to represent the pieces of the equation on the screen.

A boiteView structure exists for each glyph displayed in a window. They are not shared between windows if the boite happens to be displayed in multiple windows. The boiteView records the actual window position at which the glyph has been painted, while the boite records just its size. The boites position in the structure determines the relative location, but computation of the actual position from this structure is not something one wants to do while processing mouse clicks. The boiteView structure provides a good place to store things, and already provides the event dispatching based on event position.

The topView object, as previously described, is the top level object. It has the top level X window associated with it, and all other objects descend from it in some way or another, as was shown in figure .

equationView is a object that abstracts the mechanisms needed to display an equation. Its two specializations, stackEquationView and masterEquationView differ only in the way that they calculate their window position and size.

One problem that arose was connecting each of these windows with the topView. The windows were are already connected because they are subviews of the topView, however, distinguishing which is which is a problem. When constructing the prototypical topView object, it is easy to insert pointers to subviews into the appropriate places in the object, but new objects are instantiating, they are cloned from their prototype.

The compoundView object makes sure to clone all its subviews as well, but this would leave the previously inserted pointers pointing at the original (prototypical) objects. A post-cloning cleanup needed to be done, and was added in topView.

Finally, the button objects are specialized views that invoke particular actions when they receive events. These events will described in the next section. The editorButtons object is just a place holder to gather the various kinds of buttons that have been defined in one place. The buttons themselves are really just specializations of either textButton or imageButton, which is appropriate. Since the only difference between the buttons is the performAction method, these are actually prototypes to be cloned.