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:
1) nsPrintEngine (just wants to call GPFF; could be calling it off
nsIPresShell today).
2) XBL (needs access to the undisplayed content map, or thinks it
does).Frames do need access to the frame manager, however, for all sorts of stuff. So perhaps we should keep the frame manager and the prescontext separate classes just to keep a logical separation between "layout stuff that can be useful to someone outside layout" and "layout stuff no one outside layout will ever care about". nsFrameManager really is all about managing frames and storing all sorts of out-of-band state for frames (ReResolveStyleContext being a notable exception to the above).
I think we could certainly make nsFrameManager a plain non-XPCOM class, though, and just have the prescontext own it...
My thoughts, -Boris _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
