Re: [DISCUSS] Discuss Release Apache Royale 0.9.1 RC1

[Alex Harui]

The release artifacts are a combination of all 3 repos.  When you
uncompress an artifact, there is a README there that is different from the
README.md files we put in the root of each repo.  The artifact README
comes from the royale-asjs repo in the releasemgr/README file.

-Alex

On 2/8/18, 11:27 PM, "Piotr Zarzycki"  wrote:

>Is it that section ?
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fapache%2Froyale-asjs%23additional-prerequisites-for-swf-output=02
>%7C01%7Caharui%40adobe.com%7C2b2cd60f3b0f4c955b3208d56f8e8d3e%7C71f1da39c0
>a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537580399228517=XFpR1DQqFWHUhnDZ
>xKz58Ld3pxdxWte0tVFLQZWhXXw%3D=0
>
>
>2018-02-09 8:21 GMT+01:00 Alex Harui :
>
>>
>>
>> On 2/8/18, 10:55 PM, "Piotr Zarzycki"  wrote:
>>
>> >Hi Alex,
>> >
>> >One question to this release. Did you document anywhere that if someone
>> >download Royale SWF, JS have to on his own download the rest of
>> >dependencies ?
>>
>> It is in the top-level README.
>>
>> -Alex
>> >
>> >Thanks,
>> >Piotr
>> >
>> >2018-02-08 20:58 GMT+01:00 Alex Harui :
>> >
>> >> This is the discussion thread.
>> >>
>> >> Thanks,
>> >> Alex Harui
>> >>
>> >>
>> >
>> >
>> >--
>> >
>> >Piotr Zarzycki
>> >
>> >Patreon:
>> >*https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.patr
>> >eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%
>> 7Ca4ccc59af2fd49
>> >e37d1608d56f8a14f0%7C71f1da39c0a84d5a8d88a67b23c3
>> 0bf4%7C0%7C0%7C6365375612
>> 
>>>08523985=2InBZYmJa9J8LJlQ3eZyfy9F1jmoPeIif8B3ugrx4C8%3D=0
>> >> https%3A%2F%2Fwww.patr
>> >eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%
>> 7Ca4ccc59af2fd49
>> >e37d1608d56f8a14f0%7C71f1da39c0a84d5a8d88a67b23c3
>> 0bf4%7C0%7C0%7C6365375612
>> >08523985=2InBZYmJa9J8LJlQ3eZyfy9F1jmoPe
>> Iif8B3ugrx4C8%3D=0>*
>>
>>
>
>
>-- 
>
>Piotr Zarzycki
>
>Patreon: 
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C2b2cd60f3b0f4c
>955b3208d56f8e8d3e%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365375803
>99228517=%2F0lmMz9otGcYXJRuwWDpj7MPIbQVM3gJeD5LOaasF%2Fk%3D
>=0
>eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C2b2cd60f3b0f4c
>955b3208d56f8e8d3e%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365375803
>99228517=%2F0lmMz9otGcYXJRuwWDpj7MPIbQVM3gJeD5LOaasF%2Fk%3D
>=0>*

Re: [DISCUSS] Discuss Release Apache Royale 0.9.1 RC1

[Piotr Zarzycki]

Is it that section ?
https://github.com/apache/royale-asjs#additional-prerequisites-for-swf-output


2018-02-09 8:21 GMT+01:00 Alex Harui :

>
>
> On 2/8/18, 10:55 PM, "Piotr Zarzycki"  wrote:
>
> >Hi Alex,
> >
> >One question to this release. Did you document anywhere that if someone
> >download Royale SWF, JS have to on his own download the rest of
> >dependencies ?
>
> It is in the top-level README.
>
> -Alex
> >
> >Thanks,
> >Piotr
> >
> >2018-02-08 20:58 GMT+01:00 Alex Harui :
> >
> >> This is the discussion thread.
> >>
> >> Thanks,
> >> Alex Harui
> >>
> >>
> >
> >
> >--
> >
> >Piotr Zarzycki
> >
> >Patreon:
> >*https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.patr
> >eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%
> 7Ca4ccc59af2fd49
> >e37d1608d56f8a14f0%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C6365375612
> >08523985=2InBZYmJa9J8LJlQ3eZyfy9F1jmoPeIif8B3ugrx4C8%3D=0
> > https%3A%2F%2Fwww.patr
> >eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%
> 7Ca4ccc59af2fd49
> >e37d1608d56f8a14f0%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C6365375612
> >08523985=2InBZYmJa9J8LJlQ3eZyfy9F1jmoPe
> Iif8B3ugrx4C8%3D=0>*
>
>


-- 

Piotr Zarzycki

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

Re: [DISCUSS] Discuss Release Apache Royale 0.9.1 RC1

[Alex Harui]

On 2/8/18, 10:55 PM, "Piotr Zarzycki"  wrote:

>Hi Alex,
>
>One question to this release. Did you document anywhere that if someone
>download Royale SWF, JS have to on his own download the rest of
>dependencies ?

It is in the top-level README.

-Alex
>
>Thanks,
>Piotr
>
>2018-02-08 20:58 GMT+01:00 Alex Harui :
>
>> This is the discussion thread.
>>
>> Thanks,
>> Alex Harui
>>
>>
>
>
>-- 
>
>Piotr Zarzycki
>
>Patreon: 
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7Ca4ccc59af2fd49
>e37d1608d56f8a14f0%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365375612
>08523985=2InBZYmJa9J8LJlQ3eZyfy9F1jmoPeIif8B3ugrx4C8%3D=0
>eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7Ca4ccc59af2fd49
>e37d1608d56f8a14f0%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365375612
>08523985=2InBZYmJa9J8LJlQ3eZyfy9F1jmoPeIif8B3ugrx4C8%3D=0>*

