01. Create a Group with percentHeight and percentWeight set to 100.
02. Configure a Tile Layout as:
03. Populate the Group with four default Buttons -- just give them labels One, Two, Three, Four.
04. Upon resize the layout seems to behave as expected -- the four equi-areas redistribute proportionately.
05. Feeling good about what I've learned in my my learning to walk before flying with Spark, I change one of the Buttons to a List and am happy that the behavior is still as expected.
05. But, this list needs its own TileLayout. As soon as I add that to the mix, the resizing/layout behavior fails. In my simple test case, the failure symptom is that the column width of column 1 now appears to remain fixed, and the column width of column 2 [with a List element replacing the Button element in that upper-right corner] just gets whatever is left over. In fact, if the window is reduced below the width of column 1, column 2 is truncated completely.
06. So, without trying lots and lots of combinations of different components with different layouts, is there some more complete explanation of 'the layout contract' than what has been written on the AsDoc page for the TileLayout class? Clearly the ability of the layout algorithm to maintain the equi-area distribution depends upon properties of the children as discussed. So, if I were assigning geometry to any of the children, I would expect complications, but here, whatever element has been placed as a child inside the Group to be layed out, it has never made any explicit request for any dimensions on any of the components. Since the problem shows up when one of the child component's own layout is Tiled, it would seem that the TileLayout class as a by-product of its calculation of internal constrants 'emits' an external resize request. But, now it sounds like I think I know what I am talking about, when clearly I don't. Any help in understanding what the rules are for maintaining "nice" tiling would be much appreciated.