Re: What is x and y? What is width and height?

[Harbs]

>> documentation much easier.  I'm all for options, but making fundamental
>>>> things like geometry have options seems like it would make Royale seem
>>>> more complex.
>>>> 
>>>> I would not worry about performance until it actually proves to be a
>>>> problem.  Clearly, most of our examples do not read x/y/width/height at
>>>> all or very often otherwise we'd have many more layout issues.  Most of
>>>> the UI widgets are designed to let the Browser do the layout.  So, of
>>>> only
>>>> a small percentage of the UI widgets need x,y,w,h, then it is unlikely
>>>> to
>>>> affect performance.
>>>> 
>>>> Also on the JS side we do have the option of overwriting code if we need
>>>> to for folks using transforms and SVG.
>>>> 
>>>> People will be porting their Flex apps where they have x,y,width,height
>>>> expectations.  Even if it costs a little bit more, it seems like in the
>>>> few places they really need it, it should work like it did in Flex.
>>>> 
>>>> My 2 cents,
>>>> -Alex
>>>> 
>>>> On 2/8/18, 6:50 AM, "carlos.rov...@gmail.com 
>>>> <mailto:carlos.rov...@gmail.com> on behalf of Carlos Rovira"
>>>> mailto:carlos.rov...@gmail.com> on behalf of 
>>>> carlosrov...@apache.org <mailto:carlosrov...@apache.org>> wrote:
>>>> 
>>>>> Seems more reasonable, since its optional and people wanting it can
>>>>> include...
>>>>> 
>>>>> 2018-02-08 14:04 GMT+01:00 Piotr Zarzycki >>>> <mailto:piotrzarzyck...@gmail.com>>:
>>>>> 
>>>>>> I personally prefer having Bead for such things.
>>>>>> 
>>>>>> 2018-02-08 14:01 GMT+01:00 Yishay Weiss >>>>> <mailto:yishayj...@hotmail.com>>:
>>>>>> 
>>>>>>> I agree, that’s why I’m proposing to have a bead do the
>>>> calculation.
>>>>>> If
>>>>>>> you care about integrity with actual position on the screen and are
>>>>>> willing
>>>>>>> to sacrifice some performance use ScreenPositionCalculatorBead,
>>>>>> otherwise
>>>>>>> use the default which is more performance oriented.
>>>>>>> 
>>>>>>> Another option is to just use a utility function for calculating
>>>> that
>>>>>>> actual screen position when necessary. The util function can get
>>>> the
>>>>>>> element using (component as IRenderedObject).element and then do
>>>>>> whatever
>>>>>>> DOM/flash/wasm queries you need.
>>>>>>> 
>>>>>>> From: Carlos Rovira<mailto:carlosrov...@apache.org 
>>>>>>> <mailto:carlosrov...@apache.org>>
>>>>>>> Sent: Thursday, February 8, 2018 12:33 PM
>>>>>>> To: dev@royale.apache.org 
>>>>>>> <mailto:dev@royale.apache.org><mailto:dev@royale.apache.org 
>>>>>>> <mailto:dev@royale.apache.org>>
>>>>>>> Subject: Re: What is x and y? What is width and height?
>>>>>>> 
>>>>>>> I don't have right now a proposal for this, but it seems to me that
>>>>>>> introduce calculations that affects performance will be a bad idea.
>>>>>> That
>>>>>>> will make us not elegible for some escenarios/people. On e of the
>>>>>> things
>>>>>> I
>>>>>>> like from Royale is that in the end we are outputting the most easy
>>>>>> code
>>>>>>> while we are making it easy for coders through MXML/AS3.
>>>>>>> I think we should look the problem in other perspective to avoid
>>>>>> impacts
>>>>>> in
>>>>>>> performance
>>>>>>> 
>>>>>>> 2018-02-08 7:26 GMT+01:00 Yishay Weiss >>>>>> <mailto:yishayj...@hotmail.com>>:
>>>>>>> 
>>>>>>>> How about using beads that implement IPositionCalculator. UIBase
>>>>>> won’t
>>>>>>>> return x and y directly but use a bead to calculate them. The
>>>>>> default
>>>>>>>> SimplePositionCalculatorBead would 

Re: What is x and y? What is width and height?

[Alex Harui]

In most cases we do output the most basic code.  But let's look at one
scenario I expect to run into more than once, which is placing a popup
somewhere.

Like I said, in most of our code, we rarely read back x and y.  I don't
even think we read x and y in an absolute positioning container.  But I
would imagine there is a fair number of places in existing Flex apps that
do something like:

// center tooltip horizontally
Var tt:FancyToolTip = new FancyToolTip();
...
tt.x = MyWidget.x + MyWidget.width / 2.

This simple example does not work today.  I am proposing it should work
for non-transformed UI.  I think we can make it work.  We can provide
alternative ways of doing it by abstracting the calculation into utility
functions but it just seems strange to me that UI widgets should not have
x,y properties that work like they do in Flex/Flash.  But you are right,
we do have the option of not having x,y on our UI widgets.

Another scenario may be as we write more effects.  They may have similar
issues picking starting points.  I think this might be an issue of how
easy we make it for folks to migrate.  The calculation for x and y is just
subtracting the container's offsetLeft or offsetTop from the component's
offsetLeft or offsetTop so one extra read of a property.  Of course, I
could be wrong about that.

My 2 cents,
-Alex

On 2/8/18, 10:45 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>in this case it's hard to prove this will be a problem. Maybe the apps
>will
>suffer it very slightly for most people to perceive it, but that's not the
>problem. The problem is our solution will have additional calculations
>*always* that other frameworks doesn't have. And that's goes against our
>principle in JS to output the most basic js code we can since we'll end
>with some strange code only introduced to match a developer time way of
>doing things.
>
>So for that reason I think most people on this thread are saying this is
>not a good idea and we should rethink it before make it real.
>
>just my 2...
>
>Carlos
>
>
>
>
>2018-02-08 18:55 GMT+01:00 Alex Harui :
>
>> I would much rather we decide on an implementation.  It makes
>> documentation much easier.  I'm all for options, but making fundamental
>> things like geometry have options seems like it would make Royale seem
>> more complex.
>>
>> I would not worry about performance until it actually proves to be a
>> problem.  Clearly, most of our examples do not read x/y/width/height at
>> all or very often otherwise we'd have many more layout issues.  Most of
>> the UI widgets are designed to let the Browser do the layout.  So, of
>>only
>> a small percentage of the UI widgets need x,y,w,h, then it is unlikely
>>to
>> affect performance.
>>
>> Also on the JS side we do have the option of overwriting code if we need
>> to for folks using transforms and SVG.
>>
>> People will be porting their Flex apps where they have x,y,width,height
>> expectations.  Even if it costs a little bit more, it seems like in the
>> few places they really need it, it should work like it did in Flex.
>>
>> My 2 cents,
>> -Alex
>>
>> On 2/8/18, 6:50 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>>  wrote:
>>
>> >Seems more reasonable, since its optional and people wanting it can
>> >include...
>> >
>> >2018-02-08 14:04 GMT+01:00 Piotr Zarzycki :
>> >
>> >> I personally prefer having Bead for such things.
>> >>
>> >> 2018-02-08 14:01 GMT+01:00 Yishay Weiss :
>> >>
>> >> > I agree, that’s why I’m proposing to have a bead do the
>>calculation.
>> >>If
>> >> > you care about integrity with actual position on the screen and are
>> >> willing
>> >> > to sacrifice some performance use ScreenPositionCalculatorBead,
>> >>otherwise
>> >> > use the default which is more performance oriented.
>> >> >
>> >> > Another option is to just use a utility function for calculating
>>that
>> >> > actual screen position when necessary. The util function can get
>>the
>> >> > element using (component as IRenderedObject).element and then do
>> >>whatever
>> >> > DOM/flash/wasm queries you need.
>> >> >
>> >> > From: Carlos Rovira<mailto:carlosrov...@apache.org>
>> >> > Sent: Thursday, February 8, 2018 12:33 PM
>> >> > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
>> >> > Subject: R