Re: [DISCUSS] Discuss Release Apache Royale 0.9.1 RC1

[Piotr Zarzycki]

Hi Alex,

One question to this release. Did you document anywhere that if someone
download Royale SWF, JS have to on his own download the rest of
dependencies ?

Thanks,
Piotr

2018-02-08 20:58 GMT+01:00 Alex Harui :

> This is the discussion thread.
>
> Thanks,
> Alex Harui
>
>


-- 

Piotr Zarzycki

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

Re: Royale Examples Blog proposal to all the team

[OmPrakash Muppirala]

Great idea, Carlos.

Here is one I volunteer to write about: Getting started with Royale on npm

I will write this over the weekend and share it here.  We can post after
Andrew (and others) makes a sweep over it :-)

Thanks,
Om

On Thu, Feb 8, 2018 at 3:25 AM, Andrew Wetmore  wrote:

> This sounds really good. I will be glad to help people who have strong
> Royale skills but are uncomfortable writing for publication in English.
>
> a
>
> On Thu, Feb 8, 2018 at 7:11 AM, Carlos Rovira 
> wrote:
>
> > Hi,
> >
> > I want to propose to start introducing some "pearls" (beads? ;)) of quick
> > knowledge about Royale in our blog (Peter de Haan's flex examples blog
> > style, remember it?)
> >
> > *This will make the effect that each post will be published in Facebook
> and
> > Twitter and will make us to be "on the air" and reach more people that
> > would eventually join us. Is not only about make it easy to learn Royale,
> > but to make people out there know us!)*
> >
> > To make this happen I propose to publish one tiny example each 2 weeks,
> and
> > each time from a different team member.
> >
> > Since we are around 10-15 people supporting this project, we can make
> > calendar with publish dates, so we all know when we must publish.
> >
> > In this way each one will be publishing each 6 month (approx.), and I
> think
> > this is very affordable for all of us
> >
> > what do you think?
> >
> > (btw, we can introduce the content in WP and schedule for publication the
> > day and hour we want, and then make it live royal.a.o)
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
> Andrew Wetmore
>
> http://cottage14.blogspot.com/
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Dave Fisher]

Sent from my iPhone

> On Feb 8, 2018, at 2:10 PM, Alex Harui  wrote:
> 
> We can "leave it as it was" by making SIMPLE_OPTIMIZATIONS the default.
> The difference between Flex and Royale is that Royale currently crunches
> your code through the Google Closure Compiler with ADVANCED_OPTIMIZATIONS
> and that messes up how you use plain objects.
> 
> IMO, there is enough to gain from using ValueObjects (code hinting,
> type-checking, etc) that we should promote use of them and make it really
> easy to use them, like creating typedefs via some utility.  IOW, if it
> only took 5 minutes to generate ValueObjects for your JSON responses,
> would you just use them because it saved you time making mistakes using
> plain object?
> 
> But if enough folks want to use plain objects in production (this is not
> an issue for the bin/js-debug version) I have no objection to making it
> work, I'm just wondering if we should just use SIMPLE_OPTIMIZATIONS since
> that is easy, or take the time to add another compiler option and fork the
> output code generators to generate different code (and write tests for all
> of that).  Would ADVANCED_OPTIMIZATIONS plus this new option be worth it
> over SIMPLE_OPTIMIZATIONS?
> 
> If we change our default to SIMPLE_OPTIMIZATIONS our HelloWorld will be
> fatter, but I don't know by how much.  But that is a consideration if
> folks are going to care about download size.

A comparison would help. I don’t know what scale you have in mind. 

FWIW - If someone hosting a Royale app truly cares then there are additional 
outside the scope of Royale solutions like gzip and PageSpeed.

Regards,
Dave

> 
> Thoughts?
> -Alex
> 
> On 2/8/18, 1:55 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
> 
>> but why to complicate this so much? I think we always had in Flex/Flash
>> the
>> opportunity to make this without any additional config.
>> Why not left it as it always was?
>> 
>> thanks
>> 
>> 2018-02-08 19:48 GMT+01:00 Alex Harui :
>> 
>>> I'm not disagreeing. I think the question is whether we need yet another
>>> compiler option to generate bracket notation for objects or just ask
>>> folks
>>> to use SIMPLE_OPTIMIZATIONS.  And whether we switch to
>>> SIMPLE_OPTIMIZATIONS by default.  I can think of lots of other things to
>>> work on besides this new option if we have rough equivalents.
>>> 
>>> -Alex
>>> 
>>> On 2/8/18, 10:36 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>> Rovira"
>>>  wrote:
>>> 
 Although I'm pro typed,  I agree with Josh that we should not enforce
 that.
 That's one of the great points in Flash/Flex.
 For make things quick, I use simple objects with bracket notation, when
 the
 application is more relevant I go the right typed path.
 It's up to the developer decide when they want one or another.
 
 
 
 2018-02-08 18:50 GMT+01:00 Josh Tynjala :
 
> Nothing frustrated me more about Royale/FlexJS than the fact that I
> couldn't use untyped objects without bracket notation. It's a very
>>> bad
> user
> experience when trying to consume JSON, or even when choosing to
>>> create
> my
> own object literals. While it's a good best practice to create value
> objects, that shouldn't be forced on everyone. I frequently use
>>> untyped
> objects when prototyping because it's more convenient. They're also
> useful
> in example code to reduce boilerplate that isn't particularly
>>> relevant
> to
> the concept/feature that you're trying to demonstrate. And, of
>>> course,
> there's the already mentioned JSON.
> 
> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS
>>> the
> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
> larger file size is an acceptable trade off, if it reduces the
> frustration
> of this situation. Especially for new users who will absolutely think
> its a
> serious bug in the Royale compiler. However, as Harbs notes here, if
>>> the
> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
> retained.
> The compiler could generate code differently when something resolves
>>> as
> the
> Object type. The emitter could translate dot notation normally most
>>> of
> the
> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
> detects Object, switch to bracket notation instead. I believe it
>>> would
> also
> need to add quotes around properties defined in object literals.
> 
> Ideally, the following code should work properly out of the box:
> 
> var obj:Object = {one: 1, "two": 2};
> obj.three = 3;
> obj["four"] = 4;
> var one:Number = obj["one"];
> var two:Number = obj.two;
> var 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui]

