> 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! Concerning that aspect, I totally agree. > > 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). I'm not opposed to that but at least we should consider a (maybe) more back compatible way to save space:
Facts: Whatever we cope with widgets or labels they more or less need the same style attribute like color,font,box style. Other (simpler) alternative to the Fl_Label inherited from Fl_Widget: I would like to consider the possibility to simply factorize these attributes into a structure that would be the widget label style state definition, plus accessors and initialization handling. i.e: Fl_Widget::color() would be implemented as getStyle()->color(), getStyle would create style_ on the fly, the Style structure containing the atttributes we want to factorize, but only when set accessor() would be instanciated, when get accessors are instanciated and no set has been made, the default get version returns the default color... IMHO, it would be easier to implement, inlined Fl_Widget accessors would ensure backward compatibility, It would be also efficient concerning memory because as long as you keep the default style of a Label it won't create anything. Of course it won't create anything at initialization too so that if you don't need labels at all, you keep a null pointer to that structure internally. Any thoughts ? Fabien _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
