[webkit-reviews] review requested: [Bug 14729] [gtk] Implement FrameLoaderClientGdk::createFrame : [Attachment 15731] Implement ScrollView similiar to win/qt

[bugzilla-daemon at webkit.org]

Holger Freyther <freyther at handhelds.org> has asked  for review:
Bug 14729: [gtk] Implement FrameLoaderClientGdk::createFrame
http://bugs.webkit.org/show_bug.cgi?id=14729

Attachment 15731: Implement ScrollView similiar to win/qt
http://bugs.webkit.org/attachment.cgi?id=15731&action=edit

------- Additional Comments from Holger Freyther <freyther at handhelds.org>
Mostly follow the Windows design (which works great):
The most controversal change is with Widget::setScrollViewControl.
PlatformScrollbar uses a GtkWidget. In order to draw it correctly we need to
have a proper GtkAllocation set on the widget. We set one when
PlatformScrollbar::setRect gets called.

Now PlatformScrollbar is used by RenderFrame and ScrollView. In the case of
ScrollView scrolling should not change the position of the ScrollBar. In Win/Qt
this is achieved by translating the context before painting. As the
PlatformScrollbar in Gtk+ is a GtkWidget I would like to avoid changing the
GtkAllocation on every paint and treat it more like WebCore/plugins/win and
handle it like/similiar geometryChanged to position it.
This leads to the controversial change in Widget to select which coordinate
translation to use. Other solutions considered where to subclass
PlatformScrollbar for ScrollView to change the placing behaviour.

This is just a current diff of the work in progress implementation and comments
would be appreciated.