Sorry for the radio silence, Alex. I will try to find time to get back into
this tonight my time, if not then it might not be until my weekend (2 days
from now).
I'm using the hack-ish solutions I did for now while I focus on
other things in my current work, but definitely keen to see if we can find
a more general solution.
I think this is important and that it could make a big difference to the
porting process (and to first impressions) for some users. So I will get to
this as soon as I can.
On Tue, Jun 9, 2020 at 2:20 PM Alex Harui <aha...@adobe.com.invalid> wrote:
> The changes in the ChildResize branch didn't take too long because it only
> hooked up re-layout for width/height changes in children. It doesn’t have
> the propagation of measurement changes because the test case didn't seem to
> need it. If you have a scenario where measurement does change then we can
> work on adding the propagation.
>
> Lots of components get an initial measured width/height of 0. Sometimes
> that's because offsetWidth/Height are 0 at initialization, sometimes it is
> because no content has been assigned yet. So the 0 trigger is sort of a
> hack to deal with that. It might go away if we implement the measurement
> change propagation. The getting of measuredWidth/Height was a way to call
> measure() on demand. But I think we'll end up shifting to calling
> measure() more often as properties that affect measurement change. It is
> tempting to have invalidateSize() immediately call measure() and then send
> an event if measurement changes, but I'm concerned that measure() might get
> called too often so we might just have setters call measure and send the
> event.
>
> For the existing code, my thinking was that components where 0 is a valid
> measuredWidth/Height would override the getter and do some other
> computation to return a valid number, including 0.
>
> HTH,
> -Alex
>
> On 6/8/20, 4:57 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> Alex, I found another layout related issue to do with measurement.
>
> measuredWidth and measuredHeight can be zero as valid values. But the
> getters in UIComponent consider <= 0 as a trigger to re-evaluate the
> measurement. I'm assuming that we have the zero value to also
> re-trigger
> calculation (and not just NaN) in js for a specific reason.
> In that case I believe the following needs to be added to the
> measuredWidth
> and measuredHeight getters:
>
> e.g. inside
> public function get measuredHeight():Number
> the part that is like this:
>
> if (child)
> mh = Math.max(mh, child.getExplicitOrMeasuredHeight());
>
>
> should, IMO, be like:
>
> if (child && child.includeInLayout)
> mh = Math.max(mh, child.getExplicitOrMeasuredHeight());
>
>
> (Likewise, similar for measuredWidth)
>
> This fixes an issue in the app I am porting with containers where all
> children can have includeInLayout=false (and the measured height is
> assigned calculated and assigned as zero at the end of the BoxLayout's
> measure method, but then the getter on the target recalculates with a
> higher measuredHeight because it is still including the children which
> ought to be excluded from the calculation : includeInLayout=false)
>
> I'm tempted to make these changes in MXRoyale, but I don't know if
> others
> may be relying on the current behavior. What do you think?
>
> thanks,
> Greg
>
>
>
> On Tue, Jun 9, 2020 at 8:35 AM Greg Dove <greg.d...@gmail.com> wrote:
>
> > Thanks Alex, that was quick! I will try to find time during my
> > Tuesday-Friday to work on this. Otherwise, if I can't get to it
> then, I can
> > definitely spend time on it during my next weekend.
> >
> >
> > On Mon, Jun 8, 2020 at 8:07 PM Alex Harui <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%7Ccf31cbaae5b54149555008d80c07abf1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637272574377108976&sdata=lzhiaYqbbqerojKKy4JjrUnPsscFPJ%2FN%2BFEgvzEjqeE%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
> >> > > >> > >
> >> > > >> > >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > > >>
> >> > > >>
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>
>
