[webkit-gtk] WK2: WebKitWebViel scrolling

Julian Scheel julian at jusst.de
Mon Jul 30 01:08:28 PDT 2012


Am Montag, den 30.07.2012, 09:48 +0200 schrieb 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.

Ok, thanks for the details. I agree with you that it probably would the
bigger hassle to deal with the gtk issues than having an own kinetic
scrolling implementation.
So is anyone already working on this? Otherwise I might take a look at
it. Although it will probably take some time before I am enough into the
WebKitGTK structure to really do it.
Any hints on existing code I could orientate at are welcome (c:

-Julian



More information about the webkit-gtk mailing list