Long day... I stepped away from the keyboard and thought I had finished that when I returned. But this: ' although I know it's not a ' needs ''one:one mapping for features/behavior" on the end (or something like that!)
On Sat, Jun 6, 2020 at 7:13 PM Greg Dove <[email protected]> wrote: > > Yeah, that is the sort of thinking that I was trying to make work with > what is there already (and yes it does seem like maybe something else is > missing). Apart from simple size changes, it is the change on measuredSize > after layout has happened in the child that I think some parents *might* be > interested in when their children are containers with percent dimensions > ('flexible' children I think is how they are described in some Flex code - > this sort of makes me think of css Flexbox a bit when I look at what the > BoxLayout stuff is doing, although I know it's not a ). > But I am probably only scratching the surface here, you have the > experience with this stuff. > In terms of plumbing, one thing I pondered about would be whether MXRoyale > layouts could form their own tree where they connect/detach directly to > eachother as part of addChild/removeChild so that it is almost like a tree > in parallel with the display tree. > Maybe that could be a structure where they talk to each other directly up > and down the tree with measurement and layout order somehow optimized. I > think it still would not be as efficient as using the 'temporal buffer' of > the Flex life cycle, with enterFrame or with 'requestAnimationFrame' but > maybe it could be a little better... not sure, was just a thought and I > know it seems like a radical change, so maybe that alone rules it out. > > I was going to drop another zip into the github issue. It occurred to me > that it might be easier for you to test if I just put the changed files > into the test app fileset as a monkey patch. That way you can mess with > them locally more easily if you want to make quick changes and retest, > without recompiling MXRoyale. (I was doing this a bit with GridItem/GridRow > today in the app I am working on, where I have the monkey patch approach > and it's quite a bit faster when testing changes). > > A little aside: one other thing I think I noticed today... I think mx > Image has a 'layoutNeeded' dispatch on image load. That makes sense. But I > think I saw that it is a bubbling event. Is that correct? Would this call > layoutNeeded all the way up to SystemManager for a deeply nested Image (I > did not check if it does yet)? > > Thanks again for looking at this. If I can help by creating more test > cases or looking into anything specific in more detail, let me know. > Greg > > > > > > > > On Sat, Jun 6, 2020 at 6:30 PM Alex Harui <[email protected]> > wrote: > >> I hope to have time tomorrow. >> >> Looking quickly at the things you've tried to fix the problem, it occurs >> to me that the piece that is probably missing in MXRoyale is the >> propagation of something like invalidateSize() instead of just >> "layoutNeeded". My thinking is that in the general case the child can't >> really know that because something about the child changed that the parent >> needs to run a new layout and especially the parent of that parent. >> >> So some new plumbing may be needed where, when a component changes in a >> way that its measured or explicit size had changed (as opposed to the size >> change from the parent laying out the child), that some sort of >> layoutMightBeNeeded is sent to the parent which then uses its measurement >> code and explicit sizes to determine whether its size has changed and >> propagates a layoutMightBeNeeded to its parent. But if it decides its size >> has not changed, it would then run layout which should start the parents >> laying out children. >> >> We'll see if the test case points in that direction. >> >> HTH, >> -Alex >> >> On 6/5/20, 3:05 AM, "Greg Dove" <[email protected]> wrote: >> >> Hi Alex, thanks for the detailed explanation and offer to take a >> look, for >> now some quick replies inline.... please add questions in the github >> issue >> if you want more details about anything I did so far. >> thanks >> Greg >> >> On Fri, Jun 5, 2020 at 6:50 PM Alex Harui <[email protected]> >> wrote: >> >> > Greg, >> > >> > I think this thread got forked somehow. If you have a simple test >> case I >> > can try to look at it this weekend. >> > >> > Thanks. I added issue #849 [1] which should give you something to >> look at. >> I suggest you open the Flex build in a browser and then compare >> things to >> it in Royale. There are 2 royale builds as well with the same code in >> the >> other 2 zips. One without the modifications to MXRoyale and one with. >> The >> 'one with' zip also has the modified MXRoyale files, so you should be >> able >> to drop them in and overwrite in your local MXRoyale and build to >> test/review/change what I did. I'm the first to admit that I do think >> it >> doesn't feel right. But so far at least it does make a bunch of code >> work >> in one app with a lot of deeply nested layouts that was not working >> before. >> It certainly does not make everything work. But it helps quite a bit. >> Certainly appreciate any review/consideration. I am really keen to >> collaborate on a solution that makes sense for most here. >> >> I don't doubt that the changes you propose work for you, but they >> make me >> > nervous although I'm not the best at reading code and understanding >> what it >> > does. Here's a brain dump on layout in case it helps. >> > >> > So far they work better 'for me' I agree. But I think you probably >> know me >> enough by now to know that if I am confident that I have a >> contribution >> that is objectively good (passes unit tests compared with swf is my >> normal >> benchmark) then I will add it. Part of the reason I started this >> discussion >> is because I feel a bit the same way here. I am still learning this >> stuff >> and figuring things out, so I am not pushing it because I don't want >> to >> inflict anything that is not an objective improvement on others. >> >> In terms of describing it, the main thing I think, is that the view >> checks >> when layout happens if there was a size change since last time layout >> ran, >> or if there was a change in size during the current run. Then there >> is some >> somewhat awkward checking to see if the parent might be interested in >> this >> because there is some 'sizedToContent' aspect to it (which includes a >> percentage variation on that check). If we think it is relevant, then >> request the parent to layout. Is this likely to do it sometimes when >> it is >> not needed, I suspect so. But so far it has not caused any problems >> in the >> codebase I am working with. >> >> I'm also working on the Grid related stuff, but you could probably >> just >> ignore that for now and focus only on the BoxLayout stuff. >> >> In Flex, parents always size their children. The children probably >> > shouldn't override that size or if they do they have to be careful >> that it >> > doesn't trigger the another layout in the parent in a way that you >> run >> > layout forever (a "layout loop"). In Flex, because of the >> LayoutManager >> > running on frame events, that generally doesn't freeze the UI and I >> have >> > seen situations where the LayoutManager never goes idle even though >> the app >> > appears to be running fine. There is also the case where the first >> layout >> > pass results in scrollbars which causes children to adjust and >> results in >> > the removal of scrollbars and that loops forever with the scrollbars >> > blinking on and off. In Royale, there is a greater chance of >> hanging. >> > >> > Also in Flex, with the LayoutManager, EVERY widget added itself to >> the >> > LayoutManager ensuring validation in a particular order, enforcing >> the >> > "parents size children" rule. >> > >> > In Royale, I tried to go without a LayoutManager because we started >> out >> > targeting IE8 and I wasn’t sure if there were some things that were >> > exceptions to requestAnimationFrame (like setting text or sizing >> images). >> > To this day, I'm concerned that it will create an poor debugging >> experience >> > because I think when you hit breakpoints the screen updates. All >> of those >> > things need testing before we try a LayoutManager based on >> > requestAnimationFrame. And then, as I think you mentioned, we have >> to be >> > concerned about how much code is going to run if we start running >> all of >> > the validation methods. >> > >> > On the other hand, I think Royale runs layout too often still >> because two >> > property changes can trigger two layout passes. I looked at >> BoxLayout >> > which extends LayoutBase which does already watch for >> > widthChanged/heightChanged/sizeChanged so whatever is the root >> cause of >> > your problem may not be triggering the layout pass you want, >> although the >> > code paths in LayoutBase.childResizeHandler are there to prevent >> layout >> > loops. >> > >> > Usually, in Flex, a component didn't change its size in response to >> user >> > interaction or data loading, it changed its measured size and called >> > invalidateSize on itself and its parent. The LayoutManager measured >> > children before parents, then layed out parents before children. >> > >> > Yeah, that's the vague notion I had, your explanation has helped >> cement my >> understanding. >> >> >> > In Royale, there is little to no measurement subsystem. That's >> because we >> > rely on the browser to "immediately" measure by setting >> > offsetWidth/offsetHeight saving us the impossible task of writing >> code to >> > guess at how the browser measures. For PAYG reasons in Basic, >> there is no >> > code looking for changes that should trigger a layout other than >> possibly >> > child size changes. Everything else is supposed to use >> > LayoutChangeNotifier to wire the one event that signals a change to >> the >> > container/layout that cares. >> >> In MXRoyale, there are complex components that can't rely on >> > offsetWidth/Height since MXRoyale cannot rely on browser layout >> because of >> > things like overriding the meaning of width=100%. MXRoyale has >> measure() >> > methods from Flex, but they don't always get run because there is no >> > LayoutManager measuring the children before the parents and existing >> > measure() methods expect the children to have been measured. It >> might be >> > that is the root cause here. That some or all invalidateSize() >> calls need >> > to call measure() and then instead of calling layoutNeeded on the >> parent, >> > call the parent's invalidateSize until somehow we know we've gone >> far >> > enough up the chain to start laying out again. >> > >> > After the changes I made I do still need to make changes in some >> specific >> areas, but usually this type of thing does the trick: >> >> var layout:BoxLayout = >> containerContents.getBeadByType(BoxLayout) as BoxLayout; >> if (layout) { >> layout.measure(); >> } >> containerContents.layoutNeeded(); >> >> Note: calling measure() explicitly like that with BoxLayout seems to >> be >> necessary sometimes before an explicit layout request. It might only >> work >> more after the changes I made, not sure whether it makes a difference >> before or not. >> >> >> > HTH, >> > -Alex >> > >> > >> > On 6/4/20, 1:51 PM, "Greg Dove" <[email protected]> wrote: >> > >> > 'I don’t think we’ve dealt with a lot of children changing >> sizes (other >> > than Images loading late and a few other things) so it may be >> time to >> > listen to widthChanged/heightChanged/sizeChanged as children >> get added >> > if >> > there isn’t already code doing that.' >> > >> > That would be another way of doing it. There is already this >> code [1] >> > that >> > is swf-only but seems to only be relevant before >> sawInitComplete. >> > >> > But if the children run their layouts when their own size >> changes, then >> > they can notify their parent as well if the size changed either >> before >> > or >> > during layout. That's sort of what I was trying to do with the >> > ContainerView change I mentioned earlier. It checks size for >> change in >> > beforeLayout and again in afterLayout and then requests parent >> layout >> > if it >> > thinks the parent needs to do something that could affect parent >> > layout or >> > even re-apply its own rules to the current target. In this way >> there >> > is not >> > a need to add listeners to every child. But I expect there are >> some >> > downsides or things I cannot see with what I did so far because >> I have >> > not >> > spent a lot of time in this code, as you have. I'll post more >> details >> > in >> > the github issue at my EOD. >> > >> > 1. >> > >> > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2F9c70b052a6fef3ebe7c6a07ca887af4f7381d46f%2Fframeworks%2Fprojects%2FCore%2Fsrc%2Fmain%2Froyale%2Forg%2Fapache%2Froyale%2Fcore%2FLayoutBase.as%23L131&data=02%7C01%7Caharui%40adobe.com%7C34080cf90f504c1b7ef508d809380095%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269483425406744&sdata=na2D5dkZziw7na8WuNrz%2FRIJzphWgVEVmGX64aPJ1UA%3D&reserved=0 >> > >> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui >> <[email protected]> >> > wrote: >> > >> > > Serkan, is there a bug tracking your layout issue? >> > > >> > > There should be a difference between first layout if all >> children >> > have >> > > known sizes and what Greg is describing which is responding to >> > children >> > > changing sizes. I don’t think we’ve dealt with a lot of >> children >> > changing >> > > sizes (other than Images loading late and a few other things) >> so it >> > may be >> > > time to listen to widthChanged/heightChanged/sizeChanged as >> children >> > get >> > > added if there isn’t already code doing that. >> > > >> > > There might be other issues with containers having an inner >> > contentArea >> > > that might be getting in the way too. >> > > >> > > HTH, >> > > -Alex >> > > >> > > From: Yishay Weiss <[email protected]> >> > > Reply-To: "[email protected]" <[email protected]> >> > > Date: Thursday, June 4, 2020 at 4:30 AM >> > > To: "[email protected]" <[email protected]> >> > > Subject: RE: MXRoyale layout issues - questions/discussion >> > > >> > > Call me lazy but this is a bit difficult to parse. If you can >> spare >> > some >> > > time, maybe come up with a GitHub issue that describes a >> concrete >> > case so >> > > we can discuss this. >> > > >> > > > I think the layouts work downward for this, but changes in >> the >> > children >> > > don't seem to trigger the parent layout. >> > > >> > > Yes, I’ve seen that as well. Alex’s advice when I pointed it >> out to >> > him >> > > was to just add a parent.dispatchEvent(new >> Event(‘layoutNeeded’)) if >> > it >> > > solves a concrete bug. It’s true that this could result in a >> > performance >> > > hit. If that’s your issue then I guess we can discuss >> emulation of >> > the >> > > layout manager or some other optimization. >> > > >> > > >> > > From: Greg Dove <[email protected]> >> > > Sent: Thursday, June 4, 2020 11:12:08 AM >> > > To: Apache Royale Development <[email protected]> >> > > Subject: MXRoyale layout issues - questions/discussion >> > > >> > > Hi, >> > > >> > > Just wondered if anyone else is dealing with layout issues in >> Flex >> > > emulation. I have some layout issues that are slowing my >> progress on >> > a >> > > project, and I'd like to resolve them as quickly as I can. >> > > >> > > In particular, I see issues with BoxLayout-based containers >> which >> > have >> > > percentWidth or percentHeight set. These don't get determined >> as >> > having >> > > width or height 'SizedToContent' when performing layout, but >> in many >> > > situations they behave in a similar way (they can change >> their size >> > based >> > > on their content in terms of layout rules applied by the >> parent >> > container). >> > > This is because in Flex, percentages are not simply a >> percentage of >> > their >> > > parent, but they follow something perhaps a little closer to >> flexbox >> > layout >> > > rules for all the percentWidth or percentHeight siblings >> (managed by >> > their >> > > parent's layout). In other words, they are also related to the >> > measured >> > > size of their content if the parent needs to manage them (I'm >> not >> > sure how >> > > best to describe this, but I think that sort of captures it). >> They >> > can >> > > expand beyond their percent allocation or contract below it >> > depending on >> > > their measured sizes. >> > > I think the layouts work downward for this, but changes in the >> > children >> > > don't seem to trigger the parent layout. >> > > >> > > An example might be >> > > <mx:HBox id='addThingsToMe' width='50%' /> >> > > >> > > If you have the above at the application level (where the >> > application has >> > > vertical layout) and keep adding buttons (for example) to the >> HBox >> > via a UI >> > > test button that adds a new Button to that on each click, >> then it >> > should >> > > expand horizontally greater than 50% width when the volume of >> buttons >> > > exceeds its nominal 50% width. It is definitely easier to see >> this >> > if you >> > > add a border to the container. >> > > >> > > I have been working on this, and made progress, but the >> approach I >> > am using >> > > feels a bit patchwork, and just wondered whether others are >> seeing >> > anything >> > > like this, and/or how it has been addressed elsewhere.... >> > > >> > > Here's a summary of some of the things I have been trying, >> which do >> > yield >> > > improvements, but don't really solve the problem completely: >> > > >> > > 1. added extra listener for 'childrenRemoved' in BoxLayout >> strand >> > setter. >> > > >> > > 2. Created a new mx 'ContainerView' class >> > > (mx.containers.beads.ContainerView extends >> > > org.apache.royale.html.beads.ContainerView) >> > > This has the following in it: >> > > >> > > private var widthBefore:Number = -1 >> > > private var heightBefore:Number = -1; >> > > private var sizeChangedBeforeLayout:Boolean; >> > > >> > > COMPILE::JS >> > > override public function beforeLayout():Boolean >> > > { >> > > var container:Container = host as Container; >> > > >> > > sizeChangedBeforeLayout = (widthBefore != container.width || >> > heightBefore >> > > != container.height); >> > > widthBefore = container.width; >> > > heightBefore = container.height; >> > > return super.beforeLayout(); >> > > } >> > > >> > > COMPILE::JS >> > > override public function afterLayout():void >> > > { >> > > var container:Container = host as Container; >> > > //size might change during layout >> > > var sizeChangedDuringLayout:Boolean = >> !sizeChangedBeforeLayout && >> > > (widthBefore != container.width || heightBefore != >> container.height); >> > > if (sizeChangedDuringLayout) { >> > > //prepare for next time >> > > widthBefore = container.width; >> > > heightBefore = container.height; >> > > } >> > > var requestParentLayout:Boolean = sizeChangedBeforeLayout >> > > || sizeChangedDuringLayout >> > > || (!isNaN(container.percentWidth) && >> container.width < >> > > container.measuredWidth) || (!isNaN(container.percentHeight) >> && >> > > container.height < container.measuredHeight); >> > > if (requestParentLayout && container.parent is >> Container) { >> > > trace('requesting parent layout of ',(container as >> > > Object).ROYALE_CLASS_INFO.names[0].qName ); >> > > (container.parent as Container).layoutNeeded(); >> > > } >> > > } >> > > >> > > That is pretty much it, and it is being used as a replacement >> in my >> > local >> > > MXRoyale css for Container: >> > > >> > > /*IBeadView: >> > > >> ClassReference("org.apache.royale.html.beads.ContainerView");*/ >> > > IBeadView: >> ClassReference("mx.containers.beads.ContainerView"); >> > > >> > > I'm not saying this is right, but it does help quite a bit >> with what >> > I am >> > > facing. >> > > >> > > In addition to BoxLayout in general, I have been working on >> the >> > > Grid/GridRow/GridItem layouts which are more specific in >> terms of >> > layout >> > > changes needed, but also can have similar problems. >> > > >> > > >> > > Although I am seeing improvements with what I have done so >> far, I'm >> > not >> > > really satisfied with it, and I am keen for input/discussion >> (or >> > > collaboration). I have been pursuing what I would mostly >> describe as >> > a >> > > 'workaround' approach, so would welcome any thoughts on how >> best to >> > tackle >> > > this. >> > > I think there is something missing because of the way Flex >> does >> > layouts vs. >> > > the way Royale does it, but I can't describe it fully yet. >> Perhaps >> > things >> > > are only currently envisaged to work with mxml declarative >> content >> > onto >> > > display and not so much with dynamic updates. But I think >> state-based >> > > changes could have similar effects for some of these things >> if they >> > happen >> > > inside containers that have their own percent dimensions. >> > > >> > > >> > > Thanks, >> > > Greg >> > > From: Greg Dove<mailto:[email protected]> >> > > Sent: Thursday, June 4, 2020 11:12 AM >> > > To: Apache Royale Development<mailto:[email protected]> >> > > Subject: MXRoyale layout issues - questions/discussion >> > > >> > > Hi, >> > > >> > > Just wondered if anyone else is dealing with layout issues in >> Flex >> > > emulation. I have some layout issues that are slowing my >> progress on >> > a >> > > project, and I'd like to resolve them as quickly as I can. >> > > >> > > In particular, I see issues with BoxLayout-based containers >> which >> > have >> > > percentWidth or percentHeight set. These don't get determined >> as >> > having >> > > width or height 'SizedToContent' when performing layout, but >> in many >> > > situations they behave in a similar way (they can change >> their size >> > based >> > > on their content in terms of layout rules applied by the >> parent >> > container). >> > > This is because in Flex, percentages are not simply a >> percentage of >> > their >> > > parent, but they follow something perhaps a little closer to >> flexbox >> > layout >> > > rules for all the percentWidth or percentHeight siblings >> (managed by >> > their >> > > parent's layout). In other words, they are also related to the >> > measured >> > > size of their content if the parent needs to manage them (I'm >> not >> > sure how >> > > best to describe this, but I think that sort of captures it). >> They >> > can >> > > expand beyond their percent allocation or contract below it >> > depending on >> > > their measured sizes. >> > > I think the layouts work downward for this, but changes in the >> > children >> > > don't seem to trigger the parent layout. >> > > >> > > An example might be >> > > <mx:HBox id='addThingsToMe' width='50%' /> >> > > >> > > If you have the above at the application level (where the >> > application has >> > > vertical layout) and keep adding buttons (for example) to the >> HBox >> > via a UI >> > > test button that adds a new Button to that on each click, >> then it >> > should >> > > expand horizontally greater than 50% width when the volume of >> buttons >> > > exceeds its nominal 50% width. It is definitely easier to see >> this >> > if you >> > > add a border to the container. >> > > >> > > I have been working on this, and made progress, but the >> approach I >> > am using >> > > feels a bit patchwork, and just wondered whether others are >> seeing >> > anything >> > > like this, and/or how it has been addressed elsewhere.... >> > > >> > > Here's a summary of some of the things I have been trying, >> which do >> > yield >> > > improvements, but don't really solve the problem completely: >> > > >> > > 1. added extra listener for 'childrenRemoved' in BoxLayout >> strand >> > setter. >> > > >> > > 2. Created a new mx 'ContainerView' class >> > > (mx.containers.beads.ContainerView extends >> > > org.apache.royale.html.beads.ContainerView) >> > > This has the following in it: >> > > >> > > private var widthBefore:Number = -1 >> > > private var heightBefore:Number = -1; >> > > private var sizeChangedBeforeLayout:Boolean; >> > > >> > > COMPILE::JS >> > > override public function beforeLayout():Boolean >> > > { >> > > var container:Container = host as Container; >> > > >> > > sizeChangedBeforeLayout = (widthBefore != container.width || >> > heightBefore >> > > != container.height); >> > > widthBefore = container.width; >> > > heightBefore = container.height; >> > > return super.beforeLayout(); >> > > } >> > > >> > > COMPILE::JS >> > > override public function afterLayout():void >> > > { >> > > var container:Container = host as Container; >> > > //size might change during layout >> > > var sizeChangedDuringLayout:Boolean = >> !sizeChangedBeforeLayout && >> > > (widthBefore != container.width || heightBefore != >> container.height); >> > > if (sizeChangedDuringLayout) { >> > > //prepare for next time >> > > widthBefore = container.width; >> > > heightBefore = container.height; >> > > } >> > > var requestParentLayout:Boolean = sizeChangedBeforeLayout >> > > || sizeChangedDuringLayout >> > > || (!isNaN(container.percentWidth) && >> container.width < >> > > container.measuredWidth) || (!isNaN(container.percentHeight) >> && >> > > container.height < container.measuredHeight); >> > > if (requestParentLayout && container.parent is >> Container) { >> > > trace('requesting parent layout of ',(container as >> > > Object).ROYALE_CLASS_INFO.names[0].qName ); >> > > (container.parent as Container).layoutNeeded(); >> > > } >> > > } >> > > >> > > That is pretty much it, and it is being used as a replacement >> in my >> > local >> > > MXRoyale css for Container: >> > > >> > > /*IBeadView: >> > > >> ClassReference("org.apache.royale.html.beads.ContainerView");*/ >> > > IBeadView: >> ClassReference("mx.containers.beads.ContainerView"); >> > > >> > > I'm not saying this is right, but it does help quite a bit >> with what >> > I am >> > > facing. >> > > >> > > In addition to BoxLayout in general, I have been working on >> the >> > > Grid/GridRow/GridItem layouts which are more specific in >> terms of >> > layout >> > > changes needed, but also can have similar problems. >> > > >> > > >> > > Although I am seeing improvements with what I have done so >> far, I'm >> > not >> > > really satisfied with it, and I am keen for input/discussion >> (or >> > > collaboration). I have been pursuing what I would mostly >> describe as >> > a >> > > 'workaround' approach, so would welcome any thoughts on how >> best to >> > tackle >> > > this. >> > > I think there is something missing because of the way Flex >> does >> > layouts vs. >> > > the way Royale does it, but I can't describe it fully yet. >> Perhaps >> > things >> > > are only currently envisaged to work with mxml declarative >> content >> > onto >> > > display and not so much with dynamic updates. But I think >> state-based >> > > changes could have similar effects for some of these things >> if they >> > happen >> > > inside containers that have their own percent dimensions. >> > > >> > > >> > > Thanks, >> > > Greg >> > > >> > > >> > >> > >> > >> >> >>
