IMHO, it would be nice to split these modifications in two branches like branch-1.3-scroll and branch-1.3-composite.
As I said, I easily agree with the scroll changes, but the composite widget aspect is just something else. What I would like to discuss here is about the composite aspect: I had a look to the modifications and a look to the sources. This is not what I would call a composite because it lacks the capacity for a widget to iterate on all its children. I think we may regret this critical absence of functionality. A composite permits tree walking without having to distinguish groups from leaves, the latter one having no child as the main difference. As I saw it when we discussed, the widget would have all the children tree related api, thus permitting to any widget to handle widgets it may not know at creation time for instance. Then the Fl_Group would only provide a concrete version (with draw() implemented) of the pure class Fl_Widget. But in the composite svn branch, we can have Fl_Widget having as parent an Fl_Widget but not explicitly real subwidgets, what I mean by this is that it would be quite difficult for a widget to discover and handle its children dynamically as a group would do as there is no children() iteration api. We shouldn't understimate the flexibility that further the real composite pattern, i.e: you get a widget or a group as an input parameter of a widget iterating based function transparently. I also think about the fundations of future potential version of tree browser widgets here :-) Sorry for this long message, but I think we should take this opportunity as maybe the only one to add such an internal change for the Fl_Widget. After it is made, we will be more or less slaved to compatibilities issues, so we should consider all possibilities/options now. Fabien _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
