Hi All, Seems like we have 3 use cases:
requestLayout() - my layout and/or my size has changed - action relayout myself and all parents requestParentLayout() - my size has changed only - layout my parents requestLocalLayout() - something requiring my children to be relayed out has happened but there is no change in my pref size - just mark this node dirty for layout next pulse 3) is a optimization for preventing excessive layout that makes sense. 2) I am not sure when this can happen. When can a region's size change without is children needing to be laid out? Or have I miss understood what it does? Seems like we should look at all these extensions to layout API as one. Jasper On May 22, 2013, at 8:15 AM, mick.fleming <mick.flem...@oracle.com> wrote: > > Hi Martin, > >> I would like to introduce similar call, see > > it's a shame about the overlap, but at least I > assume it means that we're in agreement that > something can be done here :-) > > There does seem to be a a difference between the > two. While your requestParentLayout doesn't clear > the size cache, it does go up the hierarchy. > My proposal is for a method that specifically > doesn't request a layout up the hierarchy, and > only sets the current Parent as dirty. There are > cases where it's know that the change is only local. > My change is aimed primarily at Controls and the like, > for cases where they've changed their internals, and it's > known that there is no knock-on effect. > > I have an implementation, that includes changes to > Controls, Charts and Layout to utilize it. > > > regards, > mick >
