On May 28, 2013, at 2:47 PM, Tom Schindl <[email protected]> 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
