[API REVIEW] RT-30576 Parent : add new public layout method, optimized to only layout this parent and it's children.

[Richard Bair]

On May 28, 2013, at 2:47 PM, Tom Schindl <tom.schindl at bestsolution.at> wrote:

> On 28.05.13 19:11, Richard Bair wrote:
>> Thanks for the summary Jasper, I agree that we should look at this holistically.
>> 
>> I think the requestParentLayout() call is done when we don't know if the change in min/max/pref will result in an actual change in the size of the node, and therefore we don't know if it *needs* to relayout its children.
>> 
>> So for example, maybe the pref size has changed, but the node is in a StackPane, in which case its pref size changing doesn't actually matter because the size of the child is determined rather by the size of the parent.
>> 
>> I like both these names (requestParentLayout() and requestLocalLayout()). Both solutions seem important and sensible. Essentially what we're doing is making requestLayout() more fine-grained -- "I need to have layout() called, but this won't affect my parent in any way" and "I don't need my layout() called necessarily, but my size has changed in some way my parent should be informed about".
>> 
> 
> If the new methods really make requestLayout more fine grained why not expressing this by keeping the name and passing a Scope parameter which would make the API look like requestLayout(Scope)?
> 
> enum Scope {
>  LOCAL,
>  PARENT
> }

What are the pros / cons? Enums are classes so there is a greater static & dynamic cost to them over a couple of methods.

Richard