Fabien Costantini wrote: > 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.
We *do* agree here, but I think that my changes are logical and useful, if not at all necessary for the functionality I addressed. But this is not the same as that what you understand as the composite aspect. Maybe my fault, because I used a misleading term, but I didn't know a better one. :-( > 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. As I wrote in the other thread, I think that this "real composite" aspect is a major rewrite of FLTK and is not doable in the FLTK 1.3 time frame. It would also have major changes in the API. So let's do it as you suggested: Here, we should discuss that "real composite aspect" (IMHO a future project for FLTK 4.0) and in the other thread my changes for a hopefully minor addition to the current FLTK features with little API and functional changes. Thanks again for your comments Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
