On 05/04/2012 07:05 AM, Matthias Melcher wrote: > > 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 >
I would like to stay away from multiple inheritance in a library that people want to reuse, and want to learn the api for. Just put the ability to have child widgets into the basic Widget. Group still exists, but it only adds cruft that is not needed by all widgets, such as the resizebox, and fltk 1's automatic begin/end. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