We can "leave it as it was" by making SIMPLE_OPTIMIZATIONS the default.
The difference between Flex and Royale is that Royale currently crunches
your code through the Google Closure Compiler with ADVANCED_OPTIMIZATIONS
and that messes up how you use plain objects.

IMO, there is enough to gain from using ValueObjects (code hinting,
type-checking, etc) that we should promote use of them and make it really
easy to use them, like creating typedefs via some utility.  IOW, if it
only took 5 minutes to generate ValueObjects for your JSON responses,
would you just use them because it saved you time making mistakes using
plain object?

But if enough folks want to use plain objects in production (this is not
an issue for the bin/js-debug version) I have no objection to making it
work, I'm just wondering if we should just use SIMPLE_OPTIMIZATIONS since
that is easy, or take the time to add another compiler option and fork the
output code generators to generate different code (and write tests for all
of that).  Would ADVANCED_OPTIMIZATIONS plus this new option be worth it
over SIMPLE_OPTIMIZATIONS?

If we change our default to SIMPLE_OPTIMIZATIONS our HelloWorld will be
fatter, but I don't know by how much.  But that is a consideration if
folks are going to care about download size.

Thoughts?
-Alex

On 2/8/18, 1:55 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>but why to complicate this so much? I think we always had in Flex/Flash
>the
>opportunity to make this without any additional config.
>Why not left it as it always was?
>
>thanks
>
>2018-02-08 19:48 GMT+01:00 Alex Harui :
>
>> I'm not disagreeing. I think the question is whether we need yet another
>> compiler option to generate bracket notation for objects or just ask
>>folks
>> to use SIMPLE_OPTIMIZATIONS.  And whether we switch to
>> SIMPLE_OPTIMIZATIONS by default.  I can think of lots of other things to
>> work on besides this new option if we have rough equivalents.
>>
>> -Alex
>>
>> On 2/8/18, 10:36 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Although I'm pro typed,  I agree with Josh that we should not enforce
>> >that.
>> >That's one of the great points in Flash/Flex.
>> >For make things quick, I use simple objects with bracket notation, when
>> >the
>> >application is more relevant I go the right typed path.
>> >It's up to the developer decide when they want one or another.
>> >
>> >
>> >
>> >2018-02-08 18:50 GMT+01:00 Josh Tynjala :
>> >
>> >> Nothing frustrated me more about Royale/FlexJS than the fact that I
>> >> couldn't use untyped objects without bracket notation. It's a very
>>bad
>> >>user
>> >> experience when trying to consume JSON, or even when choosing to
>>create
>> >>my
>> >> own object literals. While it's a good best practice to create value
>> >> objects, that shouldn't be forced on everyone. I frequently use
>>untyped
>> >> objects when prototyping because it's more convenient. They're also
>> >>useful
>> >> in example code to reduce boilerplate that isn't particularly
>>relevant
>> >>to
>> >> the concept/feature that you're trying to demonstrate. And, of
>>course,
>> >> there's the already mentioned JSON.
>> >>
>> >> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS
>>the
>> >> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
>> >> larger file size is an acceptable trade off, if it reduces the
>> >>frustration
>> >> of this situation. Especially for new users who will absolutely think
>> >>its a
>> >> serious bug in the Royale compiler. However, as Harbs notes here, if
>>the
>> >> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
>> >>retained.
>> >> The compiler could generate code differently when something resolves
>>as
>> >>the
>> >> Object type. The emitter could translate dot notation normally most
>>of
>> >>the
>> >> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
>> >> detects Object, switch to bracket notation instead. I believe it
>>would
>> >>also
>> >> need to add quotes around properties defined in object literals.
>> >>
>> >> Ideally, the following code should work properly out of the box:
>> >>
>> >> var obj:Object = {one: 1, "two": 2};
>> >> obj.three = 3;
>> >> obj["four"] = 4;
>> >> var one:Number = obj["one"];
>> >> var two:Number = obj.two;
>> >> var three:Number = obj["three"];
>> >> var four:Number = obj.four;
>> >>
>> >> The compiler would probably emit something like this to make it work
>> >>with
>> >> the Closure compiler's ADVANCED_OPTIMIZATIONS:
>> >>
>> >> var obj:Object = {"one": 1, "two": 2};
>> >> obj["three"] = 3;
>> >> obj["four"] = 4;
>> >> var one:Number = obj["one"];
>> >> var two:Number = obj["two"];
>> >> var three:Number = obj["three"];
>> >> var four:Number = obj["four"];
>> >>
>> >> Again, 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Carlos Rovira]

but why to complicate this so much? I think we always had in Flex/Flash the
opportunity to make this without any additional config.
Why not left it as it always was?

thanks

2018-02-08 19:48 GMT+01:00 Alex Harui :

> I'm not disagreeing. I think the question is whether we need yet another
> compiler option to generate bracket notation for objects or just ask folks
> to use SIMPLE_OPTIMIZATIONS.  And whether we switch to
> SIMPLE_OPTIMIZATIONS by default.  I can think of lots of other things to
> work on besides this new option if we have rough equivalents.
>
> -Alex
>
> On 2/8/18, 10:36 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Although I'm pro typed,  I agree with Josh that we should not enforce
> >that.
> >That's one of the great points in Flash/Flex.
> >For make things quick, I use simple objects with bracket notation, when
> >the
> >application is more relevant I go the right typed path.
> >It's up to the developer decide when they want one or another.
> >
> >
> >
> >2018-02-08 18:50 GMT+01:00 Josh Tynjala :
> >
> >> Nothing frustrated me more about Royale/FlexJS than the fact that I
> >> couldn't use untyped objects without bracket notation. It's a very bad
> >>user
> >> experience when trying to consume JSON, or even when choosing to create
> >>my
> >> own object literals. While it's a good best practice to create value
> >> objects, that shouldn't be forced on everyone. I frequently use untyped
> >> objects when prototyping because it's more convenient. They're also
> >>useful
> >> in example code to reduce boilerplate that isn't particularly relevant
> >>to
> >> the concept/feature that you're trying to demonstrate. And, of course,
> >> there's the already mentioned JSON.
> >>
> >> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the
> >> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
> >> larger file size is an acceptable trade off, if it reduces the
> >>frustration
> >> of this situation. Especially for new users who will absolutely think
> >>its a
> >> serious bug in the Royale compiler. However, as Harbs notes here, if the
> >> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
> >>retained.
> >> The compiler could generate code differently when something resolves as
> >>the
> >> Object type. The emitter could translate dot notation normally most of
> >>the
> >> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
> >> detects Object, switch to bracket notation instead. I believe it would
> >>also
> >> need to add quotes around properties defined in object literals.
> >>
> >> Ideally, the following code should work properly out of the box:
> >>
> >> var obj:Object = {one: 1, "two": 2};
> >> obj.three = 3;
> >> obj["four"] = 4;
> >> var one:Number = obj["one"];
> >> var two:Number = obj.two;
> >> var three:Number = obj["three"];
> >> var four:Number = obj.four;
> >>
> >> The compiler would probably emit something like this to make it work
> >>with
> >> the Closure compiler's ADVANCED_OPTIMIZATIONS:
> >>
> >> var obj:Object = {"one": 1, "two": 2};
> >> obj["three"] = 3;
> >> obj["four"] = 4;
> >> var one:Number = obj["one"];
> >> var two:Number = obj["two"];
> >> var three:Number = obj["three"];
> >> var four:Number = obj["four"];
> >>
> >> Again, that's only for when something is typed as Object. If something
> >> actually has a class, let Closure compiler go nuts and rename
> >>everything it
> >> wants.
> >>
> >> - Josh
> >>
> >> On 2018/02/06 08:51:19, Gabe Harbs  wrote:
> >> > Quite sure. In my angular app I was using an older version of the
> >> closure compiler to minify the js files. I was using the default options
> >> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object
> >>literals
> >> didn’t get renamed.
> >> >
> >> > I think most modern app frameworks use other tools such as Babel for
> >> magnification, but I believe that handles object literals correctly too.
> >> >
> >> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
> >> object literals. I’m proposing a compiler *option* to allow to continue
> >> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
> >>should
> >> not be renamed.
> >> >
> >> > Harbs
> >> >
> >> > > On Feb 6, 2018, at 9:38 AM, Alex Harui 
> >> wrote:
> >> > >
> >> > > Are you sure Angular and React minify your code instead of running
> >>it
> >> > > against their minified framework?
> >> > >
> >> > > -Alex
> >> > >
> >> > > On 2/5/18, 11:22 PM, "Gabe Harbs"  wrote:
> >> > >
> >> > >>> Maybe I'm missing something.  I don't think Royale has any extra
> >> > >>> problems
> >> > >>> with JSON objects than other JS Frameworks have.  If you want to
> >> minify,
> >> > >>> you have to use brackets and strings.
> >> > >>
> >> > >> It does.
> 

Re: [VOTE] Release Apache Royale 0.9.1 RC1

[Alex Harui]

+1
Package 
https://dist.apache.org/repos/dist/dev/royale/0.9.1/rc1/apache-royale-0.9.1
-src.tar.gz
Java 1.8
OS: Mac OS X x86_64 10.12.5
Source kit signatures match: y
Source kit builds: y
README is ok: y
RELEASE_NOTES is ok: y
NOTICE is ok: y
LICENSE is ok: y
No unapproved licenses or archives: y
No unapproved binaries: y


Package 
https://dist.apache.org/repos/dist/dev/royale/0.9.1/rc1/binaries/apache-roy
ale-0.9.1-bin-js-swf.tar.gz
Binary kit signatures match: y
NOTICE is ok: y
LICENSE is ok: y
No unapproved licenses or archives in binary package: y
No unapproved binaries in binary package: y




On 2/8/18, 11:58 AM, "Alex Harui"  wrote:

>Hi,
>
>This is vote for the 0.9.1 release of Apache Royale.
>
>The release candidate can be found here;
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apac
>he.org%2Frepos%2Fdist%2Fdev%2Froyale%2F0.9.1%2Frc1%2F=02%7C01%7Caharu
>i%40adobe.com%7C249d7363c28c4ff6a24308d56f2e5765%7C71f1da39c0a84d5a8d88a67
>b23c30bf4%7C0%7C0%7C636537167178722263=aVaTU9jR5UiDlLc8riHGHMfxCSOMl
>Fi43IehIDsvwa8%3D=0
>
>Before voting please review the section,'What are the ASF requirements on
>approving a release?', at:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache
>.org%2Fdev%2Frelease.html%23approving-a-release=02%7C01%7Caharui%40ad
>obe.com%7C249d7363c28c4ff6a24308d56f2e5765%7C71f1da39c0a84d5a8d88a67b23c30
>bf4%7C0%7C0%7C636537167178722263=p%2Fbj8jT5O5srU%2B3xmXJeNU1PZDiKvWG
>K7MjXGcNJsQY%3D=0
>
>At a minimum you would be expected to check that:
>- MD5 and signed packages are correct
>- README, RELEASE_NOTES, NOTICE and LICENSE files are all fine
>- That the build script completes successfully
>- That you can compile and cross-compile a simple example using the SDK.
>
>The source package is a combination of the 3 main Royale repos.
>
>To use the binary package, unzip it into a folder.  The -js package is
>ready-to-use in an IDE or command-line.  If you need SWF output, use the
>-royale package and use Apache Ant to run the InstallAdobeSDKs script via:
>  ant -f InstallAdobeSDKs.xml
>
>You may also get the binary packages via NPM.  The -js package can be
>installed via:
>
>npm install 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apac
>he.org%2Frepos%2Fdist%2Fdev%2Froyale%2F0.9.1%2Frc1%2Fbinaries%2Fapache-roy
>=02%7C01%7Caharui%40adobe.com%7C249d7363c28c4ff6a24308d56f2e5765%7C71
>f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537167178722263=Rv6NjuIH
>gTh2tSfIfSWh0ySnAcpjMLrSBi4Fz3%2B4GCI%3D=0
>ale-0.9.1-bin-js.tar.gz -g
>
>The full package with SWF support can be installed via:
>
>npm install 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apac
>he.org%2Frepos%2Fdist%2Fdev%2Froyale%2F0.9.1%2Frc=02%7C01%7Caharui%40
>adobe.com%7C249d7363c28c4ff6a24308d56f2e5765%7C71f1da39c0a84d5a8d88a67b23c
>30bf4%7C0%7C0%7C636537167178722263=o4uzi6BfUUt6%2FB8XkVwrJdx40I%2Fc%
>2FJ1DwSGOKc2vd5I%3D=0{rc}/binaries/apache-
>royale-0.9.1-bin-js-swf.tar.gz -g
>
>Maven artifacts are staged here:
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepositor
>y.apache.org%2Fcontent%2Frepositories%2Forgapacheroyale-1013=02%7C01%
>7Caharui%40adobe.com%7C249d7363c28c4ff6a24308d56f2e5765%7C71f1da39c0a84d5a
>8d88a67b23c30bf4%7C0%7C0%7C636537167178722263=b71yc5owyt%2F%2FgTNG4g
>cXc7VtK1F2blb5hJkoWzuXLUY%3D=0
>
>Please vote to approve this release:
>+1 Approve the release
>-1 Disapprove the release (please provide specific comments to why)
>
>This vote will be open for 72 hours or until a result can be called.
>
>The vote passes if there is:
>- At least 3 +1 votes from the PMC
>- More positive votes than negative votes
>
>Remember that this is a 'beta-quality' release so I expect there
>will be many bugs found.  IMO the goal is not to try to find and fix bugs
>in the RC, but to make sure we have the packaging right, and enough
>functionality that folks will have some success trying to use it.
>
>People who are not in PMC are also encouraged to test out the release and
>vote, although their votes will not be binding, they can influence how the
>PMC votes.
>
>When voting please indicate what OS, IDE, Flash Player version and AIR
>version you tested with.
>
>For your convenience, there is an ant script that automates the common
>steps to validate a release.  Instead of individually downloading the
>package and signature files, unzipping, etc, you can instead:
>1) create an empty folder,
>2) download into that folder this file:
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apac
>he.org%2Frepos%2Fdist%2Fdev%2Froyale%2F0.9.1%2Frc1%2FApproveRoyale.xml
>a=02%7C01%7Caharui%40adobe.com%7C249d7363c28c4ff6a24308d56f2e5765%7C71f1da
>39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537167178722263=hN76MHp%2Bdo
>K3%2Fx46C9WRc%2F7gm7eXo0SP1oiFpDiv8O8%3D=0
>3) run the script:
>   ant -e -f ApproveRoyale.xml -Drelease.version=0.9.1 -Drc=1
>   If you want to test SWF support during the 

[VOTE] Release Apache Royale 0.9.1 RC1

[Alex Harui]

Hi,

This is vote for the 0.9.1 release of Apache Royale.

The release candidate can be found here;
https://dist.apache.org/repos/dist/dev/royale/0.9.1/rc1/

Before voting please review the section,'What are the ASF requirements on
approving a release?', at:
http://www.apache.org/dev/release.html#approving-a-release

At a minimum you would be expected to check that:
- MD5 and signed packages are correct
- README, RELEASE_NOTES, NOTICE and LICENSE files are all fine
- That the build script completes successfully
- That you can compile and cross-compile a simple example using the SDK.

The source package is a combination of the 3 main Royale repos.

To use the binary package, unzip it into a folder.  The -js package is
ready-to-use in an IDE or command-line.  If you need SWF output, use the
-royale package and use Apache Ant to run the InstallAdobeSDKs script via:
  ant -f InstallAdobeSDKs.xml

You may also get the binary packages via NPM.  The -js package can be
installed via:

npm install 
https://dist.apache.org/repos/dist/dev/royale/0.9.1/rc1/binaries/apache-roy
ale-0.9.1-bin-js.tar.gz -g

The full package with SWF support can be installed via:

npm install 
https://dist.apache.org/repos/dist/dev/royale/0.9.1/rc{rc}/binaries/apache-
royale-0.9.1-bin-js-swf.tar.gz -g

Maven artifacts are staged here:
https://repository.apache.org/content/repositories/orgapacheroyale-1013

Please vote to approve this release:
+1 Approve the release
-1 Disapprove the release (please provide specific comments to why)

This vote will be open for 72 hours or until a result can be called.

The vote passes if there is:
- At least 3 +1 votes from the PMC
- More positive votes than negative votes

Remember that this is a 'beta-quality' release so I expect there
will be many bugs found.  IMO the goal is not to try to find and fix bugs
in the RC, but to make sure we have the packaging right, and enough
functionality that folks will have some success trying to use it.

