> > 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%7C7ca071cb0fc9484c4a0f08d80b2c98c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637271633462284956&sdata=%2FOVs4X2AKyRqPknzoIp5K%2FviA4y49%2FAE2uI%2B8Aw00rI%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 > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > > > > > > > >
