A little file reorganization

[L. David Baron]

Now that we're on hg and renames are easy, I'd like to do a few more
of them in layout. In particular:

* move nsStyleConsts.h from layout/base/ to layout/style/

* rename nsFrameFrame.cpp to nsSubDocumentFrame.cpp, to match the
class name in it

* rename nsTextFrameThebes.cpp back to nsTextFrame.cpp (from which
it was forked, and which was then removed), to match the class
name in it

* do something about nsHTMLFrame.cpp, which contains a class called
CanvasFrame, which represents the CSS "canvas" (the space over
which everything is drawn, inside the viewport). We don't want
to confuse it with nsHTMLCanvasFrame, which is the HTML <canvas>
element. My inclination is to rename both the file and the class
to be nsCSSCanvasFrame, but I'd be happy to hear better
suggestions for the name.

At some point (though probably not as soon) I might also want to try
to flatten the directory structure inside layout/xul, layout/svg,
and layout/mathml, but that's a slightly bigger project.

Thoughts?

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

[rocal...@gmail.com]

On Sep 16, 10:11 am, "L. David Baron" <dba...@dbaron.org> wrote:
>  * move nsStyleConsts.h from layout/base/ to layout/style/

Good

>  * rename nsFrameFrame.cpp to nsSubDocumentFrame.cpp, to match the
>    class name in it

Great

>  * rename nsTextFrameThebes.cpp back to nsTextFrame.cpp (from which
>    it was forked, and which was then removed), to match the class
>    name in it

Good

>  * do something about nsHTMLFrame.cpp, which contains a class called
>    CanvasFrame, which represents the CSS "canvas" (the space over
>    which everything is drawn, inside the viewport).  We don't want
>    to confuse it with nsHTMLCanvasFrame, which is the HTML <canvas>
>    element.  My inclination is to rename both the file and the class
>    to be nsCSSCanvasFrame, but I'd be happy to hear better
>    suggestions for the name.

nsInitialContainingBlockFrame?

> At some point (though probably not as soon) I might also want to try
> to flatten the directory structure inside layout/xul, layout/svg,
> and layout/mathml, but that's a slightly bigger project.

Yeah, that sounds good too.

I assume these renames won't cripple people who are maintaining huge
out-of-tree patches, thanks to hg merging. Jeremy Lea has one, but I
don't know of any others (and we should get more of his stuff landed
anyway).

Rob