People who are not in PMC are also encouraged to test out the release and
vote, although their votes will not be binding, they can influence how the
PMC votes.

When voting please indicate what OS, IDE, Flash Player version and AIR
version you tested with.

For your convenience, there is an ant script that automates the common
steps to validate a release.  Instead of individually downloading the
package and signature files, unzipping, etc, you can instead:
1) create an empty folder,
2) download into that folder this file:
https://dist.apache.org/repos/dist/dev/royale/0.9.1/rc1/ApproveRoyale.xml
3) run the script:
   ant -e -f ApproveRoyale.xml -Drelease.version=0.9.1 -Drc=1
   If you want to test SWF support during the approval, use:
   ant -e -f ApproveRoyale.xml -Drelease.version=0.9.1 -Drc=1
-Duse-flash=true

You are not required to use this script, and more testing of the packages
and build results are always encouraged.


Please put all discussion about this release in the DISCUSSION thread not
this VOTE thread.

Thanks,
Alex Harui

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
>> >> > Sent: Thursday, February 8, 2018 12:33 PM
>> >> > To: 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 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui]

I'm not disagreeing. I think the question is whether we need yet another
compiler option to generate bracket notation for objects or just ask folks
to use SIMPLE_OPTIMIZATIONS.  And whether we switch to
SIMPLE_OPTIMIZATIONS by default.  I can think of lots of other things to
work on besides this new option if we have rough equivalents.

-Alex

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

>Although I'm pro typed,  I agree with Josh that we should not enforce
>that.
>That's one of the great points in Flash/Flex.
>For make things quick, I use simple objects with bracket notation, when
>the
>application is more relevant I go the right typed path.
>It's up to the developer decide when they want one or another.
>
>
>
>2018-02-08 18:50 GMT+01:00 Josh Tynjala :
>
>> Nothing frustrated me more about Royale/FlexJS than the fact that I
>> couldn't use untyped objects without bracket notation. It's a very bad
>>user
>> experience when trying to consume JSON, or even when choosing to create
>>my
>> own object literals. While it's a good best practice to create value
>> objects, that shouldn't be forced on everyone. I frequently use untyped
>> objects when prototyping because it's more convenient. They're also
>>useful
>> in example code to reduce boilerplate that isn't particularly relevant
>>to
>> the concept/feature that you're trying to demonstrate. And, of course,
>> there's the already mentioned JSON.
>>
>> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the
>> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
>> larger file size is an acceptable trade off, if it reduces the
>>frustration
>> of this situation. Especially for new users who will absolutely think
>>its a
>> serious bug in the Royale compiler. However, as Harbs notes here, if the
>> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
>>retained.
>> The compiler could generate code differently when something resolves as
>>the
>> Object type. The emitter could translate dot notation normally most of
>>the
>> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
>> detects Object, switch to bracket notation instead. I believe it would
>>also
>> need to add quotes around properties defined in object literals.
>>
>> Ideally, the following code should work properly out of the box:
>>
>> var obj:Object = {one: 1, "two": 2};
>> obj.three = 3;
>> obj["four"] = 4;
>> var one:Number = obj["one"];
>> var two:Number = obj.two;
>> var three:Number = obj["three"];
>> var four:Number = obj.four;
>>
>> The compiler would probably emit something like this to make it work
>>with
>> the Closure compiler's ADVANCED_OPTIMIZATIONS:
>>
>> var obj:Object = {"one": 1, "two": 2};
>> obj["three"] = 3;
>> obj["four"] = 4;
>> var one:Number = obj["one"];
>> var two:Number = obj["two"];
>> var three:Number = obj["three"];
>> var four:Number = obj["four"];
>>
>> Again, that's only for when something is typed as Object. If something
>> actually has a class, let Closure compiler go nuts and rename
>>everything it
>> wants.
>>
>> - Josh
>>
>> On 2018/02/06 08:51:19, Gabe Harbs  wrote:
>> > Quite sure. In my angular app I was using an older version of the
>> closure compiler to minify the js files. I was using the default options
>> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object
>>literals
>> didn’t get renamed.
>> >
>> > I think most modern app frameworks use other tools such as Babel for
>> magnification, but I believe that handles object literals correctly too.
>> >
>> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
>> object literals. I’m proposing a compiler *option* to allow to continue
>> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
>>should
>> not be renamed.
>> >
>> > Harbs
>> >
>> > > On Feb 6, 2018, at 9:38 AM, Alex Harui 
>> wrote:
>> > >
>> > > Are you sure Angular and React minify your code instead of running
>>it
>> > > against their minified framework?
>> > >
>> > > -Alex
>> > >
>> > > On 2/5/18, 11:22 PM, "Gabe Harbs"  wrote:
>> > >
>> > >>> Maybe I'm missing something.  I don't think Royale has any extra
>> > >>> problems
>> > >>> with JSON objects than other JS Frameworks have.  If you want to
>> minify,
>> > >>> you have to use brackets and strings.
>> > >>
>> > >> It does.
>> > >>
>> > >> I’ve written angular apps and I’ve never had to worry about using
>> bracket
>> > >> notation for minifying simple js objects. I’m pretty sure the same
>>is
>> for
>> > >> React, etc.
>> > >>
>> > >>> On Feb 5, 2018, at 11:34 PM, Alex Harui 
>> > >>> wrote:
>> > >>>
>> > >>> Maybe I'm missing something.  I don't think Royale has any extra
>> > >>> problems
>> > >>> with JSON objects than other JS Frameworks have.  If you want to
>> 

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
> >> > Sent: Thursday, February 8, 2018 12:33 PM
> >> > To: 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
> >> > > Sent: Wednesday, February 7, 2018 6:24 PM
> >> > > To: 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
> 

Re: Canvas

[Alex Harui]

