Re: Scrollable Widgets (Re: GtkText & scrollbars)

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> On 14 Oct 1998, Owen Taylor wrote:
> 
> > 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.

At that point, it almost becomes simpler to just create
the "set_[scroll_]adjustments" signal in GtkWidget (same
use of space, avoids having to create it in each descendant
class that needs it). Hmmm....

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

There would also be special casing in the size allocation code, in the
code for determining whether scrollbars are needed or not, more
special casing if you don't want to create lots of excess GdkWindows
when you don't need them.

There are a few sophistications to be added to the ScrolledWindow -
and it would be much nicer to have the Viewport be just a discrete
chunk of simple code.
 
> > 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)

You're missing a lot of the code - 80 lines in realize() plus quite a
bit more scattered about.

But more  important is the decreased functionality  (see John Gibson's
example), and the substantial amount of extra computation necessary in
themes to have a ScrolledWindow  widget be !NO_WINDOW but look like it
is NO_WINDOW.

Note also, that scrolling a CList or CTree, or spreadsheet widget
doesn't even look like it is in a Viewport, because of column
labels. I think pretending that goes on is a bit too much automagic.

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

Putting a CList, CTree, Text, XmHTML, GtkLayout, GnomeCanvas....
in it? right?  ;-)

Maybe you meant the other way around, but there are examples
there too - the ScrolledWindow is a very common form of UI
layout for scrolling a child, but it is by far not the only
conceivable way. (I don't believe ggv uses a Viewport for
it's GUI - which looks like gv's, but it could easily do so.)
 
> >  - 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.

[...]

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

What I was saying above is that there is no reason why people
can't continue using Text widgets the old way, because they
currently don't have internal scrollbars. 

The situation is different for CList; there we'll need to make
people add new scrollbars.

Regards,
                                        Owen