Albrecht Schlosser wrote:
> 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 *)?
The base class Fl_Group (that Fl_Tree derives from) manages
all FLTK widgets added to the tree, meaning its the 'parent'.
But it's true that once the association is made with item->widget(),
the items should then 'own' it to the extent that the item's
destructor should tell the Fl_Group to remove it. Should be relatively
easy to add that.
I suppose as well, Fl_Tree should have some methods that trap any
of Fl_Group's base class methods that manage child widgets
(like Fl_Group::remove()) so that any caller trying to manipulate
FLTK widgets that way get cleared from the tree to avoid any
dangling pointers.
Glad to see the new widgets are getting the peer review they've needed.
I see myself as an applications programmer, not a core widget developer;
I don't really know the FLTK API at the microscopic depth nor have the
forward vision one should to write core widget APIs, especially with
complex grouping widgets like Tables + Trees.
Of course I get closer with every widget I make, but designing core
widgets is not something I'd ever aspired to -- "necessity is the mother
of all invention" and all that. I just wrote what I needed and
offered it up, with the hopes I'd get some constructive feedback
on how to make the widgets better.
Fl_Tree itself is relatively new, and I'm glad to see it's getting
the peer review it has needed ;) The others could use this as well.
(Fl_Table, FNFC..)
> 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]]
Right; I think some extra code added to the Fl_Tree_Item
destructor can take care of that. It's basically an omission.
Currently the destructor just NULLs out the widget() instead
of telling the parent group to remove it.
I'll see about adding that.
> Example 2: start test/tree (or use "Rebuild Tree" after Example 1),
> click on "Load Database..." [great new function, added by Matt -
> thanks, BTW.),
Hmm, I don't seem to see this 'Load Database' function.
I'm looking at r7658?
Sun 07/11/10 10:22:29 /usr/local/src/fltk-1.3.x-svn-latest/test
[r...@tahoe] ## ROOT ## 11 # svnversion
7658
Sun 07/11/10 10:22:06 /usr/local/src/fltk-1.3.x-svn-latest/test
[r...@tahoe] ## ROOT ## 12 # svn diff tree.cxx tree.fl
Sun 07/11/10 10:22:16 /usr/local/src/fltk-1.3.x-svn-latest/test
[r...@tahoe] ## ROOT ## 13 # grep -i 'load database' *
> [1] this is not mentioned in the docs as well
Yes, the Fl_Tree docs should probably have a section that describes
how to manage FLTK widgets as children of the tree from a conceptual
point of view.
Having FLTK widgets be children of the widget was an afterthought,
but seemed easy enough to add. It's just not fully fleshed out.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