IMO, the Express set should have a Canvas component that bundles those
beads.  I challenge someone besides Peter and me to create it!

Thanks,
-Alex

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

>So cool :)
>Hope Peter could let us know what he thinks as well as well with the new
>thread I just open about examples blog :)
>
>2018-02-08 12:06 GMT+01:00 Andrew Wetmore :
>
>> Absolutely. I am also going to include this in the help docs list of
>> features that you do one way in Flex and slightly differently in Royale.
>>
>> On Thu, Feb 8, 2018 at 6:57 AM, Carlos Rovira 
>> wrote:
>>
>> > (moving to dev list)
>> >
>> > Hi I think this is a good tip that we can add to our Royale Blog in
>>the
>> > "Examples" category. And respect the user (ni this case Peter) as the
>> > poster.
>> >
>> > What do you think?
>> >
>> > 2018-02-06 15:06 GMT+01:00 Peter Ent :
>> >
>> > > Hi,
>> > >
>> > > Thanks for looking into Apache Royale!
>> > >
>> > > As you know, mx:Canvas lets you place items using (x,y) positioning.
>> You
>> > > can do the same thing using either js:Group or js:Container with
>> > > js:BasicLayout.
>> > >
>> > > js:Group is much lighter in weight then js:Container when running
>>the
>> app
>> > > in the Flash Player; in the browser they are equivalent.
>>js:Container
>> can
>> > > be made to scroll and js:Group cannot.
>> > >
>> > > If you do not need scrolling, use js:Group:
>> > >
>> > > 
>> > > 
>> > > 
>> > > 
>> > > >attributes
>> ‹>
>> > > 
>> > >
>> > > If you do need scrolling, then you would use:
>> > >
>> > > 
>> > > 
>> > > 
>> > > 
>> > > 
>> > > >attributes
>> ‹>
>> > > 
>> > >
>> > > Regards,
>> > > Peter Ent
>> > > Adobe Systems/Apache Royale Project
>> > >
>> > >
>> > > On 2/6/18, 4:46 AM, "Alina Kazi"  wrote:
>> > >
>> > > >Hi,
>> > > >
>> > > >I am using mx:Canvas and porting my app to Apache Flexjs/Royale I
>> can't
>> > > >find
>> > > >any substitute of it.
>> > > >
>> > > >Kindly let me know if there is any other alternate for similar
>> > > >functionality.
>> > > >
>> > > >
>> > > >
>> > > >Aleena
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Carlos Rovira
>> > 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C26a9a2644e9c491092af08
>>d56ee50f38%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653685246919203
>>6=S3KwHgvUwpW5STJ%2BJb41%2Fe9j%2FcBDUz2s4ZjRuyDLDcg%3D=0
>> >
>>
>>
>>
>> --
>> Andrew Wetmore
>>
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14
>>.blogspot.com%2F=02%7C01%7Caharui%40adobe.com%7C26a9a2644e9c491092af
>>08d56ee50f38%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636536852469192
>>036=ZdjtTBAGw55JysGANyB2zeOsksP0y%2BCTH2sCW8GuamA%3D=0
>>
>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C26a9a2644e9c491092af08d5
>6ee50f38%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636536852469192036
>data=S3KwHgvUwpW5STJ%2BJb41%2Fe9j%2FcBDUz2s4ZjRuyDLDcg%3D=0

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
>> > Sent: Thursday, February 8, 2018 12:33 PM
>> > To: 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
>> > > Sent: Wednesday, February 7, 2018 6:24 PM
>> > > To: 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 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Josh Tynjala]

Nothing frustrated me more about Royale/FlexJS than the fact that I couldn't 
use untyped objects without bracket notation. It's a very bad user experience 
when trying to consume JSON, or even when choosing to create my own object 
literals. While it's a good best practice to create value objects, that 
shouldn't be forced on everyone. I frequently use untyped objects when 
prototyping because it's more convenient. They're also useful in example code 
to reduce boilerplate that isn't particularly relevant to the concept/feature 
that you're trying to demonstrate. And, of course, there's the already 
mentioned JSON.

In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the default 
instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly larger file size 
is an acceptable trade off, if it reduces the frustration of this situation. 
Especially for new users who will absolutely think its a serious bug in the 
Royale compiler. However, as Harbs notes here, if the compiler were a little 
smarter, ADVANCED_OPTIMIZATIONS could be retained. The compiler could generate 
code differently when something resolves as the Object type. The emitter could 
translate dot notation normally most of the time, and let 
ADVANCED_OPTIMIZATIONS do its renaming. However, if it detects Object, switch 
to bracket notation instead. I believe it would also need to add quotes around 
properties defined in object literals.

Ideally, the following code should work properly out of the box:

var obj:Object = {one: 1, "two": 2};
obj.three = 3;
obj["four"] = 4;
var one:Number = obj["one"];
var two:Number = obj.two;
var three:Number = obj["three"];
var four:Number = obj.four;

The compiler would probably emit something like this to make it work with the 
Closure compiler's ADVANCED_OPTIMIZATIONS:

var obj:Object = {"one": 1, "two": 2};
obj["three"] = 3;
obj["four"] = 4;
var one:Number = obj["one"];
var two:Number = obj["two"];
var three:Number = obj["three"];
var four:Number = obj["four"];

Again, that's only for when something is typed as Object. If something actually 
has a class, let Closure compiler go nuts and rename everything it wants.

- Josh

On 2018/02/06 08:51:19, Gabe Harbs  wrote: 
> Quite sure. In my angular app I was using an older version of the closure 
> compiler to minify the js files. I was using the default options which 
> clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals didn’t 
> get renamed.
> 
> I think most modern app frameworks use other tools such as Babel for 
> magnification, but I believe that handles object literals correctly too.
> 
> We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing object 
> literals. I’m proposing a compiler *option* to allow to continue using 
> ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which should not be 
> renamed.
> 
> Harbs
> 
> > On Feb 6, 2018, at 9:38 AM, Alex Harui  wrote:
> > 
> > Are you sure Angular and React minify your code instead of running it
> > against their minified framework?
> > 
> > -Alex
> > 
> > On 2/5/18, 11:22 PM, "Gabe Harbs"  wrote:
> > 
> >>> Maybe I'm missing something.  I don't think Royale has any extra
> >>> problems
> >>> with JSON objects than other JS Frameworks have.  If you want to minify,
> >>> you have to use brackets and strings.
> >> 
> >> It does.
> >> 
> >> I’ve written angular apps and I’ve never had to worry about using 
> >> bracket
> >> notation for minifying simple js objects. I’m pretty sure the same is for
> >> React, etc.
> >> 
> >>> On Feb 5, 2018, at 11:34 PM, Alex Harui 
> >>> wrote:
> >>> 
> >>> Maybe I'm missing something.  I don't think Royale has any extra
> >>> problems
> >>> with JSON objects than other JS Frameworks have.  If you want to minify,
> >>> you have to use brackets and strings.  If you don't want to minify, then
> >>> you don't need to worry about that.  Am I wrong about that?
> >>> 
> >>> 
> >>> JSON has something like a "reviver".  Has anyone played with that to see
> >>> if it can be used to convert straight to VO's?
> >>> 
> >>> Thanks,
> >>> -Alex 
> >>> 
> >>> On 2/5/18, 1:08 PM, "Gabe Harbs"  wrote:
> >>> 
>  An additional point:
>  
>  How do you propose handling json that’s multiple levels deep? Walk the
>  json and construct VOs on each level? That seems to me just as bad as
>  the
>  problem. Imagine you just want foo.baz.thingy.uid? You’d need to
>  create a
>  VO of foo, baz and thingy or be forced to use
>  foo[“baz”][“thingy”][“uid”]. Of course the average user is 
>  not going to
>  remember to do that until their release build doesn’t work…
>  
>  Creating VOs means you can’t simply use JSON.parse(). You’d need your
>  own
>  parser for each type of json you’re consuming. OK. Maybe not full
>  parsing, but the 

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
> > Sent: Thursday, February 8, 2018 12:33 PM
> > To: 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
> > > Sent: Wednesday, February 7, 2018 6:24 PM
> > > To: 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 

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
> Sent: Thursday, February 8, 2018 12:33 PM
> To: 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
> > Sent: Wednesday, February 7, 2018 6:24 PM
> > To: 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 

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
Sent: Thursday, February 8, 2018 12:33 PM
To: 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
> Sent: Wednesday, February 7, 2018 6:24 PM
> To: 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 

Re: Canvas

[Andrew Wetmore]

Absolutely. I am also going to include this in the help docs list of
features that you do one way in Flex and slightly differently in Royale.

On Thu, Feb 8, 2018 at 6:57 AM, Carlos Rovira 
wrote:

> (moving to dev list)
>
> Hi I think this is a good tip that we can add to our Royale Blog in the
> "Examples" category. And respect the user (ni this case Peter) as the
> poster.
>
> What do you think?
>
> 2018-02-06 15:06 GMT+01:00 Peter Ent :
>
> > Hi,
> >
> > Thanks for looking into Apache Royale!
> >
> > As you know, mx:Canvas lets you place items using (x,y) positioning. You
> > can do the same thing using either js:Group or js:Container with
> > js:BasicLayout.
> >
> > js:Group is much lighter in weight then js:Container when running the app
> > in the Flash Player; in the browser they are equivalent. js:Container can
> > be made to scroll and js:Group cannot.
> >
> > If you do not need scrolling, use js:Group:
> >
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > If you do need scrolling, then you would use:
> >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > Regards,
> > Peter Ent
> > Adobe Systems/Apache Royale Project
> >
> >
> > On 2/6/18, 4:46 AM, "Alina Kazi"  wrote:
> >
> > >Hi,
> > >
> > >I am using mx:Canvas and porting my app to Apache Flexjs/Royale I can't
> > >find
> > >any substitute of it.
> > >
> > >Kindly let me know if there is any other alternate for similar
> > >functionality.
> > >
> > >
> > >
> > >Aleena
> > >
> > >
> > >
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 
Andrew Wetmore

http://cottage14.blogspot.com/

Re: Canvas

[Carlos Rovira]

(moving to dev list)

Hi I think this is a good tip that we can add to our Royale Blog in the
"Examples" category. And respect the user (ni this case Peter) as the
poster.

What do you think?

2018-02-06 15:06 GMT+01:00 Peter Ent :

> Hi,
>
> Thanks for looking into Apache Royale!
>
> As you know, mx:Canvas lets you place items using (x,y) positioning. You
> can do the same thing using either js:Group or js:Container with
> js:BasicLayout.
>
> js:Group is much lighter in weight then js:Container when running the app
> in the Flash Player; in the browser they are equivalent. js:Container can
> be made to scroll and js:Group cannot.
>
> If you do not need scrolling, use js:Group:
>
> 
> 
> 
> 
> 
> 
>
> If you do need scrolling, then you would use:
>
> 
> 
> 
> 
> 
> 
> 
>
> Regards,
> Peter Ent
> Adobe Systems/Apache Royale Project
>
>
> On 2/6/18, 4:46 AM, "Alina Kazi"  wrote:
>
> >Hi,
> >
> >I am using mx:Canvas and porting my app to Apache Flexjs/Royale I can't
> >find
> >any substitute of it.
> >
> >Kindly let me know if there is any other alternate for similar
> >functionality.
> >
> >
> >
> >Aleena
> >
> >
> >
>
>


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

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
> Sent: Wednesday, February 7, 2018 6:24 PM
> To: 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