Re: widget creation and parent assignment

Sounds cool, see my remark though
(havent checked the ideas in depth, i may get to some complains later *g*)
Darren V Hart wrote:
> Team,
> 
> The composition of widgets as been done by passing the parent of a
> widget to the widget create routine.  This has worked great so far, but
> the concerns Marc raised in the beginning are finally rearing their ugly
> faces.  Composed widgets (those consisting of more than widget, like
> scrollbox, the future combobox, etc.) currently cannot be built
> correctly as their is know way to assign the parent of a widget after it
> has been constructed.
> 
> I propose the following modifications to libstk:
> 
> 1) we add another create routine for every widget which does not take a
> parent pointer.  When using this routine, users are reponsible for
> composition, ie they must call my_scrollbox->add(my_widget) on their
> own.  Typically users will not use this approach, but it will be nice to
> have the option, it will be used by the library in all composite
> widgets.
> 
> 2) add a parent(container::ptr new_parent) routine to widget which
> allows for the explicit setting of the parent_ member after
> construction.
> 
> 3) remove the parent pointer assignment from the widget constructors and
> move it into the container::add(widget::ptr item) routine.  Whenever it
> is called it checks if item has a parent, if so, tell the parent to
> remove the item, add the item to itself, and sets the items parent to
> itself.
Imnsho this should be done by the widget's parent function, (remove the 
old container, add the new one). Then we catch to flies at once, the 
user can the move widgets from one parent to another one, this makes the 
widget tree much more dynamic (i have a few uses for this!)
> 
> Thoughts / objections / flames?
> 
> Darren