Re: What is x and y? What is width and height?

[Carlos Rovira]

Hi Alex,

in this case it's hard to prove this will be a problem. Maybe the apps will
suffer it very slightly for most people to perceive it, but that's not the
problem. The problem is our solution will have additional calculations
*always* that other frameworks doesn't have. And that's goes against our
principle in JS to output the most basic js code we can since we'll end
with some strange code only introduced to match a developer time way of
doing things.

So for that reason I think most people on this thread are saying this is
not a good idea and we should rethink it before make it real.

just my 2...

Carlos




2018-02-08 18:55 GMT+01:00 Alex Harui :

> I would much rather we decide on an implementation.  It makes
> documentation much easier.  I'm all for options, but making fundamental
> things like geometry have options seems like it would make Royale seem
> more complex.
>
> I would not worry about performance until it actually proves to be a
> problem.  Clearly, most of our examples do not read x/y/width/height at
> all or very often otherwise we'd have many more layout issues.  Most of
> the UI widgets are designed to let the Browser do the layout.  So, of only
> a small percentage of the UI widgets need x,y,w,h, then it is unlikely to
> affect performance.
>
> Also on the JS side we do have the option of overwriting code if we need
> to for folks using transforms and SVG.
>
> People will be porting their Flex apps where they have x,y,width,height
> expectations.  Even if it costs a little bit more, it seems like in the
> few places they really need it, it should work like it did in Flex.
>
> My 2 cents,
> -Alex
>
> On 2/8/18, 6:50 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Seems more reasonable, since its optional and people wanting it can
> >include...
> >
> >2018-02-08 14:04 GMT+01:00 Piotr Zarzycki :
> >
> >> I personally prefer having Bead for such things.
> >>
> >> 2018-02-08 14:01 GMT+01:00 Yishay Weiss :
> >>
> >> > I agree, that’s why I’m proposing to have a bead do the calculation.
> >>If
> >> > you care about integrity with actual position on the screen and are
> >> willing
> >> > to sacrifice some performance use ScreenPositionCalculatorBead,
> >>otherwise
> >> > use the default which is more performance oriented.
> >> >
> >> > Another option is to just use a utility function for calculating that
> >> > actual screen position when necessary. The util function can get the
> >> > element using (component as IRenderedObject).element and then do
> >>whatever
> >> > DOM/flash/wasm queries you need.
> >> >
> >> > From: Carlos Rovira<mailto:carlosrov...@apache.org>
> >> > Sent: Thursday, February 8, 2018 12:33 PM
> >> > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> >> > Subject: Re: What is x and y? What is width and height?
> >> >
> >> > I don't have right now a proposal for this, but it seems to me that
> >> > introduce calculations that affects performance will be a bad idea.
> >>That
> >> > will make us not elegible for some escenarios/people. On e of the
> >>things
> >> I
> >> > like from Royale is that in the end we are outputting the most easy
> >>code
> >> > while we are making it easy for coders through MXML/AS3.
> >> > I think we should look the problem in other perspective to avoid
> >>impacts
> >> in
> >> > performance
> >> >
> >> > 2018-02-08 7:26 GMT+01:00 Yishay Weiss :
> >> >
> >> > > How about using beads that implement IPositionCalculator. UIBase
> >>won’t
> >> > > return x and y directly but use a bead to calculate them. The
> >>default
> >> > > SimplePositionCalculatorBead would return x and y based on the
> >>setter
> >> > while
> >> > > the ScreenPositionCalculatorBead would return the values based on
> >>DOM
> >> > > access.
> >> > >
> >> > > From: Gabe Harbs<mailto:harbs.li...@gmail.com>
> >> > > Sent: Wednesday, February 7, 2018 6:24 PM
> >> > > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> >> > > Subject: Re: What is x and y? What is width and height?
> >> > >
> >> > > FWIW, I do think we need a “constrained layout” which places
> >> *everything*
> >> > > absolu

Re: What is x and y? What is width and height?

[Alex Harui]

I would much rather we decide on an implementation.  It makes
documentation much easier.  I'm all for options, but making fundamental
things like geometry have options seems like it would make Royale seem
more complex.

I would not worry about performance until it actually proves to be a
problem.  Clearly, most of our examples do not read x/y/width/height at
all or very often otherwise we'd have many more layout issues.  Most of
the UI widgets are designed to let the Browser do the layout.  So, of only
a small percentage of the UI widgets need x,y,w,h, then it is unlikely to
affect performance.

Also on the JS side we do have the option of overwriting code if we need
to for folks using transforms and SVG.

People will be porting their Flex apps where they have x,y,width,height
expectations.  Even if it costs a little bit more, it seems like in the
few places they really need it, it should work like it did in Flex.

My 2 cents,
-Alex

On 2/8/18, 6:50 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Seems more reasonable, since its optional and people wanting it can
>include...
>
>2018-02-08 14:04 GMT+01:00 Piotr Zarzycki :
>
>> I personally prefer having Bead for such things.
>>
>> 2018-02-08 14:01 GMT+01:00 Yishay Weiss :
>>
>> > I agree, that’s why I’m proposing to have a bead do the calculation.
>>If
>> > you care about integrity with actual position on the screen and are
>> willing
>> > to sacrifice some performance use ScreenPositionCalculatorBead,
>>otherwise
>> > use the default which is more performance oriented.
>> >
>> > Another option is to just use a utility function for calculating that
>> > actual screen position when necessary. The util function can get the
>> > element using (component as IRenderedObject).element and then do
>>whatever
>> > DOM/flash/wasm queries you need.
>> >
>> > From: Carlos Rovira<mailto:carlosrov...@apache.org>
>> > Sent: Thursday, February 8, 2018 12:33 PM
>> > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
>> > Subject: Re: What is x and y? What is width and height?
>> >
>> > I don't have right now a proposal for this, but it seems to me that
>> > introduce calculations that affects performance will be a bad idea.
>>That
>> > will make us not elegible for some escenarios/people. On e of the
>>things
>> I
>> > like from Royale is that in the end we are outputting the most easy
>>code
>> > while we are making it easy for coders through MXML/AS3.
>> > I think we should look the problem in other perspective to avoid
>>impacts
>> in
>> > performance
>> >
>> > 2018-02-08 7:26 GMT+01:00 Yishay Weiss :
>> >
>> > > How about using beads that implement IPositionCalculator. UIBase
>>won’t
>> > > return x and y directly but use a bead to calculate them. The
>>default
>> > > SimplePositionCalculatorBead would return x and y based on the
>>setter
>> > while
>> > > the ScreenPositionCalculatorBead would return the values based on
>>DOM
>> > > access.
>> > >
>> > > From: Gabe Harbs<mailto:harbs.li...@gmail.com>
>> > > Sent: Wednesday, February 7, 2018 6:24 PM
>> > > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
>> > > Subject: Re: What is x and y? What is width and height?
>> > >
>> > > FWIW, I do think we need a “constrained layout” which places
>> *everything*
>> > > absolutely and does not rely on browser layout. If that layout were
>>to
>> be
>> > > used, the bounding box values would be correct.
>> > >
>> > > > On Feb 7, 2018, at 6:00 PM, Peter Ent 
>> wrote:
>> > > >
>> > > > I think I agree with Harbs about x,y,width,height just returning
>>the
>> > set
>> > > > values if the calculation would be expensive. I wonder what the
>> > > > circumstances are that we actually need to have precise values in
>> > > > calculations. For example, if I wanted to make a circulate layout,
>> how
>> > > > would I go about doing that?
>> > > >
>> > > > In the places I've done layouts without regard to platform I'm
>>just
>> > > > assuming things work. For example, in the DataGridLayout, I need
>>to
>> > > > transfer the column width given on the js:DataGridColumn
>>definition
>> to
>> > > > both the List (column) and the c

Re: What is x and y? What is width and height?

[Carlos Rovira]

Seems more reasonable, since its optional and people wanting it can
include...

2018-02-08 14:04 GMT+01:00 Piotr Zarzycki :

> I personally prefer having Bead for such things.
>
> 2018-02-08 14:01 GMT+01:00 Yishay Weiss :
>
> > I agree, that’s why I’m proposing to have a bead do the calculation. If
> > you care about integrity with actual position on the screen and are
> willing
> > to sacrifice some performance use ScreenPositionCalculatorBead, otherwise
> > use the default which is more performance oriented.
> >
> > Another option is to just use a utility function for calculating that
> > actual screen position when necessary. The util function can get the
> > element using (component as IRenderedObject).element and then do whatever
> > DOM/flash/wasm queries you need.
> >
> > From: Carlos Rovira<mailto:carlosrov...@apache.org>
> > Sent: Thursday, February 8, 2018 12:33 PM
> > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> > Subject: Re: What is x and y? What is width and height?
> >
> > I don't have right now a proposal for this, but it seems to me that
> > introduce calculations that affects performance will be a bad idea. That
> > will make us not elegible for some escenarios/people. On e of the things
> I
> > like from Royale is that in the end we are outputting the most easy code
> > while we are making it easy for coders through MXML/AS3.
> > I think we should look the problem in other perspective to avoid impacts
> in
> > performance
> >
> > 2018-02-08 7:26 GMT+01:00 Yishay Weiss :
> >
> > > How about using beads that implement IPositionCalculator. UIBase won’t
> > > return x and y directly but use a bead to calculate them. The default
> > > SimplePositionCalculatorBead would return x and y based on the setter
> > while
> > > the ScreenPositionCalculatorBead would return the values based on DOM
> > > access.
> > >
> > > From: Gabe Harbs<mailto:harbs.li...@gmail.com>
> > > Sent: Wednesday, February 7, 2018 6:24 PM
> > > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> > > Subject: Re: What is x and y? What is width and height?
> > >
> > > FWIW, I do think we need a “constrained layout” which places
> *everything*
> > > absolutely and does not rely on browser layout. If that layout were to
> be
> > > used, the bounding box values would be correct.
> > >
> > > > On Feb 7, 2018, at 6:00 PM, Peter Ent 
> wrote:
> > > >
> > > > I think I agree with Harbs about x,y,width,height just returning the
> > set
> > > > values if the calculation would be expensive. I wonder what the
> > > > circumstances are that we actually need to have precise values in
> > > > calculations. For example, if I wanted to make a circulate layout,
> how
> > > > would I go about doing that?
> > > >
> > > > In the places I've done layouts without regard to platform I'm just
> > > > assuming things work. For example, in the DataGridLayout, I need to
> > > > transfer the column width given on the js:DataGridColumn definition
> to
> > > > both the List (column) and the corresponding Button in the ButtonBar.
> > > > Ideally, the browser takes that (along with display and position
> > styles)
> > > > and just does the right thing with minimum code on our part (that's
> not
> > > > actually what I'm doing, so perhaps I should rethink that one more
> > time).
> > > >
> > > > ‹peter
> > > >
> > > > On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
> > > >
> > > >> The offset values are very expensive.
> > > >>
> > > >> They are also not completely accurate. I¹ve found it¹s difficult to
> > get
> > > >> accurate values where SVG and transforms are in play.
> > > >>
> > > >> I would suggest that x,y,widht and height should reflect *set*
> values
> > > >> even if they are not always the actual ones.
> > > >>
> > > >> For cases where it¹s necessary to get accurate measured x,y,width
> and
> > > >> height, I would suggest using ³measured² variations of these values,
> > or
> > > >> better, a getMeasuredBounds() method.
> > > >>
> > > >>> On Feb 7, 2018, at 10:43 AM, Alex Harui 
> > > >>> wrote:
> > > >>>
> > > >>> Hi,
> > >

Re: What is x and y? What is width and height?

[Piotr Zarzycki]

I personally prefer having Bead for such things.

2018-02-08 14:01 GMT+01:00 Yishay Weiss :

> I agree, that’s why I’m proposing to have a bead do the calculation. If
> you care about integrity with actual position on the screen and are willing
> to sacrifice some performance use ScreenPositionCalculatorBead, otherwise
> use the default which is more performance oriented.
>
> Another option is to just use a utility function for calculating that
> actual screen position when necessary. The util function can get the
> element using (component as IRenderedObject).element and then do whatever
> DOM/flash/wasm queries you need.
>
> From: Carlos Rovira<mailto:carlosrov...@apache.org>
> Sent: Thursday, February 8, 2018 12:33 PM
> To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> Subject: Re: What is x and y? What is width and height?
>
> I don't have right now a proposal for this, but it seems to me that
> introduce calculations that affects performance will be a bad idea. That
> will make us not elegible for some escenarios/people. On e of the things I
> like from Royale is that in the end we are outputting the most easy code
> while we are making it easy for coders through MXML/AS3.
> I think we should look the problem in other perspective to avoid impacts in
> performance
>
> 2018-02-08 7:26 GMT+01:00 Yishay Weiss :
>
> > How about using beads that implement IPositionCalculator. UIBase won’t
> > return x and y directly but use a bead to calculate them. The default
> > SimplePositionCalculatorBead would return x and y based on the setter
> while
> > the ScreenPositionCalculatorBead would return the values based on DOM
> > access.
> >
> > From: Gabe Harbs<mailto:harbs.li...@gmail.com>
> > Sent: Wednesday, February 7, 2018 6:24 PM
> > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> > Subject: Re: What is x and y? What is width and height?
> >
> > FWIW, I do think we need a “constrained layout” which places *everything*
> > absolutely and does not rely on browser layout. If that layout were to be
> > used, the bounding box values would be correct.
> >
> > > On Feb 7, 2018, at 6:00 PM, Peter Ent  wrote:
> > >
> > > I think I agree with Harbs about x,y,width,height just returning the
> set
> > > values if the calculation would be expensive. I wonder what the
> > > circumstances are that we actually need to have precise values in
> > > calculations. For example, if I wanted to make a circulate layout, how
> > > would I go about doing that?
> > >
> > > In the places I've done layouts without regard to platform I'm just
> > > assuming things work. For example, in the DataGridLayout, I need to
> > > transfer the column width given on the js:DataGridColumn definition to
> > > both the List (column) and the corresponding Button in the ButtonBar.
> > > Ideally, the browser takes that (along with display and position
> styles)
> > > and just does the right thing with minimum code on our part (that's not
> > > actually what I'm doing, so perhaps I should rethink that one more
> time).
> > >
> > > ‹peter
> > >
> > > On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
> > >
> > >> The offset values are very expensive.
> > >>
> > >> They are also not completely accurate. I¹ve found it¹s difficult to
> get
> > >> accurate values where SVG and transforms are in play.
> > >>
> > >> I would suggest that x,y,widht and height should reflect *set* values
> > >> even if they are not always the actual ones.
> > >>
> > >> For cases where it¹s necessary to get accurate measured x,y,width and
> > >> height, I would suggest using ³measured² variations of these values,
> or
> > >> better, a getMeasuredBounds() method.
> > >>
> > >>> On Feb 7, 2018, at 10:43 AM, Alex Harui 
> > >>> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> In Royale on JS, we are trying to leverage the browser's layout code
> as
> > >>> much as possible.  We only run our own layout code in a few places.
> > >>> In debugging a few layout issues I discovered that UIBase is not
> > >>> reporting
> > >>> x and y the way we expect it from Flex/Flash.  Browser elements don't
> > >>> have
> > >>> x and y properties, instead they have offsetLeft and offsetTop.
> Mainly
> > >>> for backward-compatibility with Flex

