Hey, A few hours ago I was telling Martin what kinds of problems I've had with the scrolling code, and the requirements that were initially set for it. Essentially, the idea is that WebKitWebView be a normal GTK+ widget that can be added to any scrolling controller widget, such as GtkScrolledWindow, or MokoFingerScroll, and work.
The problem we have is that having it this way, there are a whole lot of complexities we have to deal with, one of the more annoying ones being that since the main frame scrollbars are part of the parent widget, when they appear the WebView changes size, which fires a "resize" DOM event, which some pages use to (doh) reload the page, so we get into a reload infinite loop. We discussed a few possibilities, including dropping the idea of being a "normal" scrollable, and inheriting directly from GtkScrolledWindow, thus fixing the problem from the inside. Something just came to my mind just a few minutes ago, that I'd like to explore, though: what if we create a WebKitScrolledWindow, derived from GtkScrolledWindow that does not draw scrollbars, thus never stealing space from the WebView, and is handled specially by the WebKitWebView? When that widget is the parent, the WebView would then behave more "normally". This would be the recommended parent widget for normal browsers, and tools such as devhelp, but we would retain the ability of using other widgets whenever web compatibility is not a problem, or can be worked around in other ways (for MokoFingerScroll there should be no problem as it doesn't draw scrollbars AFAIk). This new widget would be part of WebKit. Another option is to try to propose a patch to GtkScrolledWindow to give it a mode that makes it avoid drawing the scrollbars itself in a way that the child could set/detect the mode. What do you think? Cheers, -- Gustavo Noronha Silva <[email protected]> GNOME Project _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
