Your layout code is impressive. From all other projects that involve layout I looked at in the before (open office, abiword, fop) your code is in a better shape by far. I appreciate design documentation, comments in the code, naming and other practices - it all makes your code a reasonable reading.
I'm looking into your layout because I work on another layout project and face some issues. I cannot contibute to your project directly in code, but I hope that by trying to understand your code and sometimes asking questions I can leave sort of a useful contribution here. Today's questions are about views. There seems to be no design documentation about views. Maybe this is a start. 1. View objects form some sort of a tree, somewhat parallel to the frame tree? I kinda grasp the view concept, but I struggle to explain what views are exactly used for in your project. Maybe a concrete example would help. 2. Some frames (or types of frames?) have views associated with them and some not. Maybe an example would help. When a frame would have a view? What code decides whether a frame will have a view or not? 3. Views somehow help with scrolling and clipping of the associated frame(s)? I guess an example for a view with scrolling could be an HTML list box? The list of items is laid out onto a frame object and there is a view associated with this frame object. The view object just clips out and scrolls the otherwise long list of items. 4. There was a move by Robert to minimize the usage of views or get rid of them completely. In his blog Robet mentioned he was working towards Display Lists (and I think achieved that), but view classes still remain in the code. Is it still in the plans to remove the views? --------------------------- Here is another little "contribution" from me. I know I'm not in a position to issue negative comments on a project like this, but my only wish is to help. Here we go: 1. If you followed the "one class = one file" rule it could have made the code easier to find and read. For example gfxTextRun class is defined in dfxFont.h. It is confusing to me. There is a known good practice where the name of the class and name of the header and source files are the same. gfxTextRun should have been defined in gfxTextRun.h and gfxTextRun.cpp 2. You don't seem to be using namespaces. As a result of that I'm facing a flat list of over 1,600 classes and its not making my life easier. Prefixes given to class names (such as gfx) certainly help, but they are not consistent. For example, there is no prefix for layout classes or for frame classes, but there are prefixes for CSS, HTML etc classes. Any reasons for not using namespaces? Maybe historical? Namespaces in C++ appeared not so long ago I heard. 3. There seems to be only a handful of classes 6,000-7,000 lines long such as nsTextFrame, nsPresShell and nsTableFrame while many other classes are very small. Same with the length of methods, there are only a few 400+ lines methods while the rest are reasonable. On projects that I'm involved with I call this "disbalance of complexity" and usually focus refactoring efforts on these. Honestly, I cannot understand a 7000 lines long class neither can I read a 400 lines method. Perhaps a guideline in the coding standard would be helpful regarding reasonable sizes, enforced during review. Cheers, Roman _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
