On 04/12/12 07:04, Matthias Melcher wrote:
> For FLTK3, Fl_tree should be a specialized group and Fl_Tree_Item
> should be any possible widget, including a Group. If done correctly,
> this will keep Fl_Tree in line with the hierarchical design of FLTK. Greg,
> what do you think?
I think it already does, but perhaps I'm missing something.
Fl_Tree is currently a specialized group that manages
a hierarchical list of Fl_Tree_Items, each item by default
being a lightweight text item, but each can optionally
be assigned an Fl_Widget (including an Fl_Group).
The goal of Fl_Tree (current implementation) was to reinvent
Fl_Browser to be hierarchical, and to also be able to assign
FLTK widgets to the items.
To add Fl_Widgets to items, you first assign them to Fl_Tree
as you would an Fl_Group or Fl_Scroll (with begin() and end()).
You then assign the widget's pointer to an Fl_Tree_Item, and
the tree will then manage its xywh position to track that item.
So I think it rides that fine line between being a general
widget container, and being a specialized widget at handling
large lists of lightweight text.
Not sure how to improve on that; but perhaps it can.
What it surely needs:
o Some final optimizations (hardest stuff was done I think)
o Full support of FLTK widgets (like keynav of the focusbox)
o Extendability (ie. provide for inheritance)
Regarding extendability, for instance, I don't think I made methods
virtual, and wasn't really sure what features one might want to
provide by deriving from Fl_Tree. I figured I had to make it first,
then see what people did with it to find out what needed to be
virtual, and what needed to be protected vs. private, etc.
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
