Re: RFC: scrolling

[Matthias Clasen <matthias clasen gmail com>]

Hey Benjamin,

what a long, detailed mail.
You managed to break the kill-the-discussion threshold, I fear...
I'll try to comment on a few points below.


> I can come up with a few methods to implement this split:
>
> A) Don't implement it
> Instead, just rely on scrollables to do the scrolling themselves. The
> toolkit could provide some helper functionality, but if a widget
> wanted to scroll, it would do it itself. An example of this behavior
> is the map on http://maps.google.com
> B) Let the scrollable do the scrolling
> The viewport manages scrollbars and whenever it is smaller than the
> scrollable, it communicates the sizes and the current position to the
> scrollable. It is then the scrollable's job to render itself in a
> suitable way. This is the current approach of GTK with
> GtkScrolledWindow and GtkScrollable.
> C) Let the viewport do the scrolling
> In this approach, one treats the scrollable as just a large canvas and
> the viewport provides a view onto an area of the scrollable. Scrolling
> is managed completely by the viewport.
> D) Implement scrolling automatically
> Whenever a widget needs more space than is available, just
> automatically add scrollbars. This is what the overflow property of
> HTML does.

gtk_scrolled_window_add_with_viewport lets you largely get away with
pretending you are in case C), right ?
It just automatically inserts a GtkViewport between the
GtkScrolledWindow and your 'large canvas' widget. Taken together
GtkScrolledWindow and GtkViewport manage scrolling completely.

D) does not really seem a full alternative to me. It basically just
saying: when there's not enough room, automatically insert a viewport.
You then still have to answer the question of how the scrolling is
organized between the automatically inserted viewport and the
scrollable, by one of the other other answers. Since this should work
transparently for any widget seems to point to C) then.

> And then the question becomes: If we redo scrolling, which of these
> solutions should we pick? And should we only pick one? Or should we do
> it completely different?
> Or should we just keep it? I can come up with a bunch of reasons why
> we should not just keep it, that are specific to the current design:
> - the GtkAdjustments are underspecified
> Who sets what values on the adjustments? Who provides the adjustment?
> What do the values on the adjustment even mean? 5 years ago having a
> "page size" and a "step size" probably made sense, but today we have
> smooth scrolling...

Page size and step size still make sense for some uses of adjustments
today, as long as you have arrow up/down and page up/down keys on your
keyboard... they are just not very relevant for scrolling.

> - the size request mechanism is unspecified
> This was a huge oversight in the height-for-width code review. Nowhere
> is it specified what the requested sizes mean, how they should be
> interpreted and in what way scrolled windows should do layout of their
> children. Also, up to today, nobody has even bothered porting any of
> the existing scrollables to the layouting mechanism. I know of a few
> cases in GTK code where the sizing code already special-cases
> scrollables or viewports, and I do expect this to become more. It also
> means that it is practically impossible to use scrollables without
> putting them in a viewport, because their sizes will be completely
> screwed up.

I agree that we haven't succeeded in integrating scrolling into
height-for-width in a meaningful way.

> - the scrollables rely on GdkWindows
> Scrolling is today exclusively implemented using GdkWindow. And we are
> trying very hard to get rid of them. So we will need to touch all the
> code anyway.

This still seems to be the biggest question.