I send a message to Noah Stein, where I think I've gotten a bit closer to what I'm trying to convey with rendering strategies, so I'm going to paste the relevent part... [paste] I want to drive home the point that hit-testing is easy for axis-aligned bounding boxes, and complicated visibility and hit testing is not necessary for a Symbian UI. Through generic programming, I'd like to leave it out when I don't need it, not think about it when I don't have to. The Win32 GDI mistake was to create a tree of graphic objects, each materialized in memory. Recognizing the common models of content rendering, you can devise better strategies than the allocation of a chunk of memory for every axis-aligned bounding box on the screen. (Or, conversely, throwing up your hands and saying that anything further is in the application domain. This is old, this is bad. It's widgets or the pen.) [snip] I agree that you can nest a canvas, in a form, in a document, and you can do this because of an axis-aligned box convention. It is exactly what I'd like to be able to do. Use a *canvas* renderer to render an vector graphics image in the corner of a button, or use a *document* renderer to draw formatted tool tips read from a resource file. (If I'm on a /G/UI that is.) A nested axis-aligned bounding box paradigm that rules UI organization. However, a *grid* has special needs. A *document* has special needs. A *document* should not have to materialize an object for each axis-aligned bounding box, attaching a font, pen, brush, background to each. Not when there is an obvious convention of inheriting styles from the containing bounding box. See? Recognize the rendering strategy, then you can optimize design. For a *document* each box need only be t,l,r,b, and, /and/ can be disposed of when it is off screen. For a *grid* you don't need a structure to represent the axis-alined box, you only need the height of reach row and the width of each column. Ah, but not of /each/ row and column, you can have a sparse list that indicates a change in row or column width, since they tend to be uniform. A *grid* does not need to keep components in memory, they only exist when activated. Materialized axis-aligned boxes are optimal for a *form*. For a fixed set of axis-aligned boxes, you can create an object, and take advantage of optimization that comes from using memory. Materialized axis-aligned boxes are also optimal for partitioning a window's client area. Thus my concern that this model will be mistaken for a panacea. Good for some things. Non-applicable for others. When it's not applicable, I don't think the library designers should throw up their hands and go, oh, looks like an application problem. Here's some grahpics utilities. Good luck. A *grid* or a *document* or a *form* have conventions that lend themselves to optimizations. Am I getting somewhere? -- Alan Gutierrez - alan@engrm.com