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" <greg.d...@gmail.com> 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 <aha...@adobe.com.invalid> wrote:
> Responses inline.
>
> On 6/7/20, 2:49 PM, "Greg Dove" <greg.d...@gmail.com> 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 <aha...@adobe.com.invalid>
> 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" <greg.d...@gmail.com> 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 <greg.d...@gmail.com>
> 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
> <aha...@adobe.com.invalid>
> > > 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" <greg.d...@gmail.com> 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
> > <aha...@adobe.com.invalid>
> > >> 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" <greg.d...@gmail.com>
> 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
> > >> <aha...@adobe.com.invalid>
> > >> > 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 <yishayj...@hotmail.com>
> > >> > > Reply-To: "dev@royale.apache.org" <
> > dev@royale.apache.org>
> > >> > > Date: Thursday, June 4, 2020 at 4:30 AM
> > >> > > To: "dev@royale.apache.org" <
> dev@royale.apache.org>
> > >> > > 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 <greg.d...@gmail.com>
> > >> > > Sent: Thursday, June 4, 2020 11:12:08 AM
> > >> > > To: Apache Royale Development <
> dev@royale.apache.org>
> > >> > > 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:greg.d...@gmail.com>
> > >> > > Sent: Thursday, June 4, 2020 11:12 AM
> > >> > > To: Apache Royale Development<mailto:
> > dev@royale.apache.org>
> > >> > > 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
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> >
> >
> >
>
>
>
