Same goes partially for .css files like html.css. Though these are more tightly coupled with the source and implementation of various things sometimes moves between html.css and various .cpp files which makes me think that they could live in 'source directores'.
/ Jonas
L. David Baron wrote:
To continue the discussion I started in http://groups.google.com/groups?selm=20030920053236.GA6632%40darby.dbaron.org
here's a revised proposal.
Beyond the changes in http://groups.google.com/groups?selm=mailman.1080267540.11846.mozilla-layout%40mozilla.org
this incorporates responses to that, adds nsLayoutStylesheetCache and
nsIStyleRuleSupplier.h to the proposal, moves nsStyleSet to layout/style/
rather than layout/base/, notes that nsCSSFrameConstructor should be
renamed to nsFrameConstructor, moves nsFrameList, ns{I,}FrameUtil and
nsIFrameDebug to generic rather than base, and puts the new nsFrameManager
headers with the cpp file.
I'm also wondering whether nsHTMLReflowState, nsHTMLReflowMetrics, and nsReflowPath should be in base or generic (for now they're in generic).
I propose to reorganize all of the files in the following directories: content/html/style/ content/shared/ layout/base/ layout/html/ (except layout/html/tests/, to save CVS) plus the following files within content/base/: content/base/public/nsIStyleRule.h content/base/public/nsIStyleSheet.h content/base/public/nsIStyleRuleProcessor.h content/base/public/nsIStyleRuleSupplier.h content/base/public/nsIPrintProgress.idl content/base/public/nsIPrintProgressParams.idl content/base/public/nsIPrintStatusFeedback.idl content/base/public/nsLayoutStylesheetCache.cpp content/base/src/nsDocumentViewer.cpp content/base/src/nsPrintData.cpp content/base/src/nsPrintData.h content/base/src/nsPrintEngine.cpp content/base/src/nsPrintEngine.h content/base/src/nsPrintObject.cpp content/base/src/nsPrintObject.h content/base/src/nsPrintPreviewListener.cpp content/base/src/nsPrintPreviewListener.h content/base/src/nsSelection.cpp content/base/src/nsPagePrintTimer.cpp content/base/src/nsPagePrintTimer.h content/base/src/nsStyleSet.cpp content/base/src/nsStyleSet.h content/base/src/nsRuleNode.cpp content/base/src/nsStyleContext.cpp content/base/src/nsLayoutStylesheetCache.cpp
I propose that we eliminate the "public" and "src" distinction. It's been inconsistently used: we sometimes put all EXPORTS in public, sometimes only those that are intended to be used by other modules, and sometimes even put exports for other modules in src directories. I think we should use EXPORTS to indicate what should be used outside of layout, and use include paths in makefiles for within-layout inclusion.
The overall structure would yield the following subdirectories of layout (in addition to the ones excluded above):
layout/base/ [ Central objects and things that don't go anywhere else. ] layout/style/ [ Style sheets and style data computation ] layout/generic/ [ What's now in layout/html/base/src/ , roughly ] layout/forms/ layout/tables/ layout/printing/
Here's how I would move files around to get to the structure above (ignoring jar.mn, Makefile.in, and .cvsignore files):
I propose the following mass-moves: layout/html/forms/{public,src}/ -> layout/forms/ layout/html/table/{public,src}/ -> layout/tables/ layout/html/document/src/*.cpp -> layout/generic/ layout/html/document/src/<everything else> -> layout/style/ (after removing platform directories using preprocessor)
Furthermore, of the enumerated files within content/base/ above: the ones containing "Print" in the filename -> layout/printing/ all containing "Style" in the name, plus nsRuleNode.cpp -> layout/style/ nsDocumentViewer.cpp, nsSelection.cpp -> layout/base/
Further, I propose the following mass-moves (roughly): layout/html/style/src/ -> layout/base/ layout/base/{public,src}/ -> layout/base/ layout/html/base/src/ -> layout/generic/ with the following exceptions: layout/base/public/nsHTML* -> layout/generic/ layout/base/public/ns*Frame.h -> layout/generic/ layout/base/public/nsIFrameDebug.h -> layout/generic/ layout/base/public/nsFrameList.h -> layout/generic/ layout/base/public/nsIFrameUtil.h -> layout/generic/ layout/base/src/nsIntervalSet* -> layout/generic/ layout/base/src/nsSpaceManager* -> layout/generic/ layout/base/src/nsFrameList.cpp -> layout/generic/ layout/base/src/nsFrameUtil.cpp -> layout/generic/ layout/html/base/src/nsFrameManager.cpp -> layout/base/ layout/html/base/src/nsPresShell.cpp -> layout/base/ layout/html/style/src/nsIHTMLStyleSheet.h -> layout/style/ layout/html/base/src/printing.properties -> layout/printing/ and renaming nsCSSFrameConstructor.{h,cpp} to nsFrameConstructor while I'm there.
That leaves the files in the following directories to be handled individually: content/html/style/ content/shared/ I propose they all end up in layout/style except for:
content/base/src/nsHTMLValue.cpp content/base/src/nsHTMLValue.h layout/base/nsBidiUtils.cpp layout/base/nsBidiUtils.h layout/base/nsChangeHint.h content/html/content/src/nsImageMapUtils.cpp content/html/content/src/nsImageMapUtils.h content/base/src/nsTextFragment.cpp content/base/public/nsTextFragment.h content/base/src/nsAtomListUtils.cpp content/base/src/nsAtomListUtils.h content/html/content/src/nsHTMLAtomList.h content/html/content/src/nsHTMLAtoms.cpp content/html/content/src/nsHTMLAtoms.h layout/base/nsLayoutAtomList.h layout/base/nsLayoutAtoms.cpp layout/base/nsLayoutAtoms.h layout/base/nsFrameManager.h layout/base/nsFrameManagerBase.h content/svg/content/src/nsSVGAtomList.h content/svg/content/src/nsSVGAtoms.cpp content/svg/content/src/nsSVGAtoms.h content/xbl/src/nsXBLAtomList.h content/xbl/src/nsXBLAtoms.cpp content/xbl/src/nsXBLAtoms.h content/xul/content/src/nsXULAtomList.h content/xul/content/src/nsXULAtoms.cpp content/xul/content/src/nsXULAtoms.h
(Some of the atoms in nsLayoutAtomList are used by content, but many are really layout-specific. We can fix that later, if needed.)
Thoughts?
-David
_______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
