[haiku-development] Re: BBox and layout
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 10 May 2012 15:14:21 +0200
On 2012-05-10 at 12:33:08 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
wrote:
> On Thu, 10 May 2012 13:02:47 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> >> How would you solve that BBox problem?
> > I think it's mainly a question of how you want to see BBox:
> > 1. As a labeled frame for some container. It would have two child layout
> > items: the frame label and the content. The API would provide setters
> > for both (there's already SetLabel(), SetContent() would need to be
> > added) and BBox would lay them out. The content item would be laid out
> > to either fit the frame tightly -- the creator of the item would have to
> > make sure that it has pleasant insets itself -- or already with
> > additional default insets -- the creator of the item would (usually)
> > give it zero insets. In the latter case BBox should have a setter to
> > override the default insets.
> > 2. As a container with a frame. It would have a regular layout which
> > manages children as usual plus a separate frame label item which doesn't
> > belong to the layout and is laid out by BBox directly. Furthermore BBox
> > sets the insets on the layout to fit the frame -- as in option 1 either
> > tightly or with
>
> ok that are basically the ideas Alex and I came up with as well. Point 2.
> is a bit tricky because you could easily overwrite the automatically set
> inset:
>
> BLayout* layout = new BGroupLayout();
> box->SetLayout(layout);
> // sets the content area offset
> layout->SetInset(..);
> // overwrites the offset again
>
> So this would goes wrong quite often because you can't expect developers
> keeping the order when to call SetLayout.
It can go wrong, but particularly with the default insets I would challenge
that it happens very often. I think in most cases people wouldn't meddle
with the insets at all. It's not possible to prevent people from using the
API incorectly in either case.
> 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).
> Point 1. should work fine but from my own experience I would just try to
> call SetLayout on the BBox to set the layout in the content area. That
> would result in a messed up BBox.
Again, we cannot always prevent people from using the API incorrectly.
Particularly when they don't manage to RTFM. :-)
> 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.
> 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.
> I can also imagine some other use-cases for BView::SetInset but back to
> BBox: It would solves the problem I pointed out for solution 2. the BView
> inset would place the layout tightly in the content area. The layout inset
> can be used to further positioning the layout in the content area.
> Following the principle "make common tasks easy but rare tasks possible"
> it also solves the problem from 1. where a content layout bigger than the
> content area is not possible. Here one could mess with BBox::SetInset to
> resize the content layout.
I think it is possible in all proposed solutions.
CU, Ingo
Other related posts:
