On 04/12/12 09:21, Domingo Alvarez Duarte wrote:
> Fl_Tree_items are not lightweight text nodes they basically duplicate
> several data members of Fl_Widget so when we add an widget to it we have
> basically two widgets to use one right now.
I think the reason Fl_Browser (and by extension, Fl_Tree)
uses internal items that specifically /don't/ derive from Fl_Widget
is to avoid impacting the default FLTK event delivery mechanism.
Fl_Tree can (perhaps) do a better job of event management
if it manages items itself, without having each item be
a widget with its own potential handle() for events.
IIRC, creating instances of Fl_Widget impacts the widget stack
used for event delivery. So when FLTK events are delivered
to the parent group, the group's entire child array is considered.
Having Fl_Tree/Fl_Browser manage native items by itself
should allow it to more efficiently manage events without
having to worry about having separate handle()ers for
each item (as one would with Fl_Widget).
I am assuming the wisdom behind why Fl_Browser was designed
the way it was still stands, as Fl_Tree is implemented similarly.
But perhaps it's possible to reimplement Fl_Tree_Item to derive
from Fl_Widget (or Fl_Group) in such a way it can still be
optimized when used in the default case of a list of text items.
Perhaps you or Matt can envision a way where Fl_Tree_Item
can derive from Fl_Widget/Fl_Group in such a way that it
can be low impact on the event stack when used as a simple
text item (the common design case), but can easily be repurposed
as a general FLTK widget such that the memory impact is kept
minimal.
As it is, it's true that if every item in the tree is assigned
an Fl_Widget, then much of the items' values are redundant to
the Fl_Widget's own values.
In the current case, if each item were in fact an Fl_Button,
you'd have:
Fl_Tree
|
|--> Fl_Tree_Item -> Fl_Button
|--> Fl_Tree_Item -> Fl_Button
|--> Fl_Tree_Item -> Fl_Button
..whereas if Fl_Tree_Item derived from Fl_Widget, then you
could probably create something more memory frugal, such as:
Fl_Tree
|
|--> Fl_Tree_Item::Fl_Button
|--> Fl_Tree_Item::Fl_Button
|--> Fl_Tree_Item::Fl_Button
..where the item's xywh values are also Fl_Button's.
Thing is, I don't know how to wedge Fl_Tree_Item's
data in there if you do that; the tree needs each
item to have e.g. an open/close state to manage the
tree properly, so I'm not sure how you'd redefine
the array of Fl_Tree_Items to instead be an array
of Fl_Tree_Items that also inherit Fl_Button.
AFAIK, that's a bit tricky to do in C++ in a way that's
compatible with the lowest common denominator platforms
we support, and I'm not even sure I know how to do that
in C++, without having to derive from Fl_Tree first,
and redefine the array.. which seems kinda complicated.
As it is, you can just add widgets without deriving a special
class around Fl_Tree.
Input welcome though..
_______________________________________________
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
