Fabien Costantini wrote: >>>> A composite permits tree walking without having to distinguish groups from >>>> leaves, the latter one having no child as the main difference. >> 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. > 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. > > 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 you, too. But take it as a kind of an adoption ;-) I only proposed this, because FLTK can by design send events to any widget, be it a group or not, if it is a child of another group. This widget can send the event to its private children as it likes, but setting the private child widget to be the pushed() or belowmouse() widget fails because of the missing parent back pointer (contains() fails). If we could implement this differently, we would be done without my parent() change, but I didn't see an easy solution. > 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. No, my proposal is not short sighted, it is a logical extension and would not contradict your suggested extension. Maybe we could do both ? Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
