[haiku-development] Re: BBox and layout

On Tue, May 8, 2012 at 9:45 PM, Clemens <clemens.zeidler@xxxxxxxxxxxxxx> wrote:
> On Wed, 09 May 2012 02:08:00 +1200, Alex Wilson <yourpalal2@xxxxxxxxx>
> wrote:
>>> 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!
>> No, in layout mode, AddChild() would nicely layout the child you add
>> into the BBox in the right place, with the right insets. The custom
>> layout would just lay out 2 things, the label, and the child (BBox
>> only allows one child sort of). If you want multiple items in the
>> BBox, you would add a nested layout using
>> BBox::AddChild(BLayoutItem*). Because BLayout is also a BLayoutItem,
>> you no longer need the dummy layout containers.
> thats definitely a solution but IMHO not a nice one. I just took a look at
> qt *) and they do it my way :-)
> Using AddChild to add a layout if there is a SetLayout method does not
> follow the principle of least astonishment either. I think its only
> astonishing for someone who knows BLayout very well that SetLayout adds a
> layout that not spans the whole BView frame.

I don't agree here. The PLA doesn't just mean everything behaves in
the simplest way, but it means that there is a conformity to the API.
If you learn what SetLayout does in x - 1 cases, the xth case should
not surprise you. If you learn that BLayout is a BLayoutItem (an easy
thing to learn if you start making complexish layouts), then it is not
surprising at all that you can embed it into another layout with
AddItem() (or AddChild() on a view).

> To go back to the discussion where Ingo wondered that the "adding to view
> adds to layout" automatism was not a wise decision. After giving it another
> thought I think it has the following advantages to remove that automatism:

I don't think completely abandoning this mechanism is the right
choice, for the reasons I have given above, and also for one more.
I've done big changes to the layout API before, and adjusting and
testing the various apps/preflets in Haiku is a big job. It's also
very boring and error-prone. I don't think I've ever caught all the
errors, thankfully people like diver on Trac seem to find the ones I

> - AddChild does not change its behaviour if there is a layout present ->
> there is no need for a B_EXCLUDE[_VIEW]_FROM_LAYOUT flag
> - AddChild can be used for "overlay" stuff like the label view in BBox
> - AddChild is just the raw base method for adding a view, no hidden
> intelligence here
> - view and layout are more decoupled, only the layout class can be used to
> add stuff into the layout -> more consistency

> - a view could be in multiple layouts (yes it is not a very common example
> (but also not totally beside the point) but it shows that it is possible
> without further effort)

I don't understand why the current auto-add behaviour prevents this.
Unless you are also planning to remove the guarantee that a BView with
a BLayoutItem in a BLayout will be a child of the BLayout's target
BView. I guess that would be doable, but it would mean that you'd need
to add every view to both the BView and the BLayout, which would be a
huge pain.


Other related posts: