Fabien Costantini wrote: >> 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 ?
I didn't think deeper about the implementation, I was just adding 1 and 1 together and getting 2 and a half ;-) Matt proposed to do this, and he added a comment in a source file (probably Fl_Widget.cxx), and I just thought that this would be a good idea. Every useful implementation would be okay for me. And I do also think that the existing API should not change for the normal use. Everything else should be encapsulated in the implementation. With the exception of new features, of course. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
