>
> 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 <yishayj...@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 <greg.d...@gmail.com>
> *Sent:* Thursday, June 4, 2020 11:12:08 AM
> *To:* Apache Royale Development <dev@royale.apache.org>
> *Subject:* MXRoyale layout issues - questions/discussion
>
>
>
> Hi,
>
> Just wondered if anyone else is dealing with layout issues in Flex
> emulation. I have some layout issues that are slowing my progress on a
> project, and I'd like to resolve them as quickly as I can.
>
> In particular, I see issues with BoxLayout-based containers which have
> percentWidth or percentHeight set. These don't get determined as having
> width or height 'SizedToContent' when performing layout, but in many
> situations they behave in a similar way (they can change their size based
> on their content in terms of layout rules applied by the parent container).
> This is because in Flex, percentages are not simply a percentage of their
> parent, but they follow something perhaps a little closer to flexbox layout
> rules for all the percentWidth or percentHeight siblings (managed by their
> parent's layout). In other words, they are also related to the measured
> size of their content if the parent needs to manage them (I'm not sure how
> best to describe this, but I think that sort of captures it). They can
> expand beyond their percent allocation or contract below it depending on
> their measured sizes.
> I think the layouts work downward for this, but changes in the children
> don't seem to trigger the parent layout.
>
> An example might be
> <mx:HBox id='addThingsToMe' width='50%' />
>
> If you have the above at the application level (where the application has
> vertical layout) and keep adding buttons (for example) to the HBox via a UI
> test button that adds a new Button to that on each click, then it should
> expand horizontally greater than 50% width when the volume of buttons
> exceeds its nominal 50% width. It is definitely easier to see this if you
> add a border to the container.
>
> I have been working on this, and made progress, but the approach I am using
> feels a bit patchwork, and just wondered whether others are seeing anything
> like this, and/or how it has been addressed elsewhere....
>
> Here's a summary of some of the things I have been trying, which do yield
> improvements, but don't really solve the problem completely:
>
> 1. added extra listener for 'childrenRemoved' in BoxLayout strand setter.
>
> 2. Created a new mx 'ContainerView' class
> (mx.containers.beads.ContainerView extends
> org.apache.royale.html.beads.ContainerView)
> This has the following in it:
>
> private var widthBefore:Number = -1
> private var heightBefore:Number = -1;
> private var sizeChangedBeforeLayout:Boolean;
>
> COMPILE::JS
> override public function beforeLayout():Boolean
> {
> var container:Container = host as Container;
>
> sizeChangedBeforeLayout = (widthBefore != container.width || heightBefore
> != container.height);
> widthBefore = container.width;
> heightBefore = container.height;
> return super.beforeLayout();
> }
>
> COMPILE::JS
> override public function afterLayout():void
> {
> var container:Container = host as Container;
> //size might change during layout
> var sizeChangedDuringLayout:Boolean = !sizeChangedBeforeLayout &&
> (widthBefore != container.width || heightBefore != container.height);
> if (sizeChangedDuringLayout) {
> //prepare for next time
> widthBefore = container.width;
> heightBefore = container.height;
> }
> var requestParentLayout:Boolean = sizeChangedBeforeLayout
> || sizeChangedDuringLayout
> || (!isNaN(container.percentWidth) && container.width <
> container.measuredWidth) || (!isNaN(container.percentHeight) &&
> container.height < container.measuredHeight);
> if (requestParentLayout && container.parent is Container) {
> trace('requesting parent layout of ',(container as
> Object).ROYALE_CLASS_INFO.names[0].qName );
> (container.parent as Container).layoutNeeded();
> }
> }
>
> That is pretty much it, and it is being used as a replacement in my local
> MXRoyale css for Container:
>
> /*IBeadView:
> ClassReference("org.apache.royale.html.beads.ContainerView");*/
> IBeadView: ClassReference("mx.containers.beads.ContainerView");
>
> I'm not saying this is right, but it does help quite a bit with what I am
> facing.
>
> In addition to BoxLayout in general, I have been working on the
> Grid/GridRow/GridItem layouts which are more specific in terms of layout
> changes needed, but also can have similar problems.
>
>
> Although I am seeing improvements with what I have done so far, I'm not
> really satisfied with it, and I am keen for input/discussion (or
> collaboration). I have been pursuing what I would mostly describe as a
> 'workaround' approach, so would welcome any thoughts on how best to tackle
> this.
> I think there is something missing because of the way Flex does layouts vs.
> the way Royale does it, but I can't describe it fully yet. Perhaps things
> are only currently envisaged to work with mxml declarative content onto
> display and not so much with dynamic updates. But I think state-based
> changes could have similar effects for some of these things if they happen
> inside containers that have their own percent dimensions.
>
>
> Thanks,
> Greg
>
> *From: *Greg Dove <greg.d...@gmail.com>
> *Sent: *Thursday, June 4, 2020 11:12 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
>
>
>
