Re: Scrollable Widgets (Re: GtkText & scrollbars)

[Tim Janik <timj gtk org>]

On 18 Oct 1998, Owen Taylor wrote:

> 
> Tim Janik <timj@gtk.org> writes:
> 
> > On 14 Oct 1998, Owen Taylor wrote:
> > 

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

why? the scrolling code is not that complicated actually and putting all of it
into gtkscrolledwindow.c moves the code into the place where it is required and
cleans up with the widget tree mess that a scrolled window with an automagic
viewport creates. this is one of the major points in my suggestion, since
currently the scrolled window container_add/container_remove behaviour is
screwed and the scrolled window itself is a horror to use for interface
builders. if you have strong feelings about keeping a GtkViewport existant,
we can certainly do that, but there is no aparent reason to not fully integrate
all required scrolling abilities into a GtkScrolledWindow.

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

what is that "John Gibson's example" you are referring to?

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

nope, CList or CTree wouldn't go into a viewport-like window since they
provide scrolling abilities themselfes, therefore they also draw their
frames themselves and there's actually nothing the scrolled window would
have to worry about.

> > 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?).
              ^
          "currently"!

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


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

a clist wihtout scrollbars could just be used like a current text widget
without scrollbars. the actuall problem is just the involved source
incompatibility i explained earlier.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