Hi,
the most grave issues in the Gdk/Gtk port are resolved and I would
like to implement FrameLoaderClientGdk::createFrame and have a couple
of questions.
To get the cardinalities right could you confirm that:
-Each Page has one main Frame?
-Each Frame has a FrameView? Is that mandantory or should the
FrameView only be created when FrameLoaderClient::makeDocumentView is
getting called?
-Each Frame has a FrameTree containing child frames?
-Frames not in a (grand)parent-child relationship don't overlap?
-The RenderTree defines the z-order of the RenderWidget in a
RenderFrame?
-The widget of a RenderFrame is a FrameView?
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.
kind regards
z.
PS: Yes, we should get DumpRenderTree working for Gtk+ and should
look into validating test results...
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
