[gtk-list] Re: Scrollable Widgets (Re: GtkText & scrollbars)

[Lokh <Patrice Fortier aquarel fr>]

Owen Taylor wrote:
> Tim Janik <timj@gtk.org> writes:
> > 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.

[...]

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

This would be definitly a good thing(tm).

IMHO this should even have been done before 1.0, but the gimp was the
priority...

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

Last year (just before 1.0) I recoded GtkClist so it could be included
in a GtkScrolledWindow, and I was amazed by the amount of code (and thus
complexity) I threw out.
I was stopped by the 32k+ window limitation though. I don't know if it's
still there in 1.1.2.
The Clist hack to avoid this problem is just a hack, but a very efficient
one:).

[...]

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

[...]

IMHO you should implement what's described upper on this news before doing
this. It will damatically change the architecture of some of your widgets
(like clist).
I made the changed you described last year and I ran into the problem
Owen described (and that I deleted by mistake :)).

I recoded GtkScrolledWindow as a GtkViewport subclass but I don't remember
if it solved this problem (or create other ones)....

[...]

> 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
> 
I (unfortunatly) don't have enough time to get back into this, I just
want to remind you: Dont forget the 32K pixel windows :)


Don't hesitate!
Make the changes.


Regards,
Lokh.