RE: What is x and y? What is width and height?

[Yishay Weiss]

I agree, that’s why I’m proposing to have a bead do the calculation. If you 
care about integrity with actual position on the screen and are willing to 
sacrifice some performance use ScreenPositionCalculatorBead, otherwise use the 
default which is more performance oriented.

Another option is to just use a utility function for calculating that actual 
screen position when necessary. The util function can get the element using 
(component as IRenderedObject).element and then do whatever DOM/flash/wasm 
queries you need.

From: Carlos Rovira<mailto:carlosrov...@apache.org>
Sent: Thursday, February 8, 2018 12:33 PM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: What is x and y? What is width and height?

I don't have right now a proposal for this, but it seems to me that
introduce calculations that affects performance will be a bad idea. That
will make us not elegible for some escenarios/people. On e of the things I
like from Royale is that in the end we are outputting the most easy code
while we are making it easy for coders through MXML/AS3.
I think we should look the problem in other perspective to avoid impacts in
performance

2018-02-08 7:26 GMT+01:00 Yishay Weiss :

> How about using beads that implement IPositionCalculator. UIBase won’t
> return x and y directly but use a bead to calculate them. The default
> SimplePositionCalculatorBead would return x and y based on the setter while
> the ScreenPositionCalculatorBead would return the values based on DOM
> access.
>
> From: Gabe Harbs<mailto:harbs.li...@gmail.com>
> Sent: Wednesday, February 7, 2018 6:24 PM
> To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> Subject: Re: What is x and y? What is width and height?
>
> FWIW, I do think we need a “constrained layout” which places *everything*
> absolutely and does not rely on browser layout. If that layout were to be
> used, the bounding box values would be correct.
>
> > On Feb 7, 2018, at 6:00 PM, Peter Ent  wrote:
> >
> > I think I agree with Harbs about x,y,width,height just returning the set
> > values if the calculation would be expensive. I wonder what the
> > circumstances are that we actually need to have precise values in
> > calculations. For example, if I wanted to make a circulate layout, how
> > would I go about doing that?
> >
> > In the places I've done layouts without regard to platform I'm just
> > assuming things work. For example, in the DataGridLayout, I need to
> > transfer the column width given on the js:DataGridColumn definition to
> > both the List (column) and the corresponding Button in the ButtonBar.
> > Ideally, the browser takes that (along with display and position styles)
> > and just does the right thing with minimum code on our part (that's not
> > actually what I'm doing, so perhaps I should rethink that one more time).
> >
> > ‹peter
> >
> > On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
> >
> >> The offset values are very expensive.
> >>
> >> They are also not completely accurate. I¹ve found it¹s difficult to get
> >> accurate values where SVG and transforms are in play.
> >>
> >> I would suggest that x,y,widht and height should reflect *set* values
> >> even if they are not always the actual ones.
> >>
> >> For cases where it¹s necessary to get accurate measured x,y,width and
> >> height, I would suggest using ³measured² variations of these values, or
> >> better, a getMeasuredBounds() method.
> >>
> >>> On Feb 7, 2018, at 10:43 AM, Alex Harui 
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> In Royale on JS, we are trying to leverage the browser's layout code as
> >>> much as possible.  We only run our own layout code in a few places.
> >>> In debugging a few layout issues I discovered that UIBase is not
> >>> reporting
> >>> x and y the way we expect it from Flex/Flash.  Browser elements don't
> >>> have
> >>> x and y properties, instead they have offsetLeft and offsetTop.  Mainly
> >>> for backward-compatibility with Flex/Flash, Royale has had x and y in
> >>> the
> >>> API since the beginning.  I think it is a bug that x and y do not act
> >>> like
> >>> they do in Flex and plan to fix that after this release.  Thoughts?
> >>> I'm a
> >>> bit concerned of the expense of calculating x and y because you have to
> >>> check if the offsetParent is your immediate parent and get the
> >>> offsetLeft/offsetTop of the immediate parent, but I think that's wha

Re: What is x and y? What is width and height?

[Carlos Rovira]

I don't have right now a proposal for this, but it seems to me that
introduce calculations that affects performance will be a bad idea. That
will make us not elegible for some escenarios/people. On e of the things I
like from Royale is that in the end we are outputting the most easy code
while we are making it easy for coders through MXML/AS3.
I think we should look the problem in other perspective to avoid impacts in
performance

2018-02-08 7:26 GMT+01:00 Yishay Weiss :

> How about using beads that implement IPositionCalculator. UIBase won’t
> return x and y directly but use a bead to calculate them. The default
> SimplePositionCalculatorBead would return x and y based on the setter while
> the ScreenPositionCalculatorBead would return the values based on DOM
> access.
>
> From: Gabe Harbs<mailto:harbs.li...@gmail.com>
> Sent: Wednesday, February 7, 2018 6:24 PM
> To: dev@royale.apache.org<mailto:dev@royale.apache.org>
> Subject: Re: What is x and y? What is width and height?
>
> FWIW, I do think we need a “constrained layout” which places *everything*
> absolutely and does not rely on browser layout. If that layout were to be
> used, the bounding box values would be correct.
>
> > On Feb 7, 2018, at 6:00 PM, Peter Ent  wrote:
> >
> > I think I agree with Harbs about x,y,width,height just returning the set
> > values if the calculation would be expensive. I wonder what the
> > circumstances are that we actually need to have precise values in
> > calculations. For example, if I wanted to make a circulate layout, how
> > would I go about doing that?
> >
> > In the places I've done layouts without regard to platform I'm just
> > assuming things work. For example, in the DataGridLayout, I need to
> > transfer the column width given on the js:DataGridColumn definition to
> > both the List (column) and the corresponding Button in the ButtonBar.
> > Ideally, the browser takes that (along with display and position styles)
> > and just does the right thing with minimum code on our part (that's not
> > actually what I'm doing, so perhaps I should rethink that one more time).
> >
> > ‹peter
> >
> > On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
> >
> >> The offset values are very expensive.
> >>
> >> They are also not completely accurate. I¹ve found it¹s difficult to get
> >> accurate values where SVG and transforms are in play.
> >>
> >> I would suggest that x,y,widht and height should reflect *set* values
> >> even if they are not always the actual ones.
> >>
> >> For cases where it¹s necessary to get accurate measured x,y,width and
> >> height, I would suggest using ³measured² variations of these values, or
> >> better, a getMeasuredBounds() method.
> >>
> >>> On Feb 7, 2018, at 10:43 AM, Alex Harui 
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> In Royale on JS, we are trying to leverage the browser's layout code as
> >>> much as possible.  We only run our own layout code in a few places.
> >>> In debugging a few layout issues I discovered that UIBase is not
> >>> reporting
> >>> x and y the way we expect it from Flex/Flash.  Browser elements don't
> >>> have
> >>> x and y properties, instead they have offsetLeft and offsetTop.  Mainly
> >>> for backward-compatibility with Flex/Flash, Royale has had x and y in
> >>> the
> >>> API since the beginning.  I think it is a bug that x and y do not act
> >>> like
> >>> they do in Flex and plan to fix that after this release.  Thoughts?
> >>> I'm a
> >>> bit concerned of the expense of calculating x and y because you have to
> >>> check if the offsetParent is your immediate parent and get the
> >>> offsetLeft/offsetTop of the immediate parent, but I think that's what
> it
> >>> would take to fix it.
> >>>
> >>> Similarly (well, sort of), Flex did not support CSS margins, only
> >>> padding.
> >>> The browser reports width (offsetWidth) as factoring in content,
> padding
> >>> and borders, but not margin.  I think that's right, and matches Flex.
> >>> However, our custom layout algorithms do not currently factor in
> margins
> >>> since they are not reported in width.  I think our custom layout should
> >>> request width and margins and do the math.  We should not change width
> >>> to
> >>> include margins.  Thoughts?  This will make our custom layout code a
> bit
> >>> more expensive as well as it will probably need to call
> >>> getComputedStyles() on all of the children in order to get margins.
> >>> This
> >>> is also something to fix in the next release.
> >>>
> >>> Of course, I could be wrong.  Thoughts?
> >>>
> >>> -Alex
> >>>
> >>
> >
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

RE: What is x and y? What is width and height?

[Yishay Weiss]

How about using beads that implement IPositionCalculator. UIBase won’t return x 
and y directly but use a bead to calculate them. The default 
SimplePositionCalculatorBead would return x and y based on the setter while the 
ScreenPositionCalculatorBead would return the values based on DOM access.

From: Gabe Harbs<mailto:harbs.li...@gmail.com>
Sent: Wednesday, February 7, 2018 6:24 PM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: What is x and y? What is width and height?

FWIW, I do think we need a “constrained layout” which places *everything* 
absolutely and does not rely on browser layout. If that layout were to be used, 
the bounding box values would be correct.

> On Feb 7, 2018, at 6:00 PM, Peter Ent  wrote:
>
> I think I agree with Harbs about x,y,width,height just returning the set
> values if the calculation would be expensive. I wonder what the
> circumstances are that we actually need to have precise values in
> calculations. For example, if I wanted to make a circulate layout, how
> would I go about doing that?
>
> In the places I've done layouts without regard to platform I'm just
> assuming things work. For example, in the DataGridLayout, I need to
> transfer the column width given on the js:DataGridColumn definition to
> both the List (column) and the corresponding Button in the ButtonBar.
> Ideally, the browser takes that (along with display and position styles)
> and just does the right thing with minimum code on our part (that's not
> actually what I'm doing, so perhaps I should rethink that one more time).
>
> ‹peter
>
> On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
>
>> The offset values are very expensive.
>>
>> They are also not completely accurate. I¹ve found it¹s difficult to get
>> accurate values where SVG and transforms are in play.
>>
>> I would suggest that x,y,widht and height should reflect *set* values
>> even if they are not always the actual ones.
>>
>> For cases where it¹s necessary to get accurate measured x,y,width and
>> height, I would suggest using ³measured² variations of these values, or
>> better, a getMeasuredBounds() method.
>>
>>> On Feb 7, 2018, at 10:43 AM, Alex Harui 
>>> wrote:
>>>
>>> Hi,
>>>
>>> In Royale on JS, we are trying to leverage the browser's layout code as
>>> much as possible.  We only run our own layout code in a few places.
>>> In debugging a few layout issues I discovered that UIBase is not
>>> reporting
>>> x and y the way we expect it from Flex/Flash.  Browser elements don't
>>> have
>>> x and y properties, instead they have offsetLeft and offsetTop.  Mainly
>>> for backward-compatibility with Flex/Flash, Royale has had x and y in
>>> the
>>> API since the beginning.  I think it is a bug that x and y do not act
>>> like
>>> they do in Flex and plan to fix that after this release.  Thoughts?
>>> I'm a
>>> bit concerned of the expense of calculating x and y because you have to
>>> check if the offsetParent is your immediate parent and get the
>>> offsetLeft/offsetTop of the immediate parent, but I think that's what it
>>> would take to fix it.
>>>
>>> Similarly (well, sort of), Flex did not support CSS margins, only
>>> padding.
>>> The browser reports width (offsetWidth) as factoring in content, padding
>>> and borders, but not margin.  I think that's right, and matches Flex.
>>> However, our custom layout algorithms do not currently factor in margins
>>> since they are not reported in width.  I think our custom layout should
>>> request width and margins and do the math.  We should not change width
>>> to
>>> include margins.  Thoughts?  This will make our custom layout code a bit
>>> more expensive as well as it will probably need to call
>>> getComputedStyles() on all of the children in order to get margins.
>>> This
>>> is also something to fix in the next release.
>>>
>>> Of course, I could be wrong.  Thoughts?
>>>
>>> -Alex
>>>
>>
>

Re: What is x and y? What is width and height?

[Alex Harui]

Hmm.  Maybe we need to understand the circumstances.  It makes no sense to
me to have x,y return useless values just because it is easy or fast to
do.  The main point is that in the HTML/JS/CSS world there is no x,y
values so we can make them do anything we want, but do we want it to work
like Flex/Flash?  I think so.

Clearly, most of our examples and applications don't care about x,y
otherwise we would have hit this earlier.  Or maybe we've worked around it
in the few places we've hit it.  Fixing it is unlikely to cause apps to
have performance issues.  Basically, there are going to be scenarios where
we don't want the browser to run its normal layout. One example is in
ASDoc where you have a 3-pane UI with scrollbars.  There is no way to make
that work with display:flex in some browsers.  But the scenario I just ran
into was floating a popup or dropdown underneath some UI widget.  Right
now, checking the widget's x,y will not return the right value.  I think
it should, no matter how long it takes to compute it.  Another scenario I
expect us to hit more often is when we run effects.  That also tends to
float UI widgets and position them.

Under PAYG, we might have default code that expects that nothing is
transformed and even slower code if transforms are in play.

The issue about width is different from the issue about x,y.  Do we want
width to factor in margins or not?  And, independent of that, do we accept
that we must call getComputedStyles() if width hasn't been otherwise set
in order to return the right value?

Thoughts?
-Alex

On 2/7/18, 8:40 AM, "Piotr Zarzycki"  wrote:

>Can you post into the separate thread if it's even possible any of those
>case ?
>
>2018-02-07 17:36 GMT+01:00 Gabe Harbs :
>
>> Yes. Flexbox solves a lot of problems, and I use the “flex” layouts
>>pretty
>> extensively.
>>
>> However, I have run into lots of cases which are hard to solve and the
>>old
>> Flex-style layouts would have been helpful.
>>
>> > On Feb 7, 2018, at 6:34 PM, Piotr Zarzycki 
>> wrote:
>> >
>> > Lately I had huge exercises with FlexBox mechanism and it is finally
>> > something. I have never seen better working things in HTML than this.
>>If
>> I
>> > wanted to make elements on the right they are really displays on the
>> right.
>> > - Without FlexBox I would be nowhere.
>> >
>> > Maybe it is not the answer for the constrained layout, but it is
>> something.
>> >
>> > Thanks,
>> > Piotr
>> >
>> > 2018-02-07 17:24 GMT+01:00 Gabe Harbs :
>> >
>> >> FWIW, I do think we need a “constrained layout” which places
>> *everything*
>> >> absolutely and does not rely on browser layout. If that layout were
>>to
>> be
>> >> used, the bounding box values would be correct.
>> >>
>> >>> On Feb 7, 2018, at 6:00 PM, Peter Ent 
>>wrote:
>> >>>
>> >>> I think I agree with Harbs about x,y,width,height just returning the
>> set
>> >>> values if the calculation would be expensive. I wonder what the
>> >>> circumstances are that we actually need to have precise values in
>> >>> calculations. For example, if I wanted to make a circulate layout,
>>how
>> >>> would I go about doing that?
>> >>>
>> >>> In the places I've done layouts without regard to platform I'm just
>> >>> assuming things work. For example, in the DataGridLayout, I need to
>> >>> transfer the column width given on the js:DataGridColumn definition
>>to
>> >>> both the List (column) and the corresponding Button in the
>>ButtonBar.
>> >>> Ideally, the browser takes that (along with display and position
>> styles)
>> >>> and just does the right thing with minimum code on our part (that's
>>not
>> >>> actually what I'm doing, so perhaps I should rethink that one more
>> time).
>> >>>
>> >>> ‹peter
>> >>>
>> >>> On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
>> >>>
>>  The offset values are very expensive.
>> 
>>  They are also not completely accurate. I¹ve found it¹s difficult to
>> get
>>  accurate values where SVG and transforms are in play.
>> 
>>  I would suggest that x,y,widht and height should reflect *set*
>>values
>>  even if they are not always the actual ones.
>> 
>>  For cases where it¹s necessary to get accurate measured x,y,width
>>and
>>  height, I would suggest using ³measured² variations of these
>>values,
>> or
>>  better, a getMeasuredBounds() method.
>> 
>> > On Feb 7, 2018, at 10:43 AM, Alex Harui 
>> > wrote:
>> >
>> > Hi,
>> >
>> > In Royale on JS, we are trying to leverage the browser's layout
>>code
>> as
>> > much as possible.  We only run our own layout code in a few
>>places.
>> > In debugging a few layout issues I discovered that UIBase is not
>> > reporting
>> > x and y the way we expect it from Flex/Flash.  Browser elements
>>don't
>> > have
>> > x and y properties, instead they have offsetLeft and offsetTop.
>> Mainly
>> > for backward-compatibility with Flex/Flash, Royale has had x and
>>y in
>> > the
>> > API since the beginning.  I 

Re: What is x and y? What is width and height?

[Piotr Zarzycki]

Can you post into the separate thread if it's even possible any of those
case ?

2018-02-07 17:36 GMT+01:00 Gabe Harbs :

> Yes. Flexbox solves a lot of problems, and I use the “flex” layouts pretty
> extensively.
>
> However, I have run into lots of cases which are hard to solve and the old
> Flex-style layouts would have been helpful.
>
> > On Feb 7, 2018, at 6:34 PM, Piotr Zarzycki 
> wrote:
> >
> > Lately I had huge exercises with FlexBox mechanism and it is finally
> > something. I have never seen better working things in HTML than this. If
> I
> > wanted to make elements on the right they are really displays on the
> right.
> > - Without FlexBox I would be nowhere.
> >
> > Maybe it is not the answer for the constrained layout, but it is
> something.
> >
> > Thanks,
> > Piotr
> >
> > 2018-02-07 17:24 GMT+01:00 Gabe Harbs :
> >
> >> FWIW, I do think we need a “constrained layout” which places
> *everything*
> >> absolutely and does not rely on browser layout. If that layout were to
> be
> >> used, the bounding box values would be correct.
> >>
> >>> On Feb 7, 2018, at 6:00 PM, Peter Ent  wrote:
> >>>
> >>> I think I agree with Harbs about x,y,width,height just returning the
> set
> >>> values if the calculation would be expensive. I wonder what the
> >>> circumstances are that we actually need to have precise values in
> >>> calculations. For example, if I wanted to make a circulate layout, how
> >>> would I go about doing that?
> >>>
> >>> In the places I've done layouts without regard to platform I'm just
> >>> assuming things work. For example, in the DataGridLayout, I need to
> >>> transfer the column width given on the js:DataGridColumn definition to
> >>> both the List (column) and the corresponding Button in the ButtonBar.
> >>> Ideally, the browser takes that (along with display and position
> styles)
> >>> and just does the right thing with minimum code on our part (that's not
> >>> actually what I'm doing, so perhaps I should rethink that one more
> time).
> >>>
> >>> ‹peter
> >>>
> >>> On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
> >>>
>  The offset values are very expensive.
> 
>  They are also not completely accurate. I¹ve found it¹s difficult to
> get
>  accurate values where SVG and transforms are in play.
> 
>  I would suggest that x,y,widht and height should reflect *set* values
>  even if they are not always the actual ones.
> 
>  For cases where it¹s necessary to get accurate measured x,y,width and
>  height, I would suggest using ³measured² variations of these values,
> or
>  better, a getMeasuredBounds() method.
> 
> > On Feb 7, 2018, at 10:43 AM, Alex Harui 
> > wrote:
> >
> > Hi,
> >
> > In Royale on JS, we are trying to leverage the browser's layout code
> as
> > much as possible.  We only run our own layout code in a few places.
> > In debugging a few layout issues I discovered that UIBase is not
> > reporting
> > x and y the way we expect it from Flex/Flash.  Browser elements don't
> > have
> > x and y properties, instead they have offsetLeft and offsetTop.
> Mainly
> > for backward-compatibility with Flex/Flash, Royale has had x and y in
> > the
> > API since the beginning.  I think it is a bug that x and y do not act
> > like
> > they do in Flex and plan to fix that after this release.  Thoughts?
> > I'm a
> > bit concerned of the expense of calculating x and y because you have
> to
> > check if the offsetParent is your immediate parent and get the
> > offsetLeft/offsetTop of the immediate parent, but I think that's what
> >> it
> > would take to fix it.
> >
> > Similarly (well, sort of), Flex did not support CSS margins, only
> > padding.
> > The browser reports width (offsetWidth) as factoring in content,
> >> padding
> > and borders, but not margin.  I think that's right, and matches Flex.
> > However, our custom layout algorithms do not currently factor in
> >> margins
> > since they are not reported in width.  I think our custom layout
> should
> > request width and margins and do the math.  We should not change
> width
> > to
> > include margins.  Thoughts?  This will make our custom layout code a
> >> bit
> > more expensive as well as it will probably need to call
> > getComputedStyles() on all of the children in order to get margins.
> > This
> > is also something to fix in the next release.
> >
> > Of course, I could be wrong.  Thoughts?
> >
> > -Alex
> >
> 
> >>>
> >>
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: What is x and y? What is width and height?

[Gabe Harbs]

Yes. Flexbox solves a lot of problems, and I use the “flex” layouts pretty 
extensively.

However, I have run into lots of cases which are hard to solve and the old 
Flex-style layouts would have been helpful.

> On Feb 7, 2018, at 6:34 PM, Piotr Zarzycki  wrote:
> 
> Lately I had huge exercises with FlexBox mechanism and it is finally
> something. I have never seen better working things in HTML than this. If I
> wanted to make elements on the right they are really displays on the right.
> - Without FlexBox I would be nowhere.
> 
> Maybe it is not the answer for the constrained layout, but it is something.
> 
> Thanks,
> Piotr
> 
> 2018-02-07 17:24 GMT+01:00 Gabe Harbs :
> 
>> FWIW, I do think we need a “constrained layout” which places *everything*
>> absolutely and does not rely on browser layout. If that layout were to be
>> used, the bounding box values would be correct.
>> 
>>> On Feb 7, 2018, at 6:00 PM, Peter Ent  wrote:
>>> 
>>> I think I agree with Harbs about x,y,width,height just returning the set
>>> values if the calculation would be expensive. I wonder what the
>>> circumstances are that we actually need to have precise values in
>>> calculations. For example, if I wanted to make a circulate layout, how
>>> would I go about doing that?
>>> 
>>> In the places I've done layouts without regard to platform I'm just
>>> assuming things work. For example, in the DataGridLayout, I need to
>>> transfer the column width given on the js:DataGridColumn definition to
>>> both the List (column) and the corresponding Button in the ButtonBar.
>>> Ideally, the browser takes that (along with display and position styles)
>>> and just does the right thing with minimum code on our part (that's not
>>> actually what I'm doing, so perhaps I should rethink that one more time).
>>> 
>>> ‹peter
>>> 
>>> On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
>>> 
 The offset values are very expensive.
 
 They are also not completely accurate. I¹ve found it¹s difficult to get
 accurate values where SVG and transforms are in play.
 
 I would suggest that x,y,widht and height should reflect *set* values
 even if they are not always the actual ones.
 
 For cases where it¹s necessary to get accurate measured x,y,width and
 height, I would suggest using ³measured² variations of these values, or
 better, a getMeasuredBounds() method.
 
> On Feb 7, 2018, at 10:43 AM, Alex Harui 
> wrote:
> 
> Hi,
> 
> In Royale on JS, we are trying to leverage the browser's layout code as
> much as possible.  We only run our own layout code in a few places.
> In debugging a few layout issues I discovered that UIBase is not
> reporting
> x and y the way we expect it from Flex/Flash.  Browser elements don't
> have
> x and y properties, instead they have offsetLeft and offsetTop.  Mainly
> for backward-compatibility with Flex/Flash, Royale has had x and y in
> the
> API since the beginning.  I think it is a bug that x and y do not act
> like
> they do in Flex and plan to fix that after this release.  Thoughts?
> I'm a
> bit concerned of the expense of calculating x and y because you have to
> check if the offsetParent is your immediate parent and get the
> offsetLeft/offsetTop of the immediate parent, but I think that's what
>> it
> would take to fix it.
> 
> Similarly (well, sort of), Flex did not support CSS margins, only
> padding.
> The browser reports width (offsetWidth) as factoring in content,
>> padding
> and borders, but not margin.  I think that's right, and matches Flex.
> However, our custom layout algorithms do not currently factor in
>> margins
> since they are not reported in width.  I think our custom layout should
> request width and margins and do the math.  We should not change width
> to
> include margins.  Thoughts?  This will make our custom layout code a
>> bit
> more expensive as well as it will probably need to call
> getComputedStyles() on all of the children in order to get margins.
> This
> is also something to fix in the next release.
> 
> Of course, I could be wrong.  Thoughts?
> 
> -Alex
> 
 
>>> 
>> 
>> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

Re: What is x and y? What is width and height?

[Piotr Zarzycki]

Lately I had huge exercises with FlexBox mechanism and it is finally
something. I have never seen better working things in HTML than this. If I
wanted to make elements on the right they are really displays on the right.
- Without FlexBox I would be nowhere.

Maybe it is not the answer for the constrained layout, but it is something.

Thanks,
Piotr

2018-02-07 17:24 GMT+01:00 Gabe Harbs :

> FWIW, I do think we need a “constrained layout” which places *everything*
> absolutely and does not rely on browser layout. If that layout were to be
> used, the bounding box values would be correct.
>
> > On Feb 7, 2018, at 6:00 PM, Peter Ent  wrote:
> >
> > I think I agree with Harbs about x,y,width,height just returning the set
> > values if the calculation would be expensive. I wonder what the
> > circumstances are that we actually need to have precise values in
> > calculations. For example, if I wanted to make a circulate layout, how
> > would I go about doing that?
> >
> > In the places I've done layouts without regard to platform I'm just
> > assuming things work. For example, in the DataGridLayout, I need to
> > transfer the column width given on the js:DataGridColumn definition to
> > both the List (column) and the corresponding Button in the ButtonBar.
> > Ideally, the browser takes that (along with display and position styles)
> > and just does the right thing with minimum code on our part (that's not
> > actually what I'm doing, so perhaps I should rethink that one more time).
> >
> > ‹peter
> >
> > On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
> >
> >> The offset values are very expensive.
> >>
> >> They are also not completely accurate. I¹ve found it¹s difficult to get
> >> accurate values where SVG and transforms are in play.
> >>
> >> I would suggest that x,y,widht and height should reflect *set* values
> >> even if they are not always the actual ones.
> >>
> >> For cases where it¹s necessary to get accurate measured x,y,width and
> >> height, I would suggest using ³measured² variations of these values, or
> >> better, a getMeasuredBounds() method.
> >>
> >>> On Feb 7, 2018, at 10:43 AM, Alex Harui 
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> In Royale on JS, we are trying to leverage the browser's layout code as
> >>> much as possible.  We only run our own layout code in a few places.
> >>> In debugging a few layout issues I discovered that UIBase is not
> >>> reporting
> >>> x and y the way we expect it from Flex/Flash.  Browser elements don't
> >>> have
> >>> x and y properties, instead they have offsetLeft and offsetTop.  Mainly
> >>> for backward-compatibility with Flex/Flash, Royale has had x and y in
> >>> the
> >>> API since the beginning.  I think it is a bug that x and y do not act
> >>> like
> >>> they do in Flex and plan to fix that after this release.  Thoughts?
> >>> I'm a
> >>> bit concerned of the expense of calculating x and y because you have to
> >>> check if the offsetParent is your immediate parent and get the
> >>> offsetLeft/offsetTop of the immediate parent, but I think that's what
> it
> >>> would take to fix it.
> >>>
> >>> Similarly (well, sort of), Flex did not support CSS margins, only
> >>> padding.
> >>> The browser reports width (offsetWidth) as factoring in content,
> padding
> >>> and borders, but not margin.  I think that's right, and matches Flex.
> >>> However, our custom layout algorithms do not currently factor in
> margins
> >>> since they are not reported in width.  I think our custom layout should
> >>> request width and margins and do the math.  We should not change width
> >>> to
> >>> include margins.  Thoughts?  This will make our custom layout code a
> bit
> >>> more expensive as well as it will probably need to call
> >>> getComputedStyles() on all of the children in order to get margins.
> >>> This
> >>> is also something to fix in the next release.
> >>>
> >>> Of course, I could be wrong.  Thoughts?
> >>>
> >>> -Alex
> >>>
> >>
> >
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: What is x and y? What is width and height?

[Gabe Harbs]

FWIW, I do think we need a “constrained layout” which places *everything* 
absolutely and does not rely on browser layout. If that layout were to be used, 
the bounding box values would be correct.

> On Feb 7, 2018, at 6:00 PM, Peter Ent  wrote:
> 
> I think I agree with Harbs about x,y,width,height just returning the set
> values if the calculation would be expensive. I wonder what the
> circumstances are that we actually need to have precise values in
> calculations. For example, if I wanted to make a circulate layout, how
> would I go about doing that?
> 
> In the places I've done layouts without regard to platform I'm just
> assuming things work. For example, in the DataGridLayout, I need to
> transfer the column width given on the js:DataGridColumn definition to
> both the List (column) and the corresponding Button in the ButtonBar.
> Ideally, the browser takes that (along with display and position styles)
> and just does the right thing with minimum code on our part (that's not
> actually what I'm doing, so perhaps I should rethink that one more time).
> 
> ‹peter
> 
> On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:
> 
>> The offset values are very expensive.
>> 
>> They are also not completely accurate. I¹ve found it¹s difficult to get
>> accurate values where SVG and transforms are in play.
>> 
>> I would suggest that x,y,widht and height should reflect *set* values
>> even if they are not always the actual ones.
>> 
>> For cases where it¹s necessary to get accurate measured x,y,width and
>> height, I would suggest using ³measured² variations of these values, or
>> better, a getMeasuredBounds() method.
>> 
>>> On Feb 7, 2018, at 10:43 AM, Alex Harui 
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> In Royale on JS, we are trying to leverage the browser's layout code as
>>> much as possible.  We only run our own layout code in a few places.
>>> In debugging a few layout issues I discovered that UIBase is not
>>> reporting
>>> x and y the way we expect it from Flex/Flash.  Browser elements don't
>>> have
>>> x and y properties, instead they have offsetLeft and offsetTop.  Mainly
>>> for backward-compatibility with Flex/Flash, Royale has had x and y in
>>> the
>>> API since the beginning.  I think it is a bug that x and y do not act
>>> like
>>> they do in Flex and plan to fix that after this release.  Thoughts?
>>> I'm a
>>> bit concerned of the expense of calculating x and y because you have to
>>> check if the offsetParent is your immediate parent and get the
>>> offsetLeft/offsetTop of the immediate parent, but I think that's what it
>>> would take to fix it.
>>> 
>>> Similarly (well, sort of), Flex did not support CSS margins, only
>>> padding.
>>> The browser reports width (offsetWidth) as factoring in content, padding
>>> and borders, but not margin.  I think that's right, and matches Flex.
>>> However, our custom layout algorithms do not currently factor in margins
>>> since they are not reported in width.  I think our custom layout should
>>> request width and margins and do the math.  We should not change width
>>> to
>>> include margins.  Thoughts?  This will make our custom layout code a bit
>>> more expensive as well as it will probably need to call
>>> getComputedStyles() on all of the children in order to get margins.
>>> This
>>> is also something to fix in the next release.
>>> 
>>> Of course, I could be wrong.  Thoughts?
>>> 
>>> -Alex
>>> 
>> 
> 

Re: What is x and y? What is width and height?

[Peter Ent]

I think I agree with Harbs about x,y,width,height just returning the set
values if the calculation would be expensive. I wonder what the
circumstances are that we actually need to have precise values in
calculations. For example, if I wanted to make a circulate layout, how
would I go about doing that?

In the places I've done layouts without regard to platform I'm just
assuming things work. For example, in the DataGridLayout, I need to
transfer the column width given on the js:DataGridColumn definition to
both the List (column) and the corresponding Button in the ButtonBar.
Ideally, the browser takes that (along with display and position styles)
and just does the right thing with minimum code on our part (that's not
actually what I'm doing, so perhaps I should rethink that one more time).

‹peter

On 2/7/18, 8:35 AM, "Gabe Harbs"  wrote:

>The offset values are very expensive.
>
>They are also not completely accurate. I¹ve found it¹s difficult to get
>accurate values where SVG and transforms are in play.
>
>I would suggest that x,y,widht and height should reflect *set* values
>even if they are not always the actual ones.
>
>For cases where it¹s necessary to get accurate measured x,y,width and
>height, I would suggest using ³measured² variations of these values, or
>better, a getMeasuredBounds() method.
>
>> On Feb 7, 2018, at 10:43 AM, Alex Harui 
>>wrote:
>> 
>> Hi,
>> 
>> In Royale on JS, we are trying to leverage the browser's layout code as
>> much as possible.  We only run our own layout code in a few places.
>> In debugging a few layout issues I discovered that UIBase is not
>>reporting
>> x and y the way we expect it from Flex/Flash.  Browser elements don't
>>have
>> x and y properties, instead they have offsetLeft and offsetTop.  Mainly
>> for backward-compatibility with Flex/Flash, Royale has had x and y in
>>the
>> API since the beginning.  I think it is a bug that x and y do not act
>>like
>> they do in Flex and plan to fix that after this release.  Thoughts?
>>I'm a
>> bit concerned of the expense of calculating x and y because you have to
>> check if the offsetParent is your immediate parent and get the
>> offsetLeft/offsetTop of the immediate parent, but I think that's what it
>> would take to fix it.
>> 
>> Similarly (well, sort of), Flex did not support CSS margins, only
>>padding.
>> The browser reports width (offsetWidth) as factoring in content, padding
>> and borders, but not margin.  I think that's right, and matches Flex.
>> However, our custom layout algorithms do not currently factor in margins
>> since they are not reported in width.  I think our custom layout should
>> request width and margins and do the math.  We should not change width
>>to
>> include margins.  Thoughts?  This will make our custom layout code a bit
>> more expensive as well as it will probably need to call
>> getComputedStyles() on all of the children in order to get margins.
>>This
>> is also something to fix in the next release.
>> 
>> Of course, I could be wrong.  Thoughts?
>> 
>> -Alex
>> 
>

Re: What is x and y? What is width and height?

[Gabe Harbs]

The offset values are very expensive.

They are also not completely accurate. I’ve found it’s difficult to get 
accurate values where SVG and transforms are in play.

I would suggest that x,y,widht and height should reflect *set* values even if 
they are not always the actual ones.

For cases where it’s necessary to get accurate measured x,y,width and height, I 
would suggest using “measured” variations of these values, or better, a 
getMeasuredBounds() method.

> On Feb 7, 2018, at 10:43 AM, Alex Harui  wrote:
> 
> Hi,
> 
> In Royale on JS, we are trying to leverage the browser's layout code as
> much as possible.  We only run our own layout code in a few places.
> In debugging a few layout issues I discovered that UIBase is not reporting
> x and y the way we expect it from Flex/Flash.  Browser elements don't have
> x and y properties, instead they have offsetLeft and offsetTop.  Mainly
> for backward-compatibility with Flex/Flash, Royale has had x and y in the
> API since the beginning.  I think it is a bug that x and y do not act like
> they do in Flex and plan to fix that after this release.  Thoughts?  I'm a
> bit concerned of the expense of calculating x and y because you have to
> check if the offsetParent is your immediate parent and get the
> offsetLeft/offsetTop of the immediate parent, but I think that's what it
> would take to fix it.
> 
> Similarly (well, sort of), Flex did not support CSS margins, only padding.
> The browser reports width (offsetWidth) as factoring in content, padding
> and borders, but not margin.  I think that's right, and matches Flex.
> However, our custom layout algorithms do not currently factor in margins
> since they are not reported in width.  I think our custom layout should
> request width and margins and do the math.  We should not change width to
> include margins.  Thoughts?  This will make our custom layout code a bit
> more expensive as well as it will probably need to call
> getComputedStyles() on all of the children in order to get margins.  This
> is also something to fix in the next release.
> 
> Of course, I could be wrong.  Thoughts?
> 
> -Alex
>