Robert O'Callahan wrote:
I believe we have the long-term goal of merging nsPresShell into nsPresContext, so during deCOMtamination I'm trying to move functions from nsPresShell into nsPresContext. What about nsFrameManager? Is there any reason why we shouldn't merge it into nsPresContext too?
Other than fear of ending up with a _very_ baroque interface? Or creating a 13000-line monster like nsCSSFrameConstructor? ;)
It seems to me that a nsIPresContext is the interface a page layout presents to the world. Most of the stuff on nsIFrameManager is of sublime indifference to anyone that's not in /layout. For example, all the uses outside /layout are:
I think you're right, but why then do we pass around the prescontext everywhere in layout, instead of the frame manager?
The other thing is that we really should be making all the nsIPresContext methods called within layout non-virtual.
It sucks that C++ doesn't let you make a virtual method in a superclass non-virtual in a subclass.
How about we make nsIPresContext be the got-it-all interface that frames pass around. Pour nsIFrameManager into it. Create nsIPresentation or something like that to contain just the "interface to the outside world" methods, make only the methods actually called from outside gklayout virtual, and have nsIPresContext extend it. Promote the implementations of all the methods to nsIPresContext, getting rid of nsPresContext itself. We can split the nsIPresContext implementation across several files.
Rob
_______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
