reorganizing files in layout, take 3
L. David Baron
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
--
L. David Baron <URL: http://dbaron.org/ >
Jonas Sicking
upon not covered here are the various .gif files that live in /src
directories. It might be nice with a mozilla/layout/resources directory
for those.
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
Robert O'Callahan
> I'm also wondering whether nsHTMLReflowState, nsHTMLReflowMetrics, and
> nsReflowPath should be in base or generic (for now they're in generic).
I don't really grok the distinction between base and generic. For
example, why is nsIFrame in generic and not base? If it was up to me I
might make base include everything that you absolutely must use to have
a working presentation, and generic include the rest. So generic could
include block-and-line, pagination, text, etc, but not nsIFrame and
nsFrame themselves.
Overall I think it's a great improvement on what we have and I don't
think quibbling about a few details is that important.
Rob
L. David Baron
> L. David Baron wrote:
> >I'm also wondering whether nsHTMLReflowState, nsHTMLReflowMetrics, and
> >nsReflowPath should be in base or generic (for now they're in generic).
>
> I don't really grok the distinction between base and generic. For
> example, why is nsIFrame in generic and not base? If it was up to me I
> might make base include everything that you absolutely must use to have
> a working presentation, and generic include the rest. So generic could
> include block-and-line, pagination, text, etc, but not nsIFrame and
> nsFrame themselves.
The idea was that generic contain the basic frame classes and supporting
code, while base contain other core things (pres shell, etc.). Now that
you mention it, it wouldn't make sense to move the reflow stuff to base
without moving nsIFrame as well. Perhaps they should all be thrown
together, though, although there are a lot of frame classes and they'd
tend to hide the other things.
Robert O'Callahan
> On Saturday 2004-03-27 01:02 -0500, Robert O'Callahan wrote:
>
>>L. David Baron wrote:
>>
>>>I'm also wondering whether nsHTMLReflowState, nsHTMLReflowMetrics, and
>>>nsReflowPath should be in base or generic (for now they're in generic).
>>
>>I don't really grok the distinction between base and generic. For
>>example, why is nsIFrame in generic and not base? If it was up to me I
>>might make base include everything that you absolutely must use to have
>>a working presentation, and generic include the rest. So generic could
>>include block-and-line, pagination, text, etc, but not nsIFrame and
>>nsFrame themselves.
>
>
> The idea was that generic contain the basic frame classes and supporting
> code, while base contain other core things (pres shell, etc.).
Okay, that sounds very reasonable, except that it's hard to have good
names for that. Maybe we should just bite the bullet, call "generic"
"frames", and do what we can to redirect people looking for the
implementation of <FRAME>. They'll need to wise up to our use of 'frame'
quickly anyway... With this approach I would put in 'base' probably
nsIFrame.h, nsFrame.*, nsSplittableFrame.*, nsContainerFrame.*, and
nsHTMLContainerFrame.* (nsHTMLContainerFrame should be merged into
nsContainerFrame anyway, IMHO).
Rob
Boris Zbarsky
> To continue the discussion I started in
> http://groups.google.com/groups?selm=20030920053236.GA6632%40darby.dbaron.org
> here's a revised proposal.
This looks excellent to me. Minor comments below.
> I'm also wondering whether nsHTMLReflowState, nsHTMLReflowMetrics, and
> nsReflowPath should be in base or generic (for now they're in generic).
Generic seems reasonable here (with nsIFrame, nsFrameList, etc).
> layout/html/style/src/nsIHTMLStyleSheet.h -> layout/style/
Not an issue.
> layout/base/nsLayoutAtoms.h
For this and similar, I assume we'll just use ../../whatever includes in
makefiles as needed?
It'd be nice to come to agreement on the remaining base/generic/frames
issues (re roc's reply to the original post), and get this happening...
-Boris