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
}
Tom
