[webkit-dev] Page, Frame, FrameView and FrameTree clarification needed

[Holger Freyther]

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...