On 04.05.2012, at 15:30, Edzard Egberts wrote: > Matthias Melcher schrieb: >> For composite widgets, I would like to propose something else though. >> It should be possible to derive a new widget from any other widget, >> based on the data that widget provides, not on the UI. For example, >> InputChoice is derived from Group. That is silly, because Group does >> not normally handle text. It should rather be derived from Input, >> right? >> >> But currently only a Group can have children. So what I would like to >> do is keep the children in Group (no need to move them to Widget - >> that would be a waste), but add something to Widgets that I call >> Nephew for lack of a better word. > > Is it necessary, that a group is a widget? What do you think of this: > > class Fl_Group: public Fl_Widget, public Fl_Basic_Group > > class Fl_Composed_Widget: public Fl_Input, public Fl_Basic_Group > > The approach is not to derive, but to assemble.
Multiple inheritance in C++? You are a brave brave man ;-). Unless the second class is pure virtual, I would not do it. We use quite a lot of pointer casting the old way, which can break multiple inheritance quite easily. Our callback mechanism, casting a pointer to an int and back, would be a killer. And then there is the diamond inheritance issue... . - Matthias _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
