BView: Fix destruction order of layout items.

Because of the virtual hooks a BLayout must never be destroyed while it
still has layout items. If these items are only removed from the layout
in its destructor, the subclass version of hooks like ItemRemoved() are
not called anymore. This lead to leaks because many BLayout subclasses
use the ItemRemoved() hook to clean up associated data (as is suggested
explicitly in the BLayout documentation).

In the same line of thought, a BLayoutItem must never be deleted when it
is still attached to a layout, as it similarly has virtual hooks like
DetachedFromLayout() that can not be called at this point anymore.

The destructors of BLayout and BLayoutItem now have debugger calls in
case these conditions are not met which should help to avoid
accidentally introducing such hard to debug issues.

To ensure the correct destruction order the sequence is now:

* Destroy the child views first. This cleans up their layout items while
the layout tree is still intact.
* Unset the view layout before removing layout items so it can properly
detach from the layout instead of just deleting it.

BLayoutItem: Add RemoveSelf() convenience method.

It works analoguous to BView::RemoveSelf(), i.e. it removes itself from
the parent (layout in this case) and returns whether or not it had and
was successfully removed from said parent.

Added method SetExplicitSize() for convenience.

Add FBC padding to all (I think..) of the visible Layout related classes.

Add Perform() methods to all the layout-related classes that needed them.

Add BLayoutItem::LayoutInvalidated() hook. Leave BLayoutItem::InvalidateLayout() (and therefore BLayout::InvalidateLayout()) virtual. This is needed to let BLayout override it for invalidation propagations.

Fix typo in BLayoutItem::SetLayout() which led to passing the wrong layout to the DetachedFromLayout() hook.

Fix a memory leak I introduced with my modification of BLayout::RemoveItem() and add comments so that it doesn't happen again. Also resolve some TODOs on the appropriate timing of calls to hook methods in BLayoutItem/BLayout.

User BView's layout item tracking functionality to simplify and optimize some methods in BLayout and BView.
Delete BLayout::RemoveViewRecursive() as it is no longer needed.
Add a few TODO's.

Add a BObjectList<BLayoutItem> to BView::fLayoutData that keeps track of any BLayoutItems that refer to this view that are part of a layout. BLayoutItem does the registering/deregistering of the items, and BView::Private proxies fLayoutData for us. Currently, this is not used anywhere, but there are many places where it will be used soon.

Big change deriving BLayout from BLayoutItem, and allowing viewless BLayouts.
a few highlights:
* BLayout now derives publicly from BLayoutItem
* Added BAbstractLayout class, which our layouts now derive from
* updated layout builders to avoid creating views when they don't need to
* updated layout classes
* updated AboutSystem to fix a little regression
* more details on #6407
* please tell me about any regressions, I've tried to find them all, but some
may have slipped by.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38207 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Alex Wilson as part of GSoC 2010 : Archiving of Layouted BViews hierarchy.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37433 a95241bf-73f2-0310-859d-f6bbb57e9c96

Merge from layout management branch.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18649 a95241bf-73f2-0310-859d-f6bbb57e9c96

BView: Fix destruction order of layout items.

Because of the virtual hooks a BLayout must never be destroyed while it
still has layout items. If these items are only removed from the layout
in its destructor, the subclass version of hooks like ItemRemoved() are
not called anymore. This lead to leaks because many BLayout subclasses
use the ItemRemoved() hook to clean up associated data (as is suggested
explicitly in the BLayout documentation).

In the same line of thought, a BLayoutItem must never be deleted when it
is still attached to a layout, as it similarly has virtual hooks like
DetachedFromLayout() that can not be called at this point anymore.

The destructors of BLayout and BLayoutItem now have debugger calls in
case these conditions are not met which should help to avoid
accidentally introducing such hard to debug issues.

To ensure the correct destruction order the sequence is now:

* Destroy the child views first. This cleans up their layout items while
the layout tree is still intact.
* Unset the view layout before removing layout items so it can properly
detach from the layout instead of just deleting it.

BLayoutItem: Add RemoveSelf() convenience method.

It works analoguous to BView::RemoveSelf(), i.e. it removes itself from
the parent (layout in this case) and returns whether or not it had and
was successfully removed from said parent.

Added method SetExplicitSize() for convenience.

Add FBC padding to all (I think..) of the visible Layout related classes.

Add Perform() methods to all the layout-related classes that needed them.

Add BLayoutItem::LayoutInvalidated() hook. Leave BLayoutItem::InvalidateLayout() (and therefore BLayout::InvalidateLayout()) virtual. This is needed to let BLayout override it for invalidation propagations.

Fix typo in BLayoutItem::SetLayout() which led to passing the wrong layout to the DetachedFromLayout() hook.

Fix a memory leak I introduced with my modification of BLayout::RemoveItem() and add comments so that it doesn't happen again. Also resolve some TODOs on the appropriate timing of calls to hook methods in BLayoutItem/BLayout.

User BView's layout item tracking functionality to simplify and optimize some methods in BLayout and BView.
Delete BLayout::RemoveViewRecursive() as it is no longer needed.
Add a few TODO's.

Add a BObjectList<BLayoutItem> to BView::fLayoutData that keeps track of any BLayoutItems that refer to this view that are part of a layout. BLayoutItem does the registering/deregistering of the items, and BView::Private proxies fLayoutData for us. Currently, this is not used anywhere, but there are many places where it will be used soon.

Big change deriving BLayout from BLayoutItem, and allowing viewless BLayouts.
a few highlights:
* BLayout now derives publicly from BLayoutItem
* Added BAbstractLayout class, which our layouts now derive from
* updated layout builders to avoid creating views when they don't need to
* updated layout classes
* updated AboutSystem to fix a little regression
* more details on #6407
* please tell me about any regressions, I've tried to find them all, but some
may have slipped by.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38207 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Alex Wilson as part of GSoC 2010 : Archiving of Layouted BViews hierarchy.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37433 a95241bf-73f2-0310-859d-f6bbb57e9c96

Merge from layout management branch.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18649 a95241bf-73f2-0310-859d-f6bbb57e9c96