Roman Korchagin wrote: > 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.
Views form a tree that's more or less a subtree of the frame tree, except the view tree can span across documents. I think there used to be frameless views in scrollframes at some point, but I'm pretty sure we got rid of that... The idea of views initially, as I understand it, is that they were compositing units. That is, painting always started at a view and worked down from the corresponding frame in the frame tree. > 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? Historically, when it needed to be composited in a nontrivial way (e.g. had opacity, was clipped, etc). In general, frame classes can have views if they decide so. but see also nsContainerFrame::FrameNeedsView. It used to be much more extensive. ;) > What code decides whether a frame will have a view or not? The callers of FrameNeedsView. > 3. Views somehow help with scrolling and clipping of the associated > frame(s)? At this point, I believe all views are used for, basically, is scrolling and as a way to hang nsIWidgets off of (so for fixed-positioned frames and plug-ins). > I guess an example for a view with scrolling could be an HTML > list box? Or the main browser content area. Or anything with "overflow: scroll" set on it. > 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? Yes. > 2. You don't seem to be using namespaces. See http://www.mozilla.org/hacking/portable-cpp.html#dont_use_namespace At this point they could probably be used somewhat safely, but the codebase already exists and all. > 3. There seems to be only a handful of classes 6,000-7,000 lines long > such as nsTextFrame, nsPresShell and nsTableFrame The problem, of course, is that some of these are just complex things to do... But yes, some of these (and others like nsCSSFrameConstructor) could use refactoring or cleanup. Patches accepted! ;) -Boris _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
