[webkit-gtk] WK2: WebKitWebViel scrolling

[Martin Robinson]

On Mon, Jul 30, 2012 at 9:23 AM, Julian Scheel <julian at jusst.de> wrote:

>> Consider that if we implement this behavior in WebKit, we can ensure
>> that it applies equally well and consistently to interior frames. An
>> external, GTK-based implementation does not provide that.

> As I am not into the internal widget structure of WebKitGTK it might be
> completely out of scope, but what prevents us from using
> GtkScrolledWindow (or a derived class if more features are required) for
> inner frames?
> Which class should actually implement the scrolling? I assume inner
> Frames are not WebKitWebViews but some internal class?

The implementation of a frame is deeply intertwined into WebCore and
trying to bolt a GtkScrolledWindow on top would certainly be harder
than implementing kinetic and touch scrolling in WebKit. In WebKit1,
we have a lot problems interacting with GTK+ for scrolling already.
Just a quick sample of some of the problems:

GTK+ scrolling works asynchronously, yet WebCore expects it to happen
synchronously. Thus the scrollable area can be out of sync with the
page.

GtkScrolledWindow is responsible for drawing the scrollbars, yet some
frames have custom scrollbars. This leads to double scrollbars on some
pages.

The way we interact with GtkScrolledWindow (modifying the adjustments
directly), means that other widgets cannot be easily packed into the
GtkScrolledWindow, leading to more than one frustrated developer, I'm
sure.

I believe, these things just result in a situation which is "a bridge
too far" in terms of making a polished GTK+ widget. We could probably
solve all of these problems by piling even more hacks, but we'd also
end up with something that would break all the time and consume a lot
of maintenance hours.

--Martin