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
Not sure I am following you correctly - you are talking about Parent/Child Tree Structure in the widget editor?
I tried making a “Class” that I could put my script in, then making a widget and setting its class to that widget class. But then I ran into the issue, because only one (Parent or Child) can have a tree-structure, the script needs to reference layout elements (Text, Buttons etc.) which, if the layout is to be empty in the parent, cannot reference, or if I Put those elements in the parent so script can reference, I cannot put anything into the child, so now at this point I do not follow what the point is in setting a “class” for the widget, although for very basic scripting which does no have to reference any layout widget elements.
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
So if widgets have a tree-structure that of Actors, I can create a Parent Class with “Components”, and when I create a Child Class, it inherits those Components, and code written for that widget (lets say the “Window”) will function. But then in the Child Class, I could add more components that relate to that version of the parent (a specific stylized “window”) and keep the functionality of the parent scripts. Like in Actors, you have to remove elements from the Parent that exist on the parent.