Re: Scrollable Widgets (Re: GtkText & scrollbars)

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> On 12 Oct 1998, Owen Taylor wrote:
> 
> > 
> > "Damon Chaplin" <DAChaplin@email.msn.com> writes:
> 
> > > It would also help GUI builders, since connecting the scrollbars to the
> > > text widget is pretty awkward. (But using a CList is simple.)
> > 
> > What really should be done (TM) - is that scrollbars should be _removed_ 
> > from all widgets that have them currently. And then there should
> > be a generic interface added so that you could drop a
> > Viewport, a Text widget, a CList, a CTree, a GtkLayout, a
> > GnomeCanvas... etc. inside a GtkScrolledWindow and
> > it would work.
> > 
> > (Currently, a GtkScrolledWindow can only contain a GtkViewport)
> > 
> > Probably the way this would work is that any widget that
> > wanted to be scrollable in this way would create a signal
> > 
> >  "set_adjustments" (GtkAdjustment *hadj, GtkAdjustment *vadj);
> > 
> > and the ScrolledWindow would check for the existance of such
> > a signal when a child was added to it.
> 
> hm, what does "should" actually mean in the above sentence (i.e. do
> you really want to enforce this idea at some point)?

It mean's that I'd love to have it done for 1.2, but don't have the
time to work on it myself right now. I think it is worth breaking
backwards compatibility a bit if we need to.

> what's actually problematic?

> several widgets implment unneccessary complexity in order to get
> scrolling facilities. the complexity actually consists of the widget
> being a composite widget so it can handle scrollbars and thus
> occasionally widgets need to implement container behaviour where it
> is not really required.  as a side effect these widgets usually
> can't be properly default constructed, because the scrollbar
> adjustments are a somewhat mandatory part of the widget
> implementation itself and thus have to be provided at construction
> time, we gain a lot of unneccessary construction problems with that
> for language bindings and gui builders.  also the code duplication
> for scrollbar handling is a waste of effort and prune to bug
> duplication (e.g. getting the GTK_POLICY_ALWAYS and
> GTK_POLICY_AUTOMATIC handling right).

> the widgets in question are GtkText, GtkCList, GtkLayout and
> eventually some other third party widgets that i'm not currently
> aware off (GnomeCanvas inherits from GtkLayout and GtkTree doesn't
> implement scrolling facilities itself).

GtkXmHTML is the prime other example. GnomeIconList has recently
been rewritten in terms of GnomeCanvas.
 
> further, a GtkViewport implements a scrollable area and is not of actuall use
> seperatedly from a GtkScrolledWindow, it's code should better be moved
> into the gtkscrolledwindow.c. since a scrolled window automatically always
> includes a GtkViewport, but tries to hide that from API, it does some nasty
> hacks widget tree wise, like forwarding the GtkContainer::add and
> GtkContainer::remove signals to the viewport. this occasionally leads to
> problems, e.g. one would expect that the following code portion would work:

Hmm, I guess what you are saying is that the ScrolledWindow should
check to see if its child implements the "set_adjustments" 
interface, and if it doesn't, directly, itself, scroll it's
child by putting it in a big GdkWindow. (Which is the form
of scrolling a GtkViewport does)

While this is sort of a convenient API for applications, it is one
that is rather conceptually messy, would put a lot of special-casing
into the GtkScrolledWindow code, and (in some obscure, but
significant ways related to the hopefully "transparent" square in
the lower left of a CList) makes things difficult for themes.

I'd rather leave it closer to the way it is now:

 - New code would be encouraged to create the Viewport explicitely
   and add it to the scrolled window.

 - Adding a a non-scrollable widget to a ScrolledWindow would
   create a Viewport implicitly and trigger the current
   forwarding hack.

[...]

> what's involved to solve these problems?

The biggest problem is figuring out how to efficiently and
accurately decide when the subwidget needs scrollbars or
not. This is simple for things like the CList and Viewport,
but not at all simple for, say a page of HTML, which combines
word wrapping (so vertical and horizontal sizes are related),
with fixed size objects (so there is a minimal width and
horizontal scrollbars are needed.)

A short uncompleteed description of some of the ideas I've had in this
regard can be found at:
 
 http://www.gtk.org/~otaylor/whitepapers/scrolling.txt

the main different idea is the idea of "hints" - the child
of the scrolled window, can, for instance indicate that some
dimension is fixed in size. 

> as owen said, scrollable widgets would implement an extra signal,
> which is not mandatory for all widgets, similar to the "activate"
> signal implementation of widgets, which always has the same
> semantics if implemented, but can be named differently, depending on
> the implementation inheritance branch (e.g. a GtkButton implements
> this signal as "clicked").  also, the scrollbar specific code of
> these scrollable widgets would get removed from the actuall
> implementation, and they need to be put into a scrolled window if
> one would want them to be scrollable.  this alltogether would impose
> some source incompatibilities, which is virtually the only thing
> that could prevent us from actually cleaning up the scrolling
> mess. i'll try to assemble these incompatibilities:
 
> functions that would become deprecated:
> ---------------------------------------
> (but could be compatibility-maintained to some extend (i.e. set/get of
> adjustments will only work if the widget already got added to a parent)

I don't see why that restriction is necessary is necessary -
it should be possible to use a Text widget as it is currently,
though one is better off with a ScrolledWindow outside.)

[ Text widgets don't implement scrollbars, typically one makes
  table with scrollbars and connects them together manually ]
 
Regards,
                                        Owen