On Jul 16, 2007, at 1:59 AM, Holger Freyther wrote:
-Each Page has one main Frame?
Yes.
-Each Frame has a FrameView? Is that mandantory or should the
FrameView only be created when FrameLoaderClient::makeDocumentView
is getting called?
Yes. In the Windows implementation, a FrameView is created
immediately after Frame construction (see
WebFrame::initWithWebFrameView in WebKit/win/WebFrame.cpp).
-Each Frame has a FrameTree containing child frames?
The FrameTree object is essentially a sub-object of Frame that
contains all the methods for accessing the tree structure of the Frame.
-Frames not in a (grand)parent-child relationship don't overlap?
I would imagine that you could have two overlapping sibling
iframes, but perhaps you're only speaking of HTMLFrameElements.
-The RenderTree defines the z-order of the RenderWidget in a
RenderFrame?
The (Render)Layer tree maintains z-order information for all
RenderObjects.
-The widget of a RenderFrame is a FrameView?
Yes.
I think there are probably two approaches to implement it:
1.) Have one GdkWindow for the main Frame of the Page
+ Resource friendly
+ z-order would always be right
- Scrolling would need to be manually handled by ScrollView (e.g.
similiar to the Qt port)
- Complex handling of coordinates
- Complex to get right at the beginning (clipping, translation of
the GraphicsContext)
- Embedding real Platform::Widget will be more tough.
2.) Have one GdkWindow for each FrameView
+ Easy and understandable
- Need to get passing expose events to children right to have the z-
Order.
- Need to make ScrollView::update update the right (outermost) region
- Would only work when we have non-transparent overlapping Frame's
(does this apply?)
3.) What did I miss?
Answers and pointers to manual Frame tests would be appreciated. I'm
tempted to go with the 2nd option.
I think you'll have a much easier time getting things right in the
end if you go with the first option (one native widget (GdkWindow) per
Page, not per Frame). Otherwise you'll have lots of trouble getting
painting to happen in the correct order (imagine an absolutely
positioned div in the main frame that overlaps a subframe -- the
subframe needs to paint after everything in the main frame *except*
for the div).
PS: Yes, we should get DumpRenderTree working for Gtk+ and should
look into validating test results...
Yes, that would be good :-)
-Adam
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
