Re: [FlexJS] Layout Issue/Change
On 5/2/17, 5:54 AM, "Peter Ent" wrote: >Plus, there is no provision in the base layout for watching for new >children or removed children. In the PAYG world, those feature would be >part of other layouts: > >HorizontalLayoutWatchForAddChild >HorizontalLayoutWatchForRemoveChild >HorizontalLayoutWatchForAddAndRemoveChild This is theoretically true, but in reality, because we have to listen for children being added at startup time, all you need to offer as an option is the watching for remove. > >Here's the catch: going back to the HorizontalLayout, if you remove a >child, the browser will automatically reposition the children to close the >space left by the child removed. You do not need to write a specialty >layout to do. So for HorizontalLayout, do we including watching for >children added and removed because it mimics the browser or is it really a >specialty? IMO, it isn't "specialty", it is PAYG. We don't want to only offer fully-implemented browser support. It would be too big and slow and take us a long time to write and test. Many apps can be written without removing a child, so that is an option for our customers. Basic should offer those choices, Express can default to the fattest, slowest, feature-rich thing that still makes us look good. > >Right now, the event listeners watching for changes in the children are >multi-platform. A better, more PAYG approach (I think), is to make those >event listeners SWF-side only and they should be part of the layouts that >actually need them to mimic what the browser can do. IMO, LayoutBase on the SWF-side could always implement size change listeners since it would be hard to write a layout without out. > >So perhaps that best thing to do now is wait for FlexJS 0.9 and try this >out an another branch to determine what the procedure should be. I think we have until the end of the week to finish features. Next week should be all bug fixing, and the following week will hopefully be the one vote thread so we can get the release on the mirrors and have it propagate before the Summit. I don't have an opinion on whether this work should be done before the release or not. -Alex
Re: [FlexJS] Layout Issue/Change
I'm trying to find the balance between PAYG and mimicking the HTML/JS/CSS side on the SWF side. Take HorizontalLayout for example. On the JS side, this layout waits for "childrenAdded" and then changes each child's display style to "inline-block". If you then programmatically change one child's width, the browser automatically pushes the children apart to make room. Since the Flash Player does not have that capability, the HorizontalLayout, SWF version, must watch for changes in the size of the children and re-run the layout. This is the mimicking part. I put the children size watching into the LayoutBase, thinking it was a common enough, frequent enough process that it could be done in the base class. But that really is not the case. Each layout is different. Plus, there is no provision in the base layout for watching for new children or removed children. In the PAYG world, those feature would be part of other layouts: HorizontalLayoutWatchForAddChild HorizontalLayoutWatchForRemoveChild HorizontalLayoutWatchForAddAndRemoveChild Here's the catch: going back to the HorizontalLayout, if you remove a child, the browser will automatically reposition the children to close the space left by the child removed. You do not need to write a specialty layout to do. So for HorizontalLayout, do we including watching for children added and removed because it mimics the browser or is it really a specialty? Right now, the event listeners watching for changes in the children are multi-platform. A better, more PAYG approach (I think), is to make those event listeners SWF-side only and they should be part of the layouts that actually need them to mimic what the browser can do. So perhaps that best thing to do now is wait for FlexJS 0.9 and try this out an another branch to determine what the procedure should be. ‹peter On 5/2/17, 2:52 AM, "piotrz" wrote: >Understand. It is not bad changes in terms of complex layout. >I think this changes need to be done on feature branch. I would like to >test >it and see how it affects current examples. > >Piotr > > > >- >Apache Flex PMC >piotrzarzyck...@gmail.com >-- >View this message in context: >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle >x-development.247.n4.nabble.com%2FFlexJS-Layout-Issue-Change-tp61440p6 >1459.html&data=02%7C01%7C%7Ce012b30ad5354126a6a908d491297b5e%7Cfa7b1b5a7b3 >4438794aed2c178decee1%7C0%7C0%7C636293054727198273&sdata=2NhFc2LDt8sTFE17K >Ylnjms1oE6YvbWo6lFVcolThHk%3D&reserved=0 >Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layout Issue/Change
Understand. It is not bad changes in terms of complex layout. I think this changes need to be done on feature branch. I would like to test it and see how it affects current examples. Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-Layout-Issue-Change-tp61440p61459.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layout Issue/Change
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" 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" 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.247.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. >
Re: [FlexJS] Layout Issue/Change
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" 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-fle >x-development.247.n4.nabble.com%2FFlexJS-Layout-Issue-Change-tp61440p6 >1442.html&data=02%7C01%7C%7C3f4bcd255fbb43120cbc08d4909fcd58%7Cfa7b1b5a7b3 >4438794aed2c178decee1%7C0%7C0%7C636292463395237341&sdata=stp%2Fct7tHsUCkn8 >X5ZeFclHxbyIal3vC%2F5KUoRYin4Y%3D&reserved=0 >Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layout Issue/Change
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: http://apache-flex-development.247.n4.nabble.com/FlexJS-Layout-Issue-Change-tp61440p61442.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
