Scrollable

Team,

I've done some "research" into the GTK and QT toolkits.  There are 2
approaches: 1) The scrollable model (GTK) that I mentioned in the last
mail 2) The Scrollbox class pattern (QT) where each widget that may need
scrollbars inherits from scrollbox.

In my opinion, we don't want to inherit from scrollbox as every
descendent will then have scrollbars, and we won't use them very often. 
It also limits the ways in which those widgets could be used.  So method
2 is out.

If we don't use method 1, then we run into some problems.  By defining a
scroll_box to contain a viewport, we have no way for a widget to know
when it needs to scroll up or down.  Since the viewport would see a
button and a text area with the same interface, it wouldn't know when
the text area needs to scroll down do to new lines, or back up when the
user pushed the up arrow repeatedly.  The only clean way to make this
work is for the text_area to be aware of the scroll_models.  This argues
for method 1, descending from Scrollable.  This turns out to be how GTK
does it.

If you try and add a button to a scrollwindow, you need to first add a
viewport (a scrollable) and then add the button to that.  But a textview
can be added directly to a scrollwindow (since it is a scrollable too).

GTK uses container for its scrollable class.  I don't like this idea for
I think obvious reasons and would rather have widgets that need
scrolling to derive from scrollable.

I am going to start this implementation, but will still listen to
arguments for a different approach.  In my opinion this approach
satisfies the expressed wish to keep scrollbars out of the widgets, but
enables us to easily have the scrollable widgets communicate with a
scrollbox (or other scrolling widgets like just a scrollbar).

Darren