Re: RFC: scrolling

[Benjamin Otte <otte gnome org>]

On Fri, Dec 9, 2011 at 3:48 AM, Matthias Clasen
<matthias clasen gmail com> wrote:
> 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.
>
Not really. There are a bunch of things that we don't do very well if
you use current GTK with a GtkViewport:
- the height-for-width situation (and generally performance; points
13, 14, 15 of my mail)
- the ability to cause a scroll to a certain position (Kris' mail)
- reacting to changes in the visible area (points 1, 2)
- you still have GtkAdjustment shenanigans
I think what would be important if we wanted to make GtkViewport more
prominent would be the ability for scrollables to achieve the
functionality they have today without the need to be a direct child of
the scrolled window. So it'd be roughly equal to being able to getting
rid of the GtkScrollable interface and having common functionality
instead that did the same thing.

> 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.
>
There's a bunch of interesting things about that. First of all, we get
complianace with CSS' overflow mechanism. While this may not sound too
interesting at first, if you combine it with transitions and
animations, you might be able to achieve quite a few interesting
effects (like being able to scroll in views that aren't fully expanded
yet).
I agree though that this sounds very unnatural for the way GTK works.

>> - 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.
>
I'm not sure this is really much of a question, it's just a case of
doing it. And possibly doing it in a backwards-compatible way. We
expose a bunch of functions (like gtk_tree_view_get_bin_window()) that
expose this detail. I think the scrollables themselves - at least the
ones inside GTK - don't need a lot of code to work without a "bin
window" as we tend to call it.
But that is just my very unscientific look at the code, not something I tried.

Benjamin