SplitContainer: addChild(child, index) behavior changed in trunk

[liucougar]

since [29904], splitter.addChild(child, index) behaviour changes:

before [29904], index is based on children widgets in the splitter, while after [29904], the index is taking into account of all children dom nodes, even if they are not widgets.

is this intended going forward?

I think the original behaviour is the more expected one, after all the addChild function is on a widget.

(I think this behaviour change affects all containers)

[bill]

What do you mean by "splitter"? Is there some issue with BorderContainer?

In any case, addChild()'s behavior was always undefined when there were non-widget children. From the 1.8 API doc for addChild():

//	Functionality is undefined if this widget contains anything besides
//	a list of child widgets (ie, if it contains arbitrary non-widget HTML).

The change in behavior was intentional although I didn't think it would break anyone. From the checkin comment:

Modifies _Container.addChild(widget, num) to position widget as the n+1'th direct child of _Container.containerNode, even if the child widgets are not direct children of _Container.containerNode.

[liucougar]

i meant SplitterContainer?

from user's point of view, SplitterContainer? does not contains anything other than widgets. the non-widgets dom nodes are internally created by SplitterContainer? (these dom nodes are splitters)

this commit changes the meaning of the index parameter for SplitterContainer?

[bill]

Oh, you must mean SplitContainer. OK, I did not realize I had broken that, I'll fix it somehow.

[bill]

In [30251]:

Add manual tests for SplitContainer?.addChild() to 1.8 branch, to compare behavior to trunk, refs #16504.

[bill]

In [30252]:

Fix SplitContainer?.addChild() breakage from [29904]. Fixes #16504, refs #16242, #16244 !strict.