[haiku-development] Re: BBox and layout

> > cool thank! tried it but it did not work very well. I called the
> > BView::{Disable|Enable}**LayoutInvalidation() but when adding a 
> > item to
> > the layout the BView::_**InvalidateParentLayout() is called (from
> > BLayout::AddItem) which does not check if the layout invalidation 
> > is
> > disabled. Adding the check there helps though. However, 
> > additionally
> > calling BLayout::{Disable|Enable}**LayoutInvalidation() solves the
> > problem. What is the cleanest solution? and why are there flags for 
> > layout
> > invalidation in BView and BLayout shouldn't BView just use the one 
> > from
> > BLayout?
> 
> 
> BView::_InvalidateParentLayout() resides in BView mainly because it 
> needs
> access to BView stuff, and is useful even in the absence of a 
> BLayout. That
> said, it's just a convenient way to find the nearest layout and 
> invalidate
> it, regardless of where the invalidation is coming from, so it's 
> right that
> it doesn't check for invalidation being disabled.
> 
> BLayout maybe could share invalidation disabled flags with the BView, 
> when
> it is attached to one, I can't remember any specific reason why it 
> doesn't.

Ok I removed fInvalidationDisabled and BLayout::
{Disable|Enable}LayoutInvalidation() from BLayout. Think BLayout is not 
the place to decide if it triggers a relayout. This functionality is 
only in BView now. However BLayout::InvalidateLayout checks if the 
invalidation is disabled in BView. (please take a look at the 
attachment)

By the way what is the difference between fOwner and fTarget in 
BLayout?

> I don't think there's any need for any new methods. In the scenario 
> of
> using a default custom BBox layout, if a user wants full manual 
> control
> over everything in the BBox, they just use SetLayout(), if they want 
> to
> embed a layout into the BBox content area, they add it with 
> AddChild().
> This would also have the benefit of being backwards compatible with 
> current
> behaviour, meaning there's no need to rework all the layout'd BBoxes 
> in the
> repo.

Hey no backwards compatibility for beta apis! ;-) So you propose to 
leave everything as it is or do I miss something? AddChild is even more 
unusable than the current SetLayout, not only you have to calculate the 
correct inset but also the frame size and add a dummy layout container 
view!

So again, I would change the default BBox semantic of SetLayout to add 
a special BBoxLayout that has exactly one child which is the added 
layout. This layout is placed exactly in the inner BBox frame. Guess in 
99% thats what you want.

In the docs for BBox we can add: for the (unlikely) case that the 
layout should span the complete BBox frame the BView::SetLayout method 
should be called.

cheers
        Clemens

<<< application/x-be_attribute; name="BeOS Attributes": Unrecognized >>>

Other related posts: