> matthiasm wrote (in another thread): > > > WRT the earlier suggested Label-in-a-widget and other special widgets > > that have child-like widgets without beeing a group, I suggest that we > > find a general way to dispatch events. This would make it alos much > > easier to derive composite widgets from more useful superclasses > > instead of Fl_Group. > > I assume you're not talking about signals and slots or other completely > different event dispatching methods? And you're not talking about the > idea that every widget should also be a group and can have child > widgets? (Although I think that having child widget (or subwidgets,
I guess that's the idea of the composite pattern, we had a very similar discussion some years ago, I believe I argued in favor of the Composite pattern to be applied to the widget base class, one idea I had related to that was that if it was the case ; we could directly use an Fl_Widget as a box (with the label() feature) and also as a simple group (with the new children() capabilities). So It would remove 2 obsolete classes (here Fl_Box and Fl_Group) at the cost of making the Fl_Widget class even more rich in api that it is now (more methods from composite and last but not least more handle() code) This idea would greatly enhance the composite widget manipulation, but would have imho at least two con's: - incompatibilities with the 1.1.x branch (maybe we could add fake Fl_Group class typedef'd to Fl_Widget and so on, to limit the incompatibilities?) - even bigger Fl_Widget class > > For example, Fl_Input_Choice ../.. > > should rather be derived from Fl_Text_Input because it expands the > > functionality of Fl_Text_Input, and not Fl_Group. Without a composite widget, nor the albrecht solution consisting of parenting the box to the parent group with the cons about widget destruction handling, another idea could consist of creating a parent group and reparenting dynamically both the Fl_Text_Input and Fl_Box widgets into this new group, but it seems the best solution here would be the composite IMHO ... _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
