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 <aha...@adobe.com.invalid> 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" <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
> > > >> > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>
