> > Not a major rewrite at all, here is how it could work: > > 1. Get the children() tree handling api to Fl_Widget instead of Fl_Group. > > 2. Use an API like is_leaf() that will indicate if is terminal to the > > external world or a group. > > > > Is it hard ? > > Maybe not. Especially if we don't change anything else than the children() api to widget and of course the parent() returning a widget (your and also my view)
> > > > Now the interesting part: > > We don't want all widgets to be considered as group but what we really want > > is the possibilities: > > 1. to iterate on them as with groups transparently > > 2. to "hide" a real composite widget underlying (your actual/ponctual > > need) and with all the flexibility that a group furthers. > > > > How to achieve this ? > > > > Quite simple: the is_leaf() only indicate that the widget is not intended > > to be walked in a tree. > > But in fact it is still possible inside the composite widget to handle > > children() as it wishes... > > I don't oppose this. It may be useful, too. > > > This could be called private children, though it would be still possible > > walk inside it ignoring the is_leaf flag and then simply iterate children(). > > I'm not sure, if I understand you correctly, but IMHO you didn't get the > fact that you can have both: A widget A (now: a group) can have official > children (the children() array) _and_ "private" children (the scrollbars > of Fl_Scroll, e.g.). This can't be done with a leaf property of _this_ > widget A. And that's exactly the problem I tried to solve, because per > FLTK design, event handling doesn't work correctly without entering a > child widget in the group's children() array. And this _does_ have > unwanted side effects. > > > What I don't like in the current impl. is that it is like a "rubber" to > > legalize the kludges of some widgets. > > Well, I can understand you, but I wouldn't have proposed it, if I > considered this only another kludge. This "rubber" effect is not the > primary goal - it is only a side effect. > > > It is for me a non sense for a widget not capable of handling children() to > > be the target of other children. > > You mean parent, right? Yes, this sounds crazy, and I first thought like Yes sorry, I was in a hurry but didn't want to miss the opportunity to give my insight which is so simple to achieve and so flexible while keeping the API (not ABI but it seems ok now) compatible The only side effect one could have is that now previous 1.x applications won't crash anymore when iterating with children() a Fl_Widget casted in an Fl_Group :-) > > My proposal offers a complete orthogonality in the api while providing your > > needs without being too short-sighted for next implementations. > > Yes, yours is complete orthogonal to mine. > > No, it doesn't provide "my needs". Unless you can explain, how. Your need if I understood you is to get a private children feature. IMHO this can simply be achieved by what you do now, i.e: your target parent does not now that you are its child but the child does with the parent() relation. But now we would have the possible to pass any widget to function that deals wih tree walking ... > Maybe we could do both ? Sure we can and Fl_Widget children() capabilities would simplify some fltk existing internal code too just now, so it is useful too just out of the box. > Albrecht Fabien _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
