Validate
||
Pedestal
Validated HTML 4.0
Most frameworks, in the process of representing a visual hierarchy, resort to a pair of abstract concepts which they call 'views' and 'panes'. Although the names match, the actual concepts they're meant to denote usually vary across frameworks. While this variance is not problematic in and of itself (unless you're attempting to unify the frameworks), there is a disturbing lack of clarity around what the concepts actually are within a particular framework. This is evident from examining the class hierarchy. For example, there may be an abstract View class, which may support subviews or handle mouse clicks. Now, consider a checkbox: A checkbox is a kind of button, which is a control, which is a pane, which is a view. So a checkbox inherits mouse clicks -- but it also inherits subviews, which is inappropriate, or at least superfluous. On the other hand, an offscreen view is a view that generally speaking will have subviews (so there's something to be drawn offscreen) but has no need to handle mouse clicks. Although it might never result in erroneous runtime behavior, these inconsistencies nevertheless indicate a flaw in the design of the inheritance model. While it is possible to write working applications based on such a framework, the discrepancy between the model (e.g. the checkbox class) and that which is modeled (the conceptual checkbox that Mac users are familiar with) is a stumbling block for the developer. It is possible to be ever mindful and careful and never stub one's toe, but one is less likely to walk away unscathed than if the block weren't there in the first place.
Pedestal's primary design goals are accuracy/fidelity, elegance, and modularity. Nowhere are these three more evident than in Pedestal's visual model. The key distinction is the relationship between views and panes. Rather than the traditional incestuous liaisons espoused by already-existing frameworks, Pedestal introduces a respectful but no less intimate courtship. The revolutionary arrangement is this: Views and panes are distinct, disjoint types. One does not inherit from the other, nor do they share a common base (with the possible exception of a framework-wide root class). Furthermore, the abstract View class does not contain panes (or other views), and doesn't even know what panes are. The View class is a paragon of innocence -- or at least ignorance. The Pane class, however, does know about views -- in fact, every pane is contained by one, which is its superview. But it doesn't contain any panes or views either.
How can this be? How can anything be accomplished in such an austere model? The answer becomes apparent upon examination of a coterie of subclasses.
The first question concerns nesting, without which there is no hierarchy. Although the View class (PedView) doesn't contain anything, all view objects can contain panes, by virtue of some derived class. One example is PedWindow, which is defined has having exactly one pane. The mechanism for adding several panes where only one can fit involves a subview. The subview class (PedViewSub), a subclass of PedView, must be further derived from to define exactly how it contains panes (for example, a scroller contains up to two scrollbars and one content pane). The subview is associated with (not contained by) a subview-pane (PedPaneSubView) which is installed in the window. The containment of a pane by a view and the link between a subview and its subview-pane are not the same relationship. Likewise, a chicken laying an egg and an egg hatching a chicken are inequal operations (and note that the combined process is different from a live birth). In this case, however, we are not interested in the question of which came first (the view, if you're wondering), but instead the two-step manner in which they're nested.
Scrolling is a fairly complex process, involving several different activities. The content has to be redrawn and the scrollbars' values (and occasionally their maxima) must be adjusted. To further complicate things, there are different ways to cause scrolling to occur, with different procedures for implementing scrolling in each case. For example, if the user moves the scroll box, you just compare the scrollbar's value before and after and the difference is how much to scroll the content. However, if the user clicks in a scroll arrow or a paging region, you call ::TrackControl(), which repeatedly calls your ControlActionProc. Instead of sampling the control value to get the scroll distance, you supply it your own. You redraw immediately, instead of waiting for the next update event. But if you're scrolling to make a selection visible, then the distance is calculated and you scroll all at once, redrawing later (as with dragging the scroll box) but you still have to set the control value on the scroll bar. In all cases, if you've just scrolled away an area below the bounds of the content, you need to recalibrate the scroll bar's maximum. Finally, there are applications like MacPaint and Stickies which feature scrolling, but lack scroll bars.
Pedestal's approach is to divide the work. The scrollbar class (PedScrollbar) is a subclass of PedControl which is in turn derived from PedPane. A scrollview (PedViewScroll) is a subview that has one pane (the content pane) and a scroll position that determines which part of the pane is displayed. Scrolling does not affect the bounds of the content pane, just the scroll position. (It helps to think of the scrollview as an actual scroll. The document may be several feet long, but you only see a foot or so at a time.) Rounding out the set is the scroller class (PedViewScroller). A scroller doesn't actually perform any scrolling on its own, but it manages the interaction between the scrollbars and the scrolling object. Usually this object is the scrollview, but if the content pane manages its own scrolling (e.g. a TextEdit pane), then a customized scroller is called for. So a scroller object will be an instance of either PedViewScrollerStd or PedViewScrollerTE.