Fabien Costantini wrote: > > 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_.
To remove the Fl_Label structure and replace it with a pointer would save even more space in Fl_Widget. In my app, there can be hundreds of widgets that don't have a label at all. This would be a great win! If we would derive Fl_Label from Fl_Widget, the first Fl_Label could be a group and manage all the other Fl_Label children, or every Fl_Label child could also have a Fl_Label (this would constitute a linked list of labels). > 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 ... Yes, but that doesn't count ;-). Fl_Group derived widgets are designed to _have_ children. Everything else should be considered pathological. BTW: Fl_Scroll could also be changed to allocate the scrollbars only when needed, and thus could be much smaller, if there are no scrollbars (the default when it is created or all widgets fit into it). The next step would be that every widget can also have scrollbars (if it is a group, then why not ?). If we set the already existing scrollbar flags to 0 (no scrollbars), then it would behave like a normal group (or widget). Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
