> I'm working on a change that Fl_Scroll would not have its scrollbars > as children in its Fl_Group - IMO a _valuable_ change. But OTOH this > could affect user code, where someone relies an these two additional > children of the group. > > BTW: There's a working version that you can check out at: > > <http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3-composite> > > Please read the CHANGES.branch file for more info. Feedback would be > welcome. For Fl_Scroll, I read what you propose and I'm 100% favorable to the modification.
Then, I had a look to the modifications concerning the composite aspect. and had a look to the sources. This is not what I would call a composite because it seems to lack 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 we will have 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
