[haiku-development] Re: BBox and layout

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 11 May 2012 09:18:57 +0200

Clemens Zeidler wrote:
> On Fri, 11 May 2012 01:14:21 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx> 
> wrote:
> >> However, BBox setter and getter
> >> for a default inset are a solution but IMHO not very intuitive...
> >
> > IMO they are. Using default values that can be changed by setters is a
> > common idiom in the interface kit/layout API (e.g. think of the default
> > spacing).
> 
> What I meant with not very intuitive is that you have to call 
> BBox::SetContentAreaInset() to set the layout inset. Normally you would 
> call BLayout::SetInset(). Furthermore, all sub-sequential calls to 
> BLayout::SetLayout ignore the BBox inset.

I don't know which case you're referring to, but in this respect the setter in 
BBox (I'd just call it SetContentInsets()) wouldn't be different from the 
setter in BView that you are favoring.

> >> Another problem occurs if you want, for
> >> whatever reasons, a content layout that is bigger than the content area.
> >> You can't do that in this solution.
> >
> > I guess you could set negative insets.
> 
> Yes right this child layout approach would definitely be a solution. 
> However, SetContentLayout compared to SetLayout makes the dev to RTFM -> 
> bad! Overwriting SetLayout and let BBox::SetLayout call _SetContentLayout 
> would be a solution here (hacky, though and would change internal 
> behaviour).

I'd call the content setter SetContent() and it would have a BView* and a 
BLayoutItem* version. If BBox is considered a frame around a content view/item, 
then such a setter will be rather obvious IMO. BBox::SetLayout() could even 
call the debugger in this case.

> >> I don't think BView::SetInset is duplicated functionality. One can see
> >> BView as a kind of a special "super layout" that holds only one child
> >> layout. From this point of view it also deserves a SetInset method like 
> >> a
> >> real BLayout.
> >
> > I can only repeat my reasoning: It would be rarely used functionality
> > (mainly for BBox, where such an API would therefore be better placed) and
> > you can easily achieve the same by nesting layouts. An additional layout 
> > is
> > cheap, so there really is nothing speaking against doing that.
> 
> Its really not a common case but it is handy for all types of container 
> views. For example, to display a layout created by an external source with 
> an intended inset. Sure, that can be solved by adding a container layout 
> with a fix inset but hmmmm don't like it.... setting the inset to BView 
> directly seems to be more straight forward.

In the end it's just about which solution one likes better I guess. I think the 
use case is not common enough that it deserves a generic API addition while at 
the same time a relatively simple solution is already available. Not that it is 
a big deal, but the addition would have to be dealt with by all layout 
implementations.

CU, Ingo

Other related posts: