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