Greg and others,
I've seen some problems with Fl_Tree and included widgets with
the tree demo program. There may be an inconsistency or something
that needs clarification and documentation.
Let me express it in a short question: Who "owns" the widgets
added to an Fl_Tree by calling Fl_Tree_Item::widget(Fl_Widget *)?
You can see the problem with the test/tree demo program. If you
clear a tree item while it (and thus its widget) is shown, then
the widget stays at its current position forever.
Example 1: start test/tree, select the line with "ccc button"
or "D1" and "D2", and click "Clear Selected". The buttons stay
where they are and are drawn over the tree items, whatever you
do with the tree.
Example 2: start test/tree (or use "Rebuild Tree" after Example 1),
click on "Load Database..." [great new function, added by Matt -
thanks, BTW.), and select a .prefs file or the fltk.db file in the
root directory. The effect is the same as in Example 1. This doesn't
happen if you close the "Bbb" item before loading the database (and
thus hide the button widgets/groups).
What happens? Fl_Tree is derived from Fl_Group, and it seems to
require that the widgets are added to the group [1] to be drawn
correctly, but Fl_Tree_Item::clear() doesn't remove the widgets
from the group. If they are currently shown, then they can't be
modified anymore, and thus they stay on top wherever they are
currently displayed.
The tree demo program saves internal widget pointers to allocate
the widgets only once, but doesn't hide them when the associated
items are cleared (deleted from the tree). The tree demo also
uses tree->begin() and tree->end() [2] in RebuildTree() to add the
widgets explicitly to the tree.
Wouldn't it be useful to make the Fl_Tree_Item "own" the widget and
let it delete the widget when the item is deleted from the tree?
Note that Fl_Tree's destructor *would* delete all associated
widgets since they are Fl_Tree's children().
The documentation doesn't say anything about the handling of associated
widgets, and the Fl_Tree_Item::widget() method simply overwrites the
internal _widget member variable. At least it could implicitly call
Fl_Group::add() and Fl_Group::remove() to add and remove the current
and/or the replaced widget to/from the group, resp.. This would also
simplify the user code.
I can see primarily two solutions:
(A) Fl_Tree "owns" the widgets and deletes them together with the
owning Fl_Tree_Items, or
(B) Fl_Tree adds and removes associated widgets from the Fl_Tree
group as appropriate (in Fl_Tree_Item::widget()), and lets
the user program own (and thus delete the widgets, whenever
necessary).
I would probably prefer solution B, but I'd like to read your
comments. Note that I didn't use Fl_Tree myself, and the optimal
solution would be depending on the usage scenarios. Maybe...
Albrecht
----------------------------------------------
[1] this is not mentioned in the docs as well
[2] the latter is questionable anyway, since tree->end() is equivalent
to Fl_Group::current(tree->parent()), which might not be intended here.
It's correct in the initialization phase, but can be problematic in
the button callback. An additional Fl_Group::current(0) or saving and
restoring Fl_Group::current() would be better in the callback.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
