On 2011-09-03 at 16:59:32 [+0200], Stephan Assmus<superstippi@xxxxxx> wrote:
Hi,
Am 03.09.2011 15:28, schrieb pulkomandy@xxxxxxxxxxxxxxxxx:
In Haiku, sibling views are drawn one after the other, bottom-to-top. The
input dispatching is done in the same order, bottom-to-top.
It is an "invalid" layout to have overlapping sibling views. I think it
is documented in the BeBook that this results in undefined behavior. So
the implementation should (IMHO) be free to ignore this case and just
work as efficiently as is possible then.
From AddChild documentation :
"AddChild() makes aView a child of the BView, provided that aView doesn't
already have a parent. The new child is added to the BView's list of
children immediately before the named sibling BView. If the sibling is NULL
(as it is by default), aView isn't added in front of any other view—in other
words, it's added to the end of the list. If the BView is attached to a
window, aView and all its descendants become attached to the same window.
Each of them is notified of this change through AttachedToWindow() and
AllAttached() function calls."
So, we have a parameter in AddChild for setting the position in the list,
and there is a nothion of "front" here. It's rather interesting to have this
(and it clearly shows the feature was planned), but no way to make use of it
?
The interface kit introduction, however, says the drawing and event
distribution order are undeterminate. But to me, that sounds like a bug more
than anything else. I think it's worth storing fLastChild in BView to get
support for it. The sibling list is already doubly linked, so we're almost
there...
