reorganizing files in layout/
L. David Baron
I think it's high time we reorganized files within layout. I think the
current directory structure is so convoluted that it may well scare off
contributors -- people who are interested in fixing one thing, and may
later come back to help more -- because they can't find what they want.
I think the most important goals of the new directory structure are:
* related files should be nearby, for easy editing
* it should be relatively easy for somebody new, who wants to know how
we do X, to find the code that does X.
I think both of these point toward a shallower tree structure than the
one we currently have.
What follows is a proposal that I just wrote, without looking at (or
even finding, but it's in a bug somewhere) a proposal that I wrote a
year or so ago.
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)
layout/xul/
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. It
also tends to make things more difficult to read and edit.
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/sheets/ [ Style sheet objects and supporting code ]
layout/style/data/ [ Style data computation ]
layout/corenodes/ [ roughly what's now in layout/html/base/src/ -
looking for a better name (*) ]
layout/forms/
layout/tables/
layout/printing/ [ or should this just be within base ? ]
layout/xul/
layout/xulgrid/
layout/xultree/
(*) Why "nodes"? I don't want to use "frames" because it's a confusing
term to people looking for code that does something. I don't want
"boxes" because that has a specific meaning in XUL (nsIBox), although it
would otherwise be the right term. I originally had corenodes, forms,
tables, and xul* all as subdirectories of layout/nodes/, but that
hides the depth of the structure. I'd rather have a flatter
structure, since it's much easier to find things, and I can't think of
a clear name that says "lots of stuff will be in this subdirectory"
(like netwerk/protocols/).
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/xul/base/{public,src}/ -> layout/xul/
layout/xul/base/src/grid/ -> layout/xulgrid/
layout/xul/base/src/tree/{public,src}/ -> layout/xultree/
Furthermore, of the enumerated files within content/base/ above:
the ones containing "Print" in the filename -> layout/printing/
nsIStyle* -> layout/style/sheets/
nsRuleNode.cpp and nsStyleContext.cpp -> layout/style/data/
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/corenodes/
with the following exceptions:
layout/base/public/nsHTML* -> layout/corenodes/
layout/base/public/ns*Frame.h -> layout/corenodes/
layout/base/src/nsIntervalSet* -> layout/corenodes/
layout/base/src/nsSpaceManager* -> layout/corenodes/
layout/html/base/src/nsFrameManager.cpp -> layout/base/
layout/html/base/src/nsPresShell.cpp -> layout/base/
layout/html/style/src/nsIHTMLStyleSheet.h -> layout/style/sheets/
That leaves the files in the following directories to be handled
individually:
content/html/style/
content/shared/
Listing them only by their leaf name, I propose they end up in the
following locations:
layout/style/sheets/nsICSSLoader.h
layout/style/sheets/nsICSSLoaderObserver.h
layout/style/sheets/nsICSSParser.h
layout/style/sheets/nsICSSPseudoComparator.h
layout/style/sheets/nsICSSStyleSheet.h
layout/style/data/nsIComputedDOMStyle.h ? (maybe sheets?)
layout/style/sheets/nsIMediaList.h
layout/style/sheets/css.properties
layout/style/sheets/nsCSSDataBlock.cpp
layout/style/sheets/nsCSSDataBlock.h
layout/style/sheets/nsCSSDeclaration.cpp
layout/style/sheets/nsCSSDeclaration.h
layout/style/sheets/nsCSSLoader.cpp
layout/style/sheets/nsCSSLoader.h
layout/style/sheets/nsCSSOMFactory.cpp
layout/style/sheets/nsCSSOMFactory.h
layout/style/sheets/nsCSSParser.cpp
layout/style/sheets/nsCSSRule.cpp
layout/style/sheets/nsCSSRule.h
layout/style/sheets/nsCSSRules.cpp
layout/style/sheets/nsCSSScanner.cpp
layout/style/sheets/nsCSSScanner.h
layout/style/sheets/nsCSSStruct.cpp
layout/style/sheets/nsCSSStruct.h
layout/style/sheets/nsCSSStyleRule.cpp
layout/style/sheets/nsCSSStyleSheet.cpp
layout/style/sheets/nsCSSValue.cpp
layout/style/sheets/nsCSSValue.h
layout/style/data/nsComputedDOMStyle.cpp ? (maybe sheets?)
layout/style/data/nsComputedDOMStyle.h ? (maybe sheets?)
layout/style/sheets/nsDOMCSSAttrDeclaration.cpp
layout/style/sheets/nsDOMCSSAttrDeclaration.h
layout/style/sheets/nsDOMCSSDeclaration.cpp
layout/style/sheets/nsDOMCSSDeclaration.h
layout/style/sheets/nsDOMCSSRGBColor.cpp
layout/style/sheets/nsDOMCSSRGBColor.h
layout/style/sheets/nsDOMCSSRect.cpp
layout/style/sheets/nsDOMCSSRect.h
layout/style/sheets/nsDOMCSSValueList.cpp
layout/style/sheets/nsDOMCSSValueList.h
layout/style/sheets/nsHTMLAttributes.cpp ? (maybe content?)
layout/style/sheets/nsHTMLAttributes.h ? (maybe content?)
layout/style/sheets/nsHTMLValue.cpp ? (maybe content?)
layout/style/sheets/nsHTMLValue.h ? (maybe content?)
layout/style/sheets/nsHTMLCSSStyleSheet.cpp
layout/style/sheets/nsHTMLStyleSheet.cpp
layout/style/sheets/nsICSSGroupRule.h
layout/style/sheets/nsICSSImportRule.h
layout/style/sheets/nsICSSMediaRule.h
layout/style/sheets/nsICSSNameSpaceRule.h
layout/style/sheets/nsICSSOMFactory.h
layout/style/sheets/nsICSSRule.h
layout/style/sheets/nsICSSStyleRule.h
layout/style/sheets/nsICSSStyleRuleDOMWrapper.h
layout/style/sheets/nsICSSStyleRuleProcessor.h
layout/style/sheets/nsIHTMLCSSStyleSheet.h
layout/style/data/nsIInspectorCSSUtils.h
layout/style/data/nsInspectorCSSUtils.cpp
layout/style/data/nsInspectorCSSUtils.h
layout/style/sheets/nsROCSSPrimitiveValue.cpp
layout/style/sheets/nsROCSSPrimitiveValue.h
layout/style/sheets/nsStyleUtil.h
layout/style/sheets/nsStyleUtil.cpp
layout/base/nsBidiUtils.cpp ?
layout/base/nsBidiUtils.h ?
layout/style/sheets/nsCSSKeywordList.h
layout/style/sheets/nsCSSKeywords.cpp
layout/style/sheets/nsCSSKeywords.h
layout/style/sheets/nsCSSPropList.h
layout/style/sheets/nsCSSProperty.h
layout/style/sheets/nsCSSProps.cpp
layout/style/sheets/nsCSSProps.h
layout/base/nsChangeHint.h
content/html/content/src/nsImageMapUtils.cpp ?
content/html/content/src/nsImageMapUtils.h ?
layout/style/data/nsRuleNode.h
layout/style/data/nsRuleWalker.h
layout/style/data/nsStyleContext.h
layout/style/data/nsStyleCoord.cpp
layout/style/data/nsStyleCoord.h
layout/style/data/nsStyleStruct.cpp
layout/style/data/nsStyleStruct.h
layout/style/data/nsStyleStructList.h
content/base/src/nsTextFragment.cpp
content/base/public/nsTextFragment.h
The following should probably all go in layout/base/, but that might make
it a bit crowded. Any better ideas?
nsAtomListUtils.cpp
nsAtomListUtils.h
nsHTMLAtomList.h
nsHTMLAtoms.cpp
nsHTMLAtoms.h
nsLayoutAtomList.h
nsLayoutAtoms.cpp
nsLayoutAtoms.h
nsSVGAtomList.h
nsSVGAtoms.cpp
nsSVGAtoms.h
nsXBLAtomList.h
nsXBLAtoms.cpp
nsXBLAtoms.h
nsXULAtomList.h
nsXULAtoms.cpp
nsXULAtoms.h
nsCSSAnonBoxList.h
nsCSSAnonBoxes.cpp
nsCSSAnonBoxes.h
nsCSSPseudoClassList.h
nsCSSPseudoClasses.cpp
nsCSSPseudoClasses.h
nsCSSPseudoElementList.h
nsCSSPseudoElements.cpp
nsCSSPseudoElements.h
I realize a reorganization is painful, but I think we need to do it, and
now's as good a time as any (and better than many).
Thoughts?
-David
--
L. David Baron <URL: http://dbaron.org/ >
L. David Baron
>
> layout/base/ [ Central objects and things that don't go anywhere else. ]
I also wouldn't mind calling this layout/shell/ or layout/center/.
> layout/corenodes/ [ roughly what's now in layout/html/base/src/ -
> looking for a better name (*) ]
> layout/forms/
> layout/tables/
> layout/xul/
> layout/xulgrid/
> layout/xultree/
It occurred to me that another possibility (in addition to putting all
these in a nodes/ subdirectory, is that they could all have "nodes-"
prefixed on to the names. And I think I prefer "base" to "core" if
possible.
Also, I realized I forgot layout/html/document/src/. I'd dispose of
these files by:
*.cpp -> layout/corenodes/
and I'm actually not sure what I'd want to do with the rest. (All in
one place, or distributed? Perhaps layout/style/default/?)
Robert O'Callahan
L. David Baron wrote:
> 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. It
> also tends to make things more difficult to read and edit.
I'm not sure about this. I think a 'public' directory is helpful if we
adhere to the rule that files not under the 'layout/' directory can use
only those interfaces in 'layout/public'.
> (*) Why "nodes"? I don't want to use "frames" because it's a confusing
> term to people looking for code that does something. I don't want
> "boxes" because that has a specific meaning in XUL (nsIBox), although it
> would otherwise be the right term. I originally had corenodes, forms,
> tables, and xul* all as subdirectories of layout/nodes/, but that
> hides the depth of the structure. I'd rather have a flatter
> structure, since it's much easier to find things, and I can't think of
> a clear name that says "lots of stuff will be in this subdirectory"
> (like netwerk/protocols/).
I hate the term "nodes" and I don't like the other suggestions much
better :-). How about this:
layout/html (i.e., your "corenodes")
Then put forms and tables under html:
layout/html/forms
layout/html/table
Also, I think you should put tree and grid under xul:
layout/xul/tree
layout/xul/grid
Rob
L. David Baron
> I hate the term "nodes" and I don't like the other suggestions much
> better :-). How about this:
> layout/html (i.e., your "corenodes")
> Then put forms and tables under html:
> layout/html/forms
> layout/html/table
I really don't like using "html" here. The forms stuff is somewhat
HTML-specific, but most of the rest isn't, and I don't see why it should
be called HTML. Our implementation of HTML is in content/html/ and in
html.css.
> Also, I think you should put tree and grid under xul:
> layout/xul/tree
> layout/xul/grid
I've been trying to avoid having directories that contain both files and
subdirectories, but maybe that's not so bad.
Roger B. Sidje
> 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/sheets/ [ Style sheet objects and supporting code ]
> layout/style/data/ [ Style data computation ]
layout/style/cascade/ ?
> layout/corenodes/ [ roughly what's now in layout/html/base/src/ -
> looking for a better name (*) ]
What about a mass s/IBox/IXULBox/g (as it should have been in the
first place), before grabbing layout/boxes/.
["corenodes" seems to match "frames", if it doesn't beat it...].
---
RBS
Christopher Blizzard
> Mostly sounds great...
>
> L. David Baron wrote:
>
>> 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. It
>> also tends to make things more difficult to read and edit.
>
>
> I'm not sure about this. I think a 'public' directory is helpful if we
> adhere to the rule that files not under the 'layout/' directory can use
> only those interfaces in 'layout/public'.
>
Aren't we trying to get rid of bogus interfaces, except those that
actually are the dmz between layout and the outside world? Removing a
lot of bogus over-objectification is part of de-COM-tamination, eh?
--Chris
Robert O'Callahan
Sure. But even in the ideal state, we'll still have XPCOM interfaces
exported by layout. Also, we'll have non-XPCOM interfaces exported by
layout/ to other parts of Gecko (content/, accessibility/, gfx/, at least).
Rob
Robert O'Callahan
> On Sunday 2003-09-21 15:20 -0400, Robert O'Callahan wrote:
>
>>I hate the term "nodes" and I don't like the other suggestions much
>>better :-). How about this:
>>layout/html (i.e., your "corenodes")
>>Then put forms and tables under html:
>>layout/html/forms
>>layout/html/table
>
>
> I really don't like using "html" here. The forms stuff is somewhat
> HTML-specific, but most of the rest isn't, and I don't see why it should
> be called HTML. Our implementation of HTML is in content/html/ and in
> html.css.
Technically that's true, but 99% of the time that code is being used to
render HTML. Furthermore if I was a newbie and looking for block and
line stuff, that would lead me to the right place. OTOH, "corenodes"
wouldn't mean much to me and "xml" or "css" would probably discourage me
from looking there.
>>Also, I think you should put tree and grid under xul:
>>layout/xul/tree
>>layout/xul/grid
>
>
> I've been trying to avoid having directories that contain both files and
> subdirectories, but maybe that's not so bad.
Yeah, I think that's less important than logical directory structure.
Rob
fantasai
> L. David Baron wrote:
>
>> On Sunday 2003-09-21 15:20 -0400, Robert O'Callahan wrote:
>>
>>> I hate the term "nodes" and I don't like the other suggestions much
>>> better :-). How about this:
>>> layout/html (i.e., your "corenodes")
>>> Then put forms and tables under html:
>>> layout/html/forms
>>> layout/html/table
>>
>> I really don't like using "html" here. The forms stuff is somewhat
>> HTML-specific, but most of the rest isn't, and I don't see why it should
>> be called HTML. Our implementation of HTML is in content/html/ and in
>> html.css.
>
> Technically that's true, but 99% of the time that code is being used to
> render HTML. Furthermore if I was a newbie and looking for block and
> line stuff, that would lead me to the right place. OTOH, "corenodes"
> wouldn't mean much to me and "xml" or "css" would probably discourage me
> from looking there.
I've had trouble finding things *because* they were under 'html', which
I erroneously assumed meant HTML-specific. How about 'generic'?
/layout/generic/table
Or 'box', since it's layout "boxes" we're dealing with?
/layout/box/table
~fantasai
Robert O'Callahan
That's not great, but I guess it's better than all the other suggestions
I've heard so far :-).
> Or 'box', since it's layout "boxes" we're dealing with?
>
> /layout/box/table
"Box" was unfortunately usurped by XUL.
Rob
Axel Hecht
<...>
>
>
> It occurred to me that another possibility (in addition to putting all
> these in a nodes/ subdirectory, is that they could all have "nodes-"
> prefixed on to the names. And I think I prefer "base" to "core" if
> possible.
>
prefixes are sad for TAB-completion, and xul-nodes sounds more fluent
than nodes-xul to me, too. Though I understand the nodes-story to be
said and done anyway.
Axel
Boris Zbarsky
Talk about dredging up old stuff, eh? ;)
> layout/base/ [ Central objects and things that don't go anywhere else. ]
> layout/style/sheets/ [ Style sheet objects and supporting code ]
> layout/style/data/ [ Style data computation ]
I agree with roc that "cascade" seems better here.
> layout/corenodes/ [ roughly what's now in layout/html/base/src/ -
> looking for a better name (*) ]
Fantasai's "generic" suggestion is the best I've seen.... I guess
"box-model" would still be too XUL-like? On the other hand, are we
perhaps drawing a spurious distinction between this and layout/base/?
Maybe this stuff should just live in base/? Or would that make it have
too much stuff?
Maybe layout/css-box/ ?
> layout/printing/ [ or should this just be within base ? ]
No, putting the print-specific stuff on its own makes sense to me...
> layout/style/sheets/nsHTMLAttributes.cpp ? (maybe content?)
> layout/style/sheets/nsHTMLAttributes.h ? (maybe content?)
> layout/style/sheets/nsHTMLValue.cpp ? (maybe content?)
> layout/style/sheets/nsHTMLValue.h ? (maybe content?)
Those seem pretty solidly content to me.... nsHTMLValue.h will need to
be exported, probably, since things in layout do use it. I doubt anyone
except content cares about nsHTMLAttributes.
> layout/base/nsBidiUtils.cpp ?
> layout/base/nsBidiUtils.h ?
Looks reasonable.
> content/html/content/src/nsImageMapUtils.cpp ?
> content/html/content/src/nsImageMapUtils.h ?
Yeah, something along those lines.
> The following should probably all go in layout/base/, but that might make
> it a bit crowded. Any better ideas?
[lists of atoms munged]
layout/atomlists/ ? ;)
> I realize a reorganization is painful, but I think we need to do it, and
> now's as good a time as any (and better than many).
I agree that we want to do it, and I can't decide whether it's better to
do it during the 1.6 final freeze (with its lower checkin volume) or at
the beginning of 1.7a... I lean toward the former, if drivers are ok
with it.
It sounds like people are pretty much agreed except for this issue of
what to name the dir with the "basic" frame impls...
-Boris