[haiku-development] Re: BBox and layout
- From: clemens.zeidler@xxxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 08 May 2012 15:42:46 +1200
> > 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:
