There is a branch of fltk2 that does exactly this, however there was some serious negative reaction so it was never put in the trunk. We called it the "Group/Widget merge".
As you suggest, the children count and array pointer were replaced with a single pointer to a structure that is only allocated if there are non-zero children. This makes Widget one pointer larger and Group two integers smaller. What is being called "requred children" were not put into this array. Instead the scrollbars have dedicated pointers to them. Their parent pointer points at the Fl_Scroll. This is pretty much unchanged from how it is now. The idea of making the label() be a child widget is pretty interesting, but what I really wanted to get first was to make the image() be a child widget. Fabien Costantini wrote: >> 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
