On 15.04.2012 22:00, Edzard Egberts wrote: > No, the latter means, that there are is additional "Fl_Fontsize > textsize_;" inside of Fl_Label. The new data were not added to > Fl_Widget, but to Fl_Label.
Fl_Label is an own struct, but is a (private) component of Fl_Widget. Changes in Fl_Label would change the size of Fl_Widget, and thus would change the ABI. >> Probably okay for the API, but not for the ABI. We'd need to add new >> members (at least one) to Fl_Widget. Adding the textsize() method to >> Fl_Widget wouldn't harm, though. > > I think it's possible to push all changes into Fl_Label, so there are no > changes of API. But would this break ABI? That would mean, there is no > possibility remaining to realise it without breaking ABI. Yes, this is true. However, if you followed recent development, you could see that we created a way to add ABI-breaking features to FLTK that would only be activated, if a developer requested these features explicitly by changing a compiler (preprocessor) macro. So, speaking in general, we *can* now add ABI-breaking features if we're convinced that they will/should be in a future version of FLTK and that they are not too big a change so that we can maintain the code with all the necessary #ifdef's. > This is first answer, but comments to the rest of your posting would > depend on this ABI question. Looking forward to your comments. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
