>> > 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 ?

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...
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().

What I don't like in the current impl. is that it is like a "rubber" to 
legalize the kludges of some widgets.

It is for me a non sense for a widget not capable of handling children() to be 
the target of other children.

My proposal offers a complete orthogonality in the api while providing your 
needs without being too short-sighted for next implementations.

Fabien.



_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to