Re: MXRoyale layout issues - questions/discussion
; >> > 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 > >> > >
Re: MXRoyale layout issues - questions/discussion
> 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
Re: MXRoyale layout issues - questions/discussion
> >>
>> > > >>
>> > > >> > 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
>>
Re: MXRoyale layout issues - questions/discussion
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
> > > >>
Re: MXRoyale layout issues - questions/discussion
> 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"
> 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%23L131data=02%7C01%7Caharui%40adobe.com%7C1aa5a190e8644dd33de108d80b3a37da%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637271691963494100sdata=Cg4h62rBo8yUCCBqJIYZh9iI2L5lRL2ET6SgUVbWdBQ%3Dreserved=0
> > >> >
> > >> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
> > >
Re: MXRoyale layout issues - questions/discussion
nd
> > 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"
> 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 i
Re: MXRoyale layout issues - questions/discussion
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%23L131data=02%7C01%7Caharui%40adobe.com%7C7ca071cb0fc9484c4a0f08d80b2c98c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637271633462284956sdata=%2FOVs4X2AKyRqPknzoIp5K%2FviA4y49%2FAE2uI%2B8Aw00rI%3Dreserved=0 > >> > > >> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui > >> > >> > 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 > >> > > Reply-To: "dev@royale.apache.org" < > dev@royale.apache.org> > >> > > Date: Thursday, June 4, 2020 at 4:30 AM > >> > > To: "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. > >> > > > >> > &g
Re: MXRoyale layout issues - questions/discussion
>> 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" 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%23L131data=02%7C01%7Caharui%40adobe.com%7C8a6459c6e39047dd9d4608d809e97d92%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637270245738238954sdata=DtytJwdH1LB91GBcUzPsMGrDRL2jIHAONtVX%2FojUFXA%3Dreserved=0
> >> >
> >> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
> >>
> >> > 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
> >>
Re: MXRoyale layout issues - questions/discussion
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" 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%23L131data=02%7C01%7Caharui%40adobe.com%7C8a6459c6e39047dd9d4608d809e97d92%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637270245738238954sdata=DtytJwdH1LB91GBcUzPsMGrDRL2jIHAONtVX%2FojUFXA%3Dreserved=0
>> >
>> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
>>
>> > 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
>> > > Reply-To: "dev@royale.apache.org"
>> > > Date: Thursday, June 4, 2020 at 4:30 AM
>> > > To: "dev@royale.apache.org"
>> > > Subject: RE: MXRoyale layout issues - questions/discussio
Re: MXRoyale layout issues - questions/discussion
t 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%23L131data=02%7C01%7Caharui%40adobe.com%7C34080cf90f504c1b7ef508d809380095%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269483425406744sdata=na2D5dkZziw7na8WuNrz%2FRIJzphWgVEVmGX64aPJ1UA%3Dreserved=0 >> > >> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui >> >> > 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 >> > > Reply-To: "dev@royale.apache.org" >> > > Date: Thursday, June 4, 2020 at 4:30 AM >> > > To: "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 >> > > Sent: Thursday, June 4, 2020 11:12:08 AM >> > > To: Apache Royale Development >> > > 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 ca
Re: MXRoyale layout issues - questions/discussion
y 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" 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%23L131data=02%7C01%7Caharui%40adobe.com%7C34080cf90f504c1b7ef508d809380095%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269483425406744sdata=na2D5dkZziw7na8WuNrz%2FRIJzphWgVEVmGX64aPJ1UA%3Dreserved=0
> >
> > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
>
> > 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
Re: MXRoyale layout issues - questions/discussion
is 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%23L131data=02%7C01%7Caharui%40adobe.com%7C34080cf90f504c1b7ef508d809380095%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269483425406744sdata=na2D5dkZziw7na8WuNrz%2FRIJzphWgVEVmGX64aPJ1UA%3Dreserved=0 > > On Fri, Jun 5, 2020 at 3:32 AM Alex Harui > 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 > > Reply-To: "dev@royale.apache.org" > > Date: Thursday, June 4, 2020 at 4:30 AM > > To: "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 > > Sent: Thursday, June 4, 2020 11:12:08 AM > > To: Apache Royale Development > > 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 see
Re: MXRoyale layout issues - questions/discussion
+1 Agree Greg, Layout is the most time consuming issue I faced with UIs I worked although most of them look like very simple. Especially if you do not have any WYSWYG editors. There are lots of thing you have to consider while moving old flex app to royale like 3rd party libraries etc. One less is preferable :) Thanks, Serkan 5.06.2020 13:17 tarihinde Greg Dove yazdı: Yeah I understand this is sometimes necessary Piotr. But the whole point of MXRoyale Flex emulation (and why it does appeal more to some) is that those changes should be much less because it matches more closely to Flex. This is certainly why my client is keen on it. I actually think if they had more time they might be interested in reworking/modernizing the UI, but that is not desirable at this point because it will delay things too much. The app is huge and they need to minimize changes in order to meet their deadlines. Also with MXRoyale, it is not usually a simple css fix for layout, maybe in some simple cases it can be, but mostly not I think, because a lot of MXRoyale layout is driven by code. On Fri, Jun 5, 2020 at 9:41 PM Piotr Zarzycki wrote: I think we need to sometimes let it go and just make changes to our original code. In our Jewel application we are preserving around 30% of code of ported Flex app, by our choice. The rest is just rewritten. Even in that rewritten code when I'm seeing some UI, layout issue - I don't waste huge amount of time if I can simply make it work by one line of CSS. It just allows you to move forward. I know it is hard sometimes convince the client to make the changes, but our job as a power users of this framework is educate also that Royale won't provide 100% conversion. Changes in the old code is in many cases inevitable. Thanks, Piotr pt., 5 cze 2020 o 11:36 Greg Dove napisał(a): thanks Serkan - you are right - I did not see that explanation earlier (just the screencaptures) which is why I asked my extra question. It sounds like it could be similar to what I was addressing, but I don't have a 'universal' solution (and possibly not even a 'good' selective solution, which is why I am keen for extra eyes on it), but it might be useful as-is, or possibly give Alex, you or anyone else some other approaches to consider. I am happy to collaborate on an approach once we settle on one that makes sense for all of us. On Fri, Jun 5, 2020 at 2:29 PM serkan wrote: I am not sure but I guess mail not sent to the list Greg :) My application heavily use states to manage visual layout Greg. Alex is working on the issues one by one as open an issue. They are mostly with percentage based. e.g. id="allJobDetail" height="100%"/> This component is the one et the center with name "İş Tüm Detay Formu" which is very ugly displayed in Royale. Some fix works at first like menu bar but as you can see when resize, it is broken again :) Thank Serkan 4.06.2020 13:08 tarihinde Greg Dove yazdı: Thanks Serkan, Do you think you are seeing the same type of issue I described? Are any of those controls being added either via states or via code at runtime into containers that have percentage based dimensions? I think that the changes I have won't break anyone's existing layouts, but I am not sure yet if I should push them as is to develop or not, because this is the first time I looked at emulation layout stuff. I do see improvements for the issues I have been facing, but there still might be more things that need attention, or I may not be addressing things in the right way. @aharui : when you get to see this, what do you think? Would you have time to take a look at this? And do you think I can push what I have to develop or should it go in a branch? (I can monkey patch my client project so we can use these 'fixes' for local progress in the interim if I need to). On Thu, Jun 4, 2020 at 8:52 PM serkan wrote: 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,
Re: MXRoyale layout issues - questions/discussion
Yeah I understand this is sometimes necessary Piotr. But the whole point of MXRoyale Flex emulation (and why it does appeal more to some) is that those changes should be much less because it matches more closely to Flex. This is certainly why my client is keen on it. I actually think if they had more time they might be interested in reworking/modernizing the UI, but that is not desirable at this point because it will delay things too much. The app is huge and they need to minimize changes in order to meet their deadlines. Also with MXRoyale, it is not usually a simple css fix for layout, maybe in some simple cases it can be, but mostly not I think, because a lot of MXRoyale layout is driven by code. On Fri, Jun 5, 2020 at 9:41 PM Piotr Zarzycki wrote: > I think we need to sometimes let it go and just make changes to our > original code. In our Jewel application we are preserving around 30% of > code of ported Flex app, by our choice. The rest is just rewritten. Even in > that rewritten code when I'm seeing some UI, layout issue - I don't waste > huge amount of time if I can simply make it work by one line of CSS. > > It just allows you to move forward. I know it is hard sometimes convince > the client to make the changes, but our job as a power users of this > framework is educate also that Royale won't provide 100% conversion. > Changes in the old code is in many cases inevitable. > > Thanks, > Piotr > > pt., 5 cze 2020 o 11:36 Greg Dove napisał(a): > > > > > thanks Serkan - you are right - I did not see that explanation earlier > > (just the screencaptures) which is why I asked my extra question. > > > > It sounds like it could be similar to what I was addressing, but I don't > > have a 'universal' solution (and possibly not even a 'good' selective > > solution, which is why I am keen for extra eyes on it), but it might be > > useful as-is, or possibly give Alex, you or anyone else some other > > approaches to consider. I am happy to collaborate on an approach once we > > settle on one that makes sense for all of us. > > > > > > On Fri, Jun 5, 2020 at 2:29 PM serkan wrote: > > > >> > >> I am not sure but I guess mail not sent to the list Greg :) > >> > >> My application heavily use states to manage visual layout Greg. Alex is > >> working on the issues one by one as open an issue. > >> > >> They are mostly with percentage based. > >> > >> e.g. > >> > >> id="allJobDetail" > >> height="100%"/> > >> > >> This component is the one et the center with name "İş Tüm Detay Formu" > >> which is very ugly displayed in Royale. > >> > >> Some fix works at first like menu bar but as you can see when resize, it > >> is broken again :) > >> > >> Thank > >> Serkan > >> > >> 4.06.2020 13:08 tarihinde Greg Dove yazdı: > >> > >> > >> Thanks Serkan, > >> > >> Do you think you are seeing the same type of issue I described? Are any > >> of those controls being added either via states or via code at runtime > into > >> containers that have percentage based dimensions? > >> > >> I think that the changes I have won't break anyone's existing layouts, > >> but I am not sure yet if I should push them as is to develop or not, > >> because this is the first time I looked at emulation layout stuff. > >> I do see improvements for the issues I have been facing, but there still > >> might be more things that need attention, or I may not be addressing > things > >> in the right way. > >> > >> @aharui : when you get to see this, what do you think? Would you have > >> time to take a look at this? And do you think I can push what I have to > >> develop or should it go in a branch? > >> (I can monkey patch my client project so we can use these 'fixes' for > >> local progress in the interim if I need to). > >> > >> > >> > >> > >> > >> > >> On Thu, Jun 4, 2020 at 8:52 PM serkan > wrote: > >> > >>> 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
Re: MXRoyale layout issues - questions/discussion
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" 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%23L131data=02%7C01%7Caharui%40adobe.com%7C6386a0b1feaa464dab7c08d808c9126c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269006974198657sdata=Mrz28G2QGTZDNSRqZuLyrHe52Q2yje7Y2qUZA%2BroK0k%3Dreserved=0
>
> On Fri, Jun 5, 2020 at 3:32 AM Alex Harui
> 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
> >
Re: MXRoyale layout issues - questions/discussion
I think we need to sometimes let it go and just make changes to our original code. In our Jewel application we are preserving around 30% of code of ported Flex app, by our choice. The rest is just rewritten. Even in that rewritten code when I'm seeing some UI, layout issue - I don't waste huge amount of time if I can simply make it work by one line of CSS. It just allows you to move forward. I know it is hard sometimes convince the client to make the changes, but our job as a power users of this framework is educate also that Royale won't provide 100% conversion. Changes in the old code is in many cases inevitable. Thanks, Piotr pt., 5 cze 2020 o 11:36 Greg Dove napisał(a): > > thanks Serkan - you are right - I did not see that explanation earlier > (just the screencaptures) which is why I asked my extra question. > > It sounds like it could be similar to what I was addressing, but I don't > have a 'universal' solution (and possibly not even a 'good' selective > solution, which is why I am keen for extra eyes on it), but it might be > useful as-is, or possibly give Alex, you or anyone else some other > approaches to consider. I am happy to collaborate on an approach once we > settle on one that makes sense for all of us. > > > On Fri, Jun 5, 2020 at 2:29 PM serkan wrote: > >> >> I am not sure but I guess mail not sent to the list Greg :) >> >> My application heavily use states to manage visual layout Greg. Alex is >> working on the issues one by one as open an issue. >> >> They are mostly with percentage based. >> >> e.g. >> >> > height="100%"/> >> >> This component is the one et the center with name "İş Tüm Detay Formu" >> which is very ugly displayed in Royale. >> >> Some fix works at first like menu bar but as you can see when resize, it >> is broken again :) >> >> Thank >> Serkan >> >> 4.06.2020 13:08 tarihinde Greg Dove yazdı: >> >> >> Thanks Serkan, >> >> Do you think you are seeing the same type of issue I described? Are any >> of those controls being added either via states or via code at runtime into >> containers that have percentage based dimensions? >> >> I think that the changes I have won't break anyone's existing layouts, >> but I am not sure yet if I should push them as is to develop or not, >> because this is the first time I looked at emulation layout stuff. >> I do see improvements for the issues I have been facing, but there still >> might be more things that need attention, or I may not be addressing things >> in the right way. >> >> @aharui : when you get to see this, what do you think? Would you have >> time to take a look at this? And do you think I can push what I have to >> develop or should it go in a branch? >> (I can monkey patch my client project so we can use these 'fixes' for >> local progress in the interim if I need to). >> >> >> >> >> >> >> On Thu, Jun 4, 2020 at 8:52 PM serkan wrote: >> >>> 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 >>> >>> >>> 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
Re: MXRoyale layout issues - questions/discussion
thanks Serkan - you are right - I did not see that explanation earlier
(just the screencaptures) which is why I asked my extra question.
It sounds like it could be similar to what I was addressing, but I don't
have a 'universal' solution (and possibly not even a 'good' selective
solution, which is why I am keen for extra eyes on it), but it might be
useful as-is, or possibly give Alex, you or anyone else some other
approaches to consider. I am happy to collaborate on an approach once we
settle on one that makes sense for all of us.
On Fri, Jun 5, 2020 at 2:29 PM serkan wrote:
>
> I am not sure but I guess mail not sent to the list Greg :)
>
> My application heavily use states to manage visual layout Greg. Alex is
> working on the issues one by one as open an issue.
>
> They are mostly with percentage based.
>
> e.g.
>
> height="100%"/>
>
> This component is the one et the center with name "İş Tüm Detay Formu"
> which is very ugly displayed in Royale.
>
> Some fix works at first like menu bar but as you can see when resize, it
> is broken again :)
>
> Thank
> Serkan
>
> 4.06.2020 13:08 tarihinde Greg Dove yazdı:
>
>
> Thanks Serkan,
>
> Do you think you are seeing the same type of issue I described? Are any of
> those controls being added either via states or via code at runtime into
> containers that have percentage based dimensions?
>
> I think that the changes I have won't break anyone's existing layouts, but
> I am not sure yet if I should push them as is to develop or not, because
> this is the first time I looked at emulation layout stuff.
> I do see improvements for the issues I have been facing, but there still
> might be more things that need attention, or I may not be addressing things
> in the right way.
>
> @aharui : when you get to see this, what do you think? Would you have time
> to take a look at this? And do you think I can push what I have to develop
> or should it go in a branch?
> (I can monkey patch my client project so we can use these 'fixes' for
> local progress in the interim if I need to).
>
>
>
>
>
>
> On Thu, Jun 4, 2020 at 8:52 PM serkan wrote:
>
>> 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
>>
>>
>> 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);
>>
Re: MXRoyale layout issues - questions/discussion
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%23L131data=02%7C01%7Caharui%40adobe.com%7C6386a0b1feaa464dab7c08d808c9126c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269006974198657sdata=Mrz28G2QGTZDNSRqZuLyrHe52Q2yje7Y2qUZA%2BroK0k%3Dreserved=0 On Fri, Jun 5, 2020 at 3:32 AM Alex Harui 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 > Reply-To: "dev@royale.apache.org" > Date: Thursday, June 4, 2020 at 4:30 AM > To: "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 > Sent: Thursday, June 4, 2020 11:12:08 AM > To: Apache Royale Development > 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 > > > 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 'Container
Re: MXRoyale layout issues - questions/discussion
'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 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 > Reply-To: "dev@royale.apache.org" > Date: Thursday, June 4, 2020 at 4:30 AM > To: "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 > Sent: Thursday, June 4, 2020 11:12:08 AM > To: Apache Royale Development > 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 > > > 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
Re: MXRoyale layout issues - questions/discussion
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
Reply-To: "dev@royale.apache.org"
Date: Thursday, June 4, 2020 at 4:30 AM
To: "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
Sent: Thursday, June 4, 2020 11:12:08 AM
To: Apache Royale Development
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
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(conta
Re: MXRoyale layout issues - questions/discussion
> > 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 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 > *Sent:* Thursday, June 4, 2020 11:12:08 AM > *To:* Apache Royale Development > *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 > > > 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
Re: MXRoyale layout issues - questions/discussion
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
Reply-To: "dev@royale.apache.org"
Date: Thursday, June 4, 2020 at 4:30 AM
To: "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
Sent: Thursday, June 4, 2020 11:12:08 AM
To: Apache Royale Development
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
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
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
Sent: Thursday, June 4, 2020 11:12:08 AM
To: Apache Royale Development
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
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
