Alex, I found another layout related issue to do with measurement. measuredWidth and measuredHeight can be zero as valid values. But the getters in UIComponent consider <= 0 as a trigger to re-evaluate the measurement. I'm assuming that we have the zero value to also re-trigger calculation (and not just NaN) in js for a specific reason. In that case I believe the following needs to be added to the measuredWidth and measuredHeight getters:
e.g. inside public function get measuredHeight():Number the part that is like this: if (child) mh = Math.max(mh, child.getExplicitOrMeasuredHeight()); should, IMO, be like: if (child && child.includeInLayout) mh = Math.max(mh, child.getExplicitOrMeasuredHeight()); (Likewise, similar for measuredWidth) This fixes an issue in the app I am porting with containers where all children can have includeInLayout=false (and the measured height is assigned calculated and assigned as zero at the end of the BoxLayout's measure method, but then the getter on the target recalculates with a higher measuredHeight because it is still including the children which ought to be excluded from the calculation : includeInLayout=false) I'm tempted to make these changes in MXRoyale, but I don't know if others may be relying on the current behavior. What do you think? thanks, Greg On Tue, Jun 9, 2020 at 8:35 AM Greg Dove <[email protected]> wrote: > Thanks Alex, that was quick! I will try to find time during my > Tuesday-Friday to work on this. Otherwise, if I can't get to it then, I can > definitely spend time on it during my next weekend. > > > On Mon, Jun 8, 2020 at 8:07 PM Alex Harui <[email protected]> > wrote: > >> I pushed a branch called ChildResize. It seemed to make the example work >> much better, without even getting into measure() changes, possibly because >> the example doesn't really test measurement changes. >> >> IMO, to handle measurement changes, the measure() logic would dispatch >> some new event if the measureWidth/Height change. The BoxLayout would be >> listening, run its measure(), and dispatch that same event to its parent if >> it changes, and if it doesn't change, then run layout. That event would be >> listened for in the listenToChildren() method I added to BoxLayout. >> >> There should be a difference between measurement changes and setting >> width/height. If you set width/height on a child, then the child's layout >> should run. Assuming layout only runs if width/height change, then I think >> it shouldn't really matter that much if it runs before or after notifying >> the parent. The parent should honor the width/height so the child's layout >> shouldn't run again. The child can check isWidthSizedToContent() to >> determine if the parent needs notification. >> >> If you want to modify the test case to introduce a measurement change >> then we can try handling that. Feel free to try adding the measure() >> handling to the test case and to BoxLayout. Otherwise I will try to code >> it up sometime this week. >> >> HTH, >> -Alex >> >> On 6/7/20, 4:26 PM, "Greg Dove" <[email protected]> wrote: >> >> > >> > That's my goal in the changes I'm playing with: to mimic the 2 >> passes. >> > We'll see how it goes. >> >> >> Ok, that's good to know. I hadn't picked up on it being that >> extensive. If >> there's anything I can help with, please let me know. >> >> On Mon, Jun 8, 2020 at 11:07 AM Alex Harui <[email protected]> >> wrote: >> >> > Responses inline. >> > >> > On 6/7/20, 2:49 PM, "Greg Dove" <[email protected]> wrote: >> > >> > > >> > > Turns out I was wrong and JS LayoutBase is not listening for >> > > widthChanged/heightChanged/sizeChanged. That was SWF-only >> code I saw >> > > earlier. IMO, that's the first thing to change by overriding >> > > handleChildrenAdded in BoxLayout and other MX Layouts. I >> don't >> > think Basic >> > > layouts need to watch children for size changes. >> > >> > Yeah, I mentioned that earlier. Not only was it swf-only, it >> was only >> > prior >> > to 'sawInitCompleted' (or whatever the exact name for that flag >> is, >> > going >> > from memory). >> > >> > I thought I'd read that in one of your posts but couldn't find it >> when I >> > looked for it. Anyway, the parent needs to listen to each child >> for some >> > event. >> > >> > For the 'handleChildrenAdded' thing it also needs to cover >> > 'handleChildrenRemoved'. Doing things this way would mean >> adding the 3 >> > size-related listeners on 'add' child and then removing them on >> > 'remove' >> > child. But I still think that could be avoidable. >> > Why? Because the children are already listening to these events >> for >> > their own layouts. Their own layouts respond to their size >> changes. So >> > the >> > question is : when does the parent need to know about the >> child's size >> > change: is it before it does it's own layout, or after (and >> could that >> > requirement be different for some 'parent' layouts)? The >> child's own >> > layout >> > process can inform the parent in either case via beforeLayout >> (where >> > the >> > parent could even signal to the child not to continue its own >> layout, >> > in >> > which case presumably the parent will simply 'take over') or >> > afterLayout(), >> > which could trigger a re-flow downwards from the parent - I >> definitely >> > did >> > not do all this with the 'workaround' I already added, but >> maybe there >> > is >> > something to this approach? On the other hand, if as you >> suggest, the >> > parent layouts are also adding their own listeners to each >> child, then >> > assuming the execution order of the size change listeners on the >> > children >> > will be deterministic in terms of when the parent layout runs >> its >> > listener >> > versus when the child's own layout runs its listener, it seems >> to me >> > that >> > adding individual listeners to each of the children could be >> doubling >> > up on >> > something that is already possible without doing that (just by >> thinking >> > about it in a different way : 'the children layouts are already >> > listening >> > to those events, and it is possible for them to talk to their >> parent >> > layouts'). >> > If all the MXRoyale layouts were doing something like the >> 'measure if >> > needed' before the layout, then maybe it could actually mimic >> the 2 >> > passes >> > of the Flex approach, using beforeLayout() and afterLayout() to >> advise >> > the >> > parent layouts... just pondering this, not at all sure yet. >> > >> > I have concerns about using beforeLayout/afterLayout to trigger >> another >> > layout such as the "layout loop" I wrote about earlier. I would >> rather >> > mimic the 2 Flex passes where the measuring would happen separately >> from >> > layout. >> > >> > >> > Also UIComponent's setActualSize() should set the noEvent flag >> on >> > > setWidthAndHeight. >> > >> > I assume that could work if the layout flow is always from the >> root of >> > the >> > display tree downwards, same as Flex. But if it is signaling up >> to let >> > parents know that a child's own layout caused some change that >> should >> > be >> > interesting to the parent, I am not so sure how that would work. >> > >> > IMO, in Flex, if non-layout code set the width/height of some >> component, >> > that would fire a change event to trigger a layout. But when >> layout code >> > set the width/height (via setActualSize), it would not fire events >> and >> > re-trigger another layout pass. It maybe be that instead of setting >> > noEvent on setWidthAndHeight that we set some flag in the handler >> to ignore >> > change events from children. >> > >> > The reason I'm suggesting these changes is because I think >> that's >> > closer to >> > > what Flex does. I don't think Flex has logic like >> > > sizeChangedBeforeLayout/sizeChangedDuringLayout logic. >> > >> > Yeah I get that. But unless we actually do the 'measure from >> > bottom-up'. >> > 'layout from top-down' flow as Flex, I think we might be stuck >> with >> > some >> > sort of workarounds that are not the same as Flex in any case >> because >> > we >> > are already not 'close' enough to how Flex does things (I >> really hope >> > I am >> > wrong, definitely keen to see your solution). >> > >> > That's my goal in the changes I'm playing with: to mimic the 2 >> passes. >> > We'll see how it goes. >> > >> > -Alex >> > >> > On Sun, Jun 7, 2020 at 7:23 PM Alex Harui >> <[email protected]> >> > wrote: >> > >> > > Easy thing first: The bubbling of layoutNeeded from Image is >> a hack >> > and >> > > should go away someday. >> > > >> > > Turns out I was wrong and JS LayoutBase is not listening for >> > > widthChanged/heightChanged/sizeChanged. That was SWF-only >> code I saw >> > > earlier. IMO, that's the first thing to change by overriding >> > > handleChildrenAdded in BoxLayout and other MX Layouts. I >> don't >> > think Basic >> > > layouts need to watch children for size changes. >> > > >> > > Also UIComponent's setActualSize() should set the noEvent >> flag on >> > > setWidthAndHeight. >> > > >> > > The reason I'm suggesting these changes is because I think >> that's >> > closer >> > > to what Flex does. I don't think Flex has logic like >> > > sizeChangedBeforeLayout/sizeChangedDuringLayout logic. >> > > >> > > For some reason, ApplicationLayout is not getting the >> > > handleChildrenAdded. I will work on it more tomorrow. >> > > >> > > HTH, >> > > -Alex >> > > >> > > On 6/6/20, 12:16 AM, "Greg Dove" <[email protected]> wrote: >> > > >> > > 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%7C1aa5a190e8644dd33de108d80b3a37da%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637271691963494100&sdata=Cg4h62rBo8yUCCBqJIYZh9iI2L5lRL2ET6SgUVbWdBQ%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 >> > > >> > > >> > > >> > > >> > > >> > >> > > >> > >> > > >> > >> > > >> >> > > >> >> > > >> >> > > >> > > >> > > >> > >> > >> > >> >> >>
