> The basic Composite (in the Design Patterns sense) doesn't have > this distinction. A component is either a composite with children, > or it is a leaf. We really need a modified composite with "fixed" > children and "optional" children. Even the basic Composite does not prevent you to add children to leaf, if you make the distinction between : - For the external widget I am not a group (in the sense here of Fl_Group) as for today we could use the existing type() to express that and i would ensure total backward compatibility. - For the internals of the widgets, you could use the underlying children structure to add custom subwidgets that would be "seen" as one for the external world, but still it would be correctly handled inside the controlling widget.
My guess is that we have _almost all to win_ and few to lose except maybe the room necessary to store the group children info when the widget would not have a group feature. But even then, I reviewed recently the Fl_Group code and fortunately for us, the internal attributes to handle children (array_,children_ and size_) are all private ; so it could be quite easy to replace that 3 attributes internally by only one pointer on a structure encapsulating these attributes. When NULL, it would simply means that there is no children, when not null the children() would return the structure attribute children_. Not only it would be more economical for the Fl_Widget, but also all Fl_Group derives classes could benefit to have 8 bytes less per group in a 32 bit architecture as an example ... Concerning now the performances, my guess is you won't see any noticeable differences. Fabien _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
