[Webkit-unassigned] [Bug 14729] [gtk] Implement FrameLoaderClientGdk::createFrame

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Jul 29 16:08:22 PDT 2007


http://bugs.webkit.org/show_bug.cgi?id=14729


freyther at handhelds.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #15731|                            |review?
               Flag|                            |




------- Comment #2 from freyther at handhelds.org  2007-07-29 16:08 PDT -------
Created an attachment (id=15731)
 --> (http://bugs.webkit.org/attachment.cgi?id=15731&action=view)
Implement ScrollView similiar to win/qt

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.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list