I was getting at what you said about having to call not only the adding of the child widget, but also its removal. One of the “problems” with parent / child inheritance is it quickly turns into a tree structure, where in order to modify existing inheritance there needs to be pre-written instructions to add / remove inherited traits (in this case the traits would be layout properties and functions). And it’s always then bound to the parent, which if it is not modified correctly, can result in child instances becoming more tedious to clear of unwanted traits and adding wanted traits. With a base class, it would be similar to a template or modular system that doesn’t require such a ton of restructuring of inheritance at more complex or deeper levels. It would involve, as you said, duplicating or perhaps instantiating the base class layout (and anything else selected for in the base “class”…denoting the C++ class term), then modifying its properties and functions. So multiple base classes could be created with certain properties and functions already set, and then instantiating or duplicating that for designing a particular layout while retaining those properties / functions and adding and modifying new ones. It’s to get rid of the necessity to call the parent class, then remove certain child widgets / inherited traits, then add new ones…and then do it all over again for a completely new interface or part of the interface. That way it’s not bound to the parent in every aspect of the menu / window system that is to be developed. Several or more base classes could be created from the start that are intended for designing several or more different aspects of the interface…all without having to reference the parent class and continuously alter its inheritance over differing iterations.