You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Greg Dove <gr...@gmail.com> on 2020/06/04 08:12:08 UTC
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
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
>
> 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.
I'm not worried about performance issues, or at least I have not had reason
to so far. It was a case of some layouts not working in the way that they
did in Flex, and the need to track them down and figure them out being
complicated in a deeply nested layout structure. Basically the change I
showed in the ContainerView was detecting more cases for when the call to
parent's layout was likely to be needed after the child's layout was
complete.
In terms of thinking about full LayoutManager emulation, I had definitely
wondered about that also. But I think the implications there are important
to consider earlier rather than later, because it might only really make
sense if tied to a general emulation of the Flex component
lifecycle, which we have avoided directly emulating thus far. And so far,
it has worked 'close enough' to get a lot done. So I am not sure what the
threshold for making that decision should be.
Perhaps the question is: are we seeing enough variation in the needs of
people who would consider it is currently 'close enough' for them, for us
to be sure it is 'close enough' for most? If we can be sure of this then we
probably could continue to fill gaps in the current approach (which is
built on/leveraging how things work in Basic and Core etc).
If you can spare some time, maybe come up with a GitHub issue that
> describes a concrete case so we can discuss this.
Sure, I actually started this way, but then figured that I should approach
it with a discussion first, because I have actually worked on this, and
have what I think is at least a partial solution to the problem. I'm just
not sure whether I am tackling it the 'right' way.
I have been testing and refining what I did so far with isolated cases of
the issues, with a simple test app which runs in Flex as well as Royale. I
will post that test app in an issue later today.
On Thu, Jun 4, 2020 at 11:30 PM Yishay Weiss <yi...@hotmail.com> wrote:
> 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 <gr...@gmail.com>
> *Sent:* Thursday, June 4, 2020 11:12:08 AM
> *To:* Apache Royale Development <de...@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 <gr...@gmail.com>
> *Sent: *Thursday, June 4, 2020 11:12 AM
> *To: *Apache Royale Development <de...@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
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@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" <gr...@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 <gr...@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 <ah...@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" <gr...@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
> <ah...@adobe.com.invalid>
> >> wrote:
> >>
> >> > Responses inline.
> >> >
> >> > On 6/7/20, 2:49 PM, "Greg Dove" <gr...@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
> >> <ah...@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" <gr...@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.dove@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
> >> > <ah...@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.dove@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
> >> > > <ah...@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.dove@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
> >> > > >> <ah...@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 <
> yishayjobs@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.dove@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.dove@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
> >> > > >> > >
> >> > > >> > >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > > >>
> >> > > >>
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@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 <gr...@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 <ah...@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" <gr...@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 <ah...@adobe.com.invalid>
>> wrote:
>>
>> > Responses inline.
>> >
>> > On 6/7/20, 2:49 PM, "Greg Dove" <gr...@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
>> <ah...@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" <gr...@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.dove@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
>> > <ah...@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" <gr...@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
>> > > <ah...@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.dove@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
>> > > >> <ah...@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 <yishayjobs@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 <gr...@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.dove@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
>> > > >> > >
>> > > >> > >
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >>
>> > > >>
>> > > >>
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
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 <gr...@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 <ah...@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" <gr...@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 <ah...@adobe.com.invalid>
>> wrote:
>>
>> > Responses inline.
>> >
>> > On 6/7/20, 2:49 PM, "Greg Dove" <gr...@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
>> <ah...@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" <gr...@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.dove@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
>> > <ah...@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" <gr...@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
>> > > <ah...@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.dove@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
>> > > >> <ah...@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 <yishayjobs@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 <gr...@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.dove@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
>> > > >> > >
>> > > >> > >
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >>
>> > > >>
>> > > >>
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@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" <gr...@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 <ah...@adobe.com.invalid>
> wrote:
>
> > Responses inline.
> >
> > On 6/7/20, 2:49 PM, "Greg Dove" <gr...@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
> <ah...@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" <gr...@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.dove@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
> > <ah...@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" <gr...@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
> > > <ah...@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.dove@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
> > > >> <ah...@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 <yi...@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 <gr...@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<ma...@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
> > > >> > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@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 <ah...@adobe.com.invalid> wrote:
> Responses inline.
>
> On 6/7/20, 2:49 PM, "Greg Dove" <gr...@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 <ah...@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" <gr...@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 <gr...@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
> <ah...@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" <gr...@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
> > <ah...@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" <gr...@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
> > >> <ah...@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 <yi...@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 <gr...@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<ma...@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
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> >
> >
> >
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
>
> 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 <ah...@adobe.com.invalid> wrote:
> Responses inline.
>
> On 6/7/20, 2:49 PM, "Greg Dove" <gr...@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 <ah...@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" <gr...@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 <gr...@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
> <ah...@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" <gr...@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
> > <ah...@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" <gr...@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%7C7ca071cb0fc9484c4a0f08d80b2c98c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637271633462284956&sdata=%2FOVs4X2AKyRqPknzoIp5K%2FviA4y49%2FAE2uI%2B8Aw00rI%3D&reserved=0
> > >> >
> > >> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
> > >> <ah...@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 <yi...@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 <gr...@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<ma...@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
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> >
> >
> >
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Responses inline.
On 6/7/20, 2:49 PM, "Greg Dove" <gr...@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 <ah...@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" <gr...@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 <gr...@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 <ah...@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" <gr...@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
> <ah...@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" <gr...@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%7C7ca071cb0fc9484c4a0f08d80b2c98c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637271633462284956&sdata=%2FOVs4X2AKyRqPknzoIp5K%2FviA4y49%2FAE2uI%2B8Aw00rI%3D&reserved=0
> >> >
> >> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
> >> <ah...@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 <yi...@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" <de...@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 <gr...@gmail.com>
> >> > > Sent: Thursday, June 4, 2020 11:12:08 AM
> >> > > To: Apache Royale Development <de...@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<ma...@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
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
>
> 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).
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.
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.
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).
On Sun, Jun 7, 2020 at 7:23 PM Alex Harui <ah...@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" <gr...@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 <gr...@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 <ah...@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" <gr...@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
> <ah...@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" <gr...@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%7C8a6459c6e39047dd9d4608d809e97d92%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637270245738238954&sdata=DtytJwdH1LB91GBcUzPsMGrDRL2jIHAONtVX%2FojUFXA%3D&reserved=0
> >> >
> >> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
> >> <ah...@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 <yi...@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" <de...@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 <gr...@gmail.com>
> >> > > Sent: Thursday, June 4, 2020 11:12:08 AM
> >> > > To: Apache Royale Development <de...@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<ma...@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
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@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 <gr...@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 <ah...@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" <gr...@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 <ah...@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" <gr...@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%7C8a6459c6e39047dd9d4608d809e97d92%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637270245738238954&sdata=DtytJwdH1LB91GBcUzPsMGrDRL2jIHAONtVX%2FojUFXA%3D&reserved=0
>> >
>> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
>> <ah...@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 <yi...@hotmail.com>
>> > > Reply-To: "dev@royale.apache.org" <de...@royale.apache.org>
>> > > Date: Thursday, June 4, 2020 at 4:30 AM
>> > > To: "dev@royale.apache.org" <de...@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 <gr...@gmail.com>
>> > > Sent: Thursday, June 4, 2020 11:12:08 AM
>> > > To: Apache Royale Development <de...@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<ma...@gmail.com>
>> > > Sent: Thursday, June 4, 2020 11:12 AM
>> > > To: Apache Royale Development<ma...@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
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
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 <gr...@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 <ah...@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" <gr...@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 <ah...@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" <gr...@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%7C34080cf90f504c1b7ef508d809380095%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269483425406744&sdata=na2D5dkZziw7na8WuNrz%2FRIJzphWgVEVmGX64aPJ1UA%3D&reserved=0
>> >
>> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
>> <ah...@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 <yi...@hotmail.com>
>> > > Reply-To: "dev@royale.apache.org" <de...@royale.apache.org>
>> > > Date: Thursday, June 4, 2020 at 4:30 AM
>> > > To: "dev@royale.apache.org" <de...@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 <gr...@gmail.com>
>> > > Sent: Thursday, June 4, 2020 11:12:08 AM
>> > > To: Apache Royale Development <de...@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<ma...@gmail.com>
>> > > Sent: Thursday, June 4, 2020 11:12 AM
>> > > To: Apache Royale Development<ma...@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
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@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" <gr...@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 <ah...@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" <gr...@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%7C34080cf90f504c1b7ef508d809380095%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269483425406744&sdata=na2D5dkZziw7na8WuNrz%2FRIJzphWgVEVmGX64aPJ1UA%3D&reserved=0
> >
> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
> <ah...@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 <yi...@hotmail.com>
> > > Reply-To: "dev@royale.apache.org" <de...@royale.apache.org>
> > > Date: Thursday, June 4, 2020 at 4:30 AM
> > > To: "dev@royale.apache.org" <de...@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 <gr...@gmail.com>
> > > Sent: Thursday, June 4, 2020 11:12:08 AM
> > > To: Apache Royale Development <de...@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<ma...@gmail.com>
> > > Sent: Thursday, June 4, 2020 11:12 AM
> > > To: Apache Royale Development<ma...@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
> > >
> > >
> >
> >
> >
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@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 <ah...@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" <gr...@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%7C34080cf90f504c1b7ef508d809380095%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269483425406744&sdata=na2D5dkZziw7na8WuNrz%2FRIJzphWgVEVmGX64aPJ1UA%3D&reserved=0
>
> On Fri, Jun 5, 2020 at 3:32 AM Alex Harui <ah...@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 <yi...@hotmail.com>
> > Reply-To: "dev@royale.apache.org" <de...@royale.apache.org>
> > Date: Thursday, June 4, 2020 at 4:30 AM
> > To: "dev@royale.apache.org" <de...@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 <gr...@gmail.com>
> > Sent: Thursday, June 4, 2020 11:12:08 AM
> > To: Apache Royale Development <de...@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<ma...@gmail.com>
> > Sent: Thursday, June 4, 2020 11:12 AM
> > To: Apache Royale Development<ma...@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
> >
> >
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@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" <gr...@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%7C6386a0b1feaa464dab7c08d808c9126c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269006974198657&sdata=Mrz28G2QGTZDNSRqZuLyrHe52Q2yje7Y2qUZA%2BroK0k%3D&reserved=0
>
> On Fri, Jun 5, 2020 at 3:32 AM Alex Harui <ah...@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 <yi...@hotmail.com>
> > Reply-To: "dev@royale.apache.org" <de...@royale.apache.org>
> > Date: Thursday, June 4, 2020 at 4:30 AM
> > To: "dev@royale.apache.org" <de...@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 <gr...@gmail.com>
> > Sent: Thursday, June 4, 2020 11:12:08 AM
> > To: Apache Royale Development <de...@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<ma...@gmail.com>
> > Sent: Thursday, June 4, 2020 11:12 AM
> > To: Apache Royale Development<ma...@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
> >
> >
>
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Greg,
I think this thread got forked somehow. If you have a simple test case I can try to look at it this weekend.
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.
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.
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.
HTH,
-Alex
On 6/4/20, 1:51 PM, "Greg Dove" <gr...@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%7C6386a0b1feaa464dab7c08d808c9126c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269006974198657&sdata=Mrz28G2QGTZDNSRqZuLyrHe52Q2yje7Y2qUZA%2BroK0k%3D&reserved=0
On Fri, Jun 5, 2020 at 3:32 AM Alex Harui <ah...@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 <yi...@hotmail.com>
> Reply-To: "dev@royale.apache.org" <de...@royale.apache.org>
> Date: Thursday, June 4, 2020 at 4:30 AM
> To: "dev@royale.apache.org" <de...@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 <gr...@gmail.com>
> Sent: Thursday, June 4, 2020 11:12:08 AM
> To: Apache Royale Development <de...@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<ma...@gmail.com>
> Sent: Thursday, June 4, 2020 11:12 AM
> To: Apache Royale Development<ma...@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
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by Greg Dove <gr...@gmail.com>.
'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://github.com/apache/royale-asjs/blob/9c70b052a6fef3ebe7c6a07ca887af4f7381d46f/frameworks/projects/Core/src/main/royale/org/apache/royale/core/LayoutBase.as#L131
On Fri, Jun 5, 2020 at 3:32 AM Alex Harui <ah...@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 <yi...@hotmail.com>
> Reply-To: "dev@royale.apache.org" <de...@royale.apache.org>
> Date: Thursday, June 4, 2020 at 4:30 AM
> To: "dev@royale.apache.org" <de...@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 <gr...@gmail.com>
> Sent: Thursday, June 4, 2020 11:12:08 AM
> To: Apache Royale Development <de...@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<ma...@gmail.com>
> Sent: Thursday, June 4, 2020 11:12 AM
> To: Apache Royale Development<ma...@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
>
>
Re: MXRoyale layout issues - questions/discussion
Posted by serkan <se...@likyateknoloji.com>.
Sure not Alex,
I am creating issues one by one. I just wanted to respond Greg's question.
Thanks,
Serkan
4.06.2020 18:32 tarihinde Alex Harui yazdı:
> 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 <yi...@hotmail.com>
> Reply-To: "dev@royale.apache.org" <de...@royale.apache.org>
> Date: Thursday, June 4, 2020 at 4:30 AM
> To: "dev@royale.apache.org" <de...@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 <gr...@gmail.com>
> Sent: Thursday, June 4, 2020 11:12:08 AM
> To: Apache Royale Development <de...@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<ma...@gmail.com>
> Sent: Thursday, June 4, 2020 11:12 AM
> To: Apache Royale Development<ma...@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
>
Re: MXRoyale layout issues - questions/discussion
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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 <yi...@hotmail.com>
Reply-To: "dev@royale.apache.org" <de...@royale.apache.org>
Date: Thursday, June 4, 2020 at 4:30 AM
To: "dev@royale.apache.org" <de...@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 <gr...@gmail.com>
Sent: Thursday, June 4, 2020 11:12:08 AM
To: Apache Royale Development <de...@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<ma...@gmail.com>
Sent: Thursday, June 4, 2020 11:12 AM
To: Apache Royale Development<ma...@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
RE: MXRoyale layout issues - questions/discussion
Posted by Yishay Weiss <yi...@hotmail.com>.
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 <gr...@gmail.com>
Sent: Thursday, June 4, 2020 11:12:08 AM
To: Apache Royale Development <de...@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<ma...@gmail.com>
Sent: Thursday, June 4, 2020 11:12 AM
To: Apache Royale Development<ma...@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
Re: MXRoyale layout issues - questions/discussion
Posted by serkan <se...@likyateknoloji.com>.
Hi Greg,
Yes I am.
Here is my case :
Flex:
Emulation :
Thanks,
Serkan
4.06.2020 11:12 tarihinde Greg Dove yazdı:
> 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
>