Re: Scrollable Widgets (Re: GtkText & scrollbars)

[Tim Janik <timj gtk org>]

On 14 Oct 1998, Owen Taylor wrote:

> > On 12 Oct 1998, Owen Taylor wrote:

> > > 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.

[...]

> > 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)

i'd rather name that "set_scroll_adjusments" which maps better onto the
actuall purpose.
checking if a signal to set these adjustments is implemented is imho
the best way, this can easily be done by adding an extra field
guint set_scroll_adjustments_signal; to GtkWidgetClass, similar to
the existing activate_signal member.
the scrolled window would actually always provide a parent_window
for its child, and if the child doesn't provide own scrolling capabilities,
the scrolled window could automatically reparent this window into a 
viewport window (which doesn't need to be always present).

> 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.

there'd not be much special casing code in scrolled window, the signal
handlers for the scrollbar adjustments would either move the child's
parent_window inside the viewport, or just do nothing.

> 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.

that's exactly what i wanted to avoid. why make things more complicated
than neccessary? the actuall scrolling code in gtkviewport.c boils down
to a little more than 100 lines (in gtk_viewport_size_allocate() actually)
the rest is about parent-child relationship, object arguments and type
system stuff. there's no reason for this to not be provided by the
scrolled window itself, and also there's no reason for the application
writers to deal with a vieport widget (what's a scrolled window without
a viewport usefull for anyways?).

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

they way you suggest also implies that a toolkit user needs to know
whether a widget can provide scrolling itself, i.e. a clist wouldn't
need an intermediate viewport whereas a table would. it's pretty
obvious that this burden is unneccessary.

> > 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 ]

i think we need to draw a line here. either you want scrolling abilities, in
which case you'll always add to a scrolled window, or you don't get scrolling
abilities because you left the scrolled window out, and thus a clist, text or
whatever scrollable widget is just left with gtk's normal request/allocation
mechanism. this will make things easier and more consistent for both, the
toolkit and the application side. the downside of this approach is of course
that we'll have to add a few scroled windows into existing applications, but
that usually boils down to 3 lines of new code, which are pretty easy to cover.

>  
> Regards,
>                                         Owen
> 

---
ciaoTJ