Without having looked at every layout, it does make sense to me that LayoutBase should not need to watch children for size changes on the JS side. That's because the browser already has installed those listeners and will re-calculate the layout as needed. The SWF-side will continue to need to watch the children since there is no runtime support for layout.
Even on the JS side, some layouts still need to "visit the children". Basic needs to set position:absolute, the old VerticalLayout will set display:block. When is the right time to do that is up to the layout. childrenAdded is a good time. And even on the JS side, someone should still be allowed to write a layout that doesn't rely on CSS and needs to visit the children and watch for size changes in the children. It is true that having display objects dispatch size changing events when nobody is listening is wasteful. There might be fancier ways for us to make that more PAYG on the JS-side, but I don't think that is a priority right now. The original vision for "layoutNeeded" event is for "other scenarios". That's why there is a LayoutChangeNotifier that allows you to set a binding expression to trigger a layoutNeeded somewhere else when a component's property changes, so we don't waste as much code watching for things "just-in-case". HTH, -Alex On 5/1/17, 7:59 AM, "Peter Ent" <p...@adobe.com> wrote: >The current listeners in LayoutBase (Basic Project) are for the children >of a component. Right now, if you have a Group with 10 buttons and >VerticalLayout, and you resize one of those buttons, >LayoutBase/VerticalLayout will detect that and automatically re-run the >VerticalLayout algorithm. > >What I propose is to eliminate those event listeners on the children. So >if you resize one of the buttons you will have dispatch "layoutNeeded" on >the Group to get the VerticalLayout to reformat the Group. > >If you resize the Group, that will continue to re-run the layout. > >Another example is FirstFlexibleChildHorizontalLayout (or whatever that's >called). If you delete that first child, the layout will not run. My >change will not affect this situation - you must still dispatch >"layoutNeeded" to get the layout to recalculate the next child as the >flexible item. On the JS side, this is crucial because this layout sets >flex-grow:1 on the first child and flex-grow:0 on the rest. When you >remove the first child, all children have flex-grow:0, so you must re-run >the layout. > >This is the inconsistency: sometimes you need to dispatch "layoutNeeded" >and sometimes you do not. I propose you always dispatch "layoutNeeded" >whenever you add a child, remove a child, resize a child, or do anything >that would require the layout to run. > >‹peter > >On 5/1/17, 10:27 AM, "piotrz" <piotrzarzyck...@gmail.com> wrote: > >>Hi Peter, >> >>It look like we have partially implemented "layoutNeeded". >> >>Your suggestion in #1 - is to completely remove current listeners which >>are >>dispatch "layoutNeeded". - Am I understand correctly ? - So if I will add >>children later - those will resize itself, but in order to correct parent >>resizing it will need to dispatch "layoutNeeded" ? Am I understand >>correctly >>? >> >>In case of #2 and #3 - I think both cases are good for express >>components, >>but Option #3 seems to me to complicated in case of later usage. >> >>Piotr >> >> >> >>----- >>Apache Flex PMC >>piotrzarzyck...@gmail.com >>-- >>View this message in context: >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl >>e >>x-development.2333347.n4.nabble.com%2FFlexJS-Layout-Issue-Change-tp61440p >>6 >>1442.html&data=02%7C01%7C%7C3f4bcd255fbb43120cbc08d4909fcd58%7Cfa7b1b5a7b >>3 >>4438794aed2c178decee1%7C0%7C0%7C636292463395237341&sdata=stp%2Fct7tHsUCkn >>8 >>X5ZeFclHxbyIal3vC%2F5KUoRYin4Y%3D&reserved=0 >>Sent from the Apache Flex Development mailing list archive at Nabble.com. >
