reorganizing files in layout, take 2
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.
This considers the comments in that thread and also eliminates the
subdirectories within layout/style/ (which don't have a clear
distinction) and distributes the atom lists files to various places.
I've also removed xul from the plan for now -- the changes to xul don't
have that great a benefit, and don't mix with any of the other changes.
I still want to go through all the files one by one to check that this
still makes sense. When I do this, I may be able to make a list of
files that could go in layout/public/ rather than layout/base/, although
I'm not sure I actually want to do such a thing.
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/nsIPrintProgress.idl
content/base/public/nsIPrintProgressParams.idl
content/base/public/nsIPrintStatusFeedback.idl
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/nsRuleNode.cpp
content/base/src/nsStyleContext.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/generic/ [ What's now in layout/html/base/src/ , roughly ]
layout/forms/
layout/printing/
layout/style/ [ Style sheets and style data computation ]
layout/tables/
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 by using preprocessor)
Furthermore, of the enumerated files within content/base/ above:
the ones containing "Print" in the filename -> layout/printing/
nsIStyle*, nsRuleNode.cpp and nsStyleContext.cpp -> layout/style/
nsDocumentViewer.cpp, nsSelection.cpp, and nsStyleSet.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/src/nsIntervalSet* -> layout/generic/
layout/base/src/nsSpaceManager* -> 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/
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/html/content/public/nsHTMLValue.cpp (or content/base/public/ ?)
content/html/content/src/nsHTMLValue.h (or content/base/src/ ?)
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/svg/base/src/nsSVGAtomList.h
layout/svg/base/src/nsSVGAtoms.cpp
layout/svg/base/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
Thoughts?
-David
--
L. David Baron <URL: http://dbaron.org/ >
Jonas Sicking
> This considers the comments in that thread and also eliminates the
> subdirectories within layout/style/ (which don't have a clear
> distinction) and distributes the atom lists files to various places.
Moving the atom-lists to their siblingclasses (i.e. xul-atoms should go
to the xul code, svg atoms to svg code) sounds like a very good idea. I
would prefer if the atomlists lived in
mozilla/content/{xul|html|svg}/content, rather then in layout. I tend to
think of layout as being built on top of content and that stuff that are
used by both of them should live in layout. Of course, this is likly
because i mostly work in content :)
> content/html/content/public/nsHTMLValue.cpp (or content/base/public/ ?)
> content/html/content/src/nsHTMLValue.h (or content/base/src/ ?)
Please move both these to content/html/content/src. This class is being
replaced by nsAttrValue which lives there. And neither nsHTMLValue or
nsAttrValue is used (or usable) outside of content so no need to put the
.h file in public.
> Thoughts?
To minimize the pain for developers it might be good to land this
sometime in the middle of the alpha cycle. That way people with patches
get a chance to land after the tree-freeze, and lets people modify
patches before the craze right before the 1.8a freeze.
/ Jonas
Johnny Stenback
Jonas Sicking wrote:
--
jst
Jonas Sicking
> Moving the atom-lists to their siblingclasses (i.e. xul-atoms should go
> to the xul code, svg atoms to svg code) sounds like a very good idea. I
> would prefer if the atomlists lived in
> mozilla/content/{xul|html|svg}/content, rather then in layout. I tend to
> think of layout as being built on top of content and that stuff that are
> used by both of them should live in layout. Of course, this is likly
> because i mostly work in content :)
Err.. this should of course say "stuff that are used by both of them
should live in *layout*"
>> content/html/content/public/nsHTMLValue.cpp (or
>> content/base/public/ ?)
>> content/html/content/src/nsHTMLValue.h (or content/base/src/ ?)
>
> Please move both these to content/html/content/src. This class is being
> replaced by nsAttrValue which lives there. And neither nsHTMLValue or
> nsAttrValue is used (or usable) outside of content so no need to put the
> .h file in public.
And this should say "outside of gklayout.so" :)
It's friday, time to go home...
/ Jonas
Jonas Sicking
> Jonas Sicking wrote:
>>> content/html/content/public/nsHTMLValue.cpp (or
>>> content/base/public/ ?)
>>> content/html/content/src/nsHTMLValue.h (or content/base/src/ ?)
>>
>>
>> Please move both these to content/html/content/src. This class is
>> being replaced by nsAttrValue which lives there.
Ack! Today isn't my day. I ment content/base/src, nothing else.
/ Jonas