On Mon, Jul 30, 2012 at 9:23 AM, Julian Scheel <[email protected]> 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 _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-gtk
