Alright, this thread has sort of morphed into a discussion of three issues: 1: BBox We have the idea of adding a BView::SetInsets() to deal with this. That seems unclean to me, especially if layouts already support insets. Nesting layouts is really easy, and it's also very powerful. Why add *more* layout features to BView, further confusing things? I still think adding a BBoxLayout is the best solution; it won't require adjusting the BBox use in our apps, and doesn't require any deviation from the other parts of the Interface Kit. Clean and consistent :) With this idea, there is really no need for a SetContentLayout() method, since box->GetLayout()->AddItem(myLayout) (or box->AddChild(myLayout) makes perfect sense, just like you can add layouts to a BGroupView. We also have the idea of having BBox manage the insets of its layout, which would work fine (even without BVIew::SetInsets()). BBox could call SetInsets() on the layout, using a nested layout if you wanted extra insets. 2: BView::AddChild() -> BLayout::AddItem(). Theoretically, I do like the idea of breaking this behaviour, but the potential work included isn't something that I want to do. For this reason, I prefer the proposal of using a view flag to trigger this, or potentially a flag could be passed to AddChild(). Encouraging people to learn the API and focus on using the layout over the view is important, though and breaking this behaviour would do that. 3: BLayoutItems with a BView must have the BView in the layout's target view. (layout swapping) Breaking this guarantee would mean that layout items could be added before SetLayout() is called. This doesn't seem necessary to me, but it's a limitation we could remove without too much work, and I don't think it would cause too many problems. The main one that I can think of would be memory management, if a view is not part of a hierarchy, and the layouts it is part of are deleted, then does the view get deleted? It's impossible to say, because we don't know if the user has a pointer to it somewhere. In addition to breaking this guarantee, the layout swapping case would also require the ability for a layout item to be in multiple layouts at once. This would again be possible, but doesn't seem very useful. What if a layout item is in two sibling layouts, and both are enabled? This is really a weird use case to me, and the adage of 'make simple things easy, and hard things possible' is already met with the current API. That saying has some hidden wisdom in it; making hard things *possible* also means not wasting time trying to cater for every weird edge case you can think of, as long as the API is flexible enough to meet them with some work. --Alex