>> layout
> >> > > >> > loops.
> >> > > >> >
> >> > > >> > Usually, in Flex, a componen
there is no
>> > > >> > code looking for changes that should trigger a
>> layout
>> > other
>> > > than
>> > > >> possibly
&g
t my
>> > > >> understanding.
>> > > >>
>> > > >>
>> > > >> > In Royale, there is little to no measurement
&
ods from Flex, but they don't always get run
> because
> > > there is no
> > > >> > LayoutManager measuring the children before the
> parents
> > and
> > > existing
> > &g
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
t; >> if (layout) {
> > >> layout.measure();
> > >> }
> > >> containerContents.layoutNeeded();
> > >>
> > >> Note: calling measure() explicitly like that
t.'
> >> >
> >> > 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
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
&g
> 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
> 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
2Fmain%2Froyale%2Forg%2Fapache%2Froyale%2Fcore%2FLayoutBase.as%23L131&data=02%7C01%7Caharui%40adobe.com%7C34080cf90f504c1b7ef508d809380095%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637269483425406744&sdata=na2D5dkZziw7na8WuNrz%2FRIJzphWgVEVmGX64aPJ1UA%3D&reserved=0
> >
>
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
&g
+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.
On
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
mo
t 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.
> >
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 amou
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 i
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@
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 GitH
t;
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 childr
>
> 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
: 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
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 se
23 matches
Mail list logo
