Some ideas about layout: About the way to organize the class hierarchy, it's not ideal to have a specialized descendant of OXCompositeFrame for each type of layout, because general widgets (like dialog boxes) can either be vertically or horizontaly arranged. If we choose a structure like this OXCompositeFrame | +--OXVerticalFrames | +--OXHorizontalFrames etc... then we must have multiple descendant for each type of layout, e.g.: OXMenuVertical, OXMenuHorizontal, etc. We can't either to have a pointer to a layout function for technical reasons (C++ won't let us point at a member function). So far, we have used flags to implement all the different layout policies in a single OXCompositeFrame object: it's not clean, and it's not easily expandable. So, I propose to consider layout as a separate entity (read: object), similar to the Java AWT concept. OLayoutManager | +--OVerticalLayout | +--OHorizontalLayout | +--OVerticalTiledLayout That way a OXCompositeFrame object contains a layout manager object that could even be changed at runtime. Layout Policy: - inner (child) frames *never* modify parent's size; instead the parent can (or cannot) adapt it's own size in order to show all (or part) of its content. - a frame (particularly OXSimpleFrame) has a default minimum size under which it cannot shrink: the limit is 1,1 to avoid XLib errors. - we do not define a maximum size yet.