Re: Royale and Google Search

[Alex Harui]

Update:  Google was able to index the package links, but didn't seen to
index the individual class pages yet.  I just pushed an update to try to
convince Google to crawl the class pages.  We'll see.

But now, if you Google Search for things like "Apache Royale
CartesianChart" you will see a link to chart package in the ASDoc app
written in Royale!  IMO, that proves that Royale apps are searchable.

Later,
-Alex

On 2/20/18, 11:26 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>that's a great start for routing in royale. Thanks for sharing! :)
>
>2018-02-20 17:27 GMT+01:00 Alex Harui :
>
>> Hi,
>>
>> The other day, I requested that Google index the ASDoc at
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Froyale.ap
>>ache.org%2Fasdoc%2F=02%7C01%7Caharui%40adobe.com%7Cb32b5d34557b4f8dc
>>a7d08d57897e295%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547516095
>>370010=c39Aw1nIRyp%2FTi6%2FuJ2giI1yu0W9MFytETSfz%2FV1Kv4%3D
>>d=0
>>
>> The ASDoc is a Royale app, it is not static HTML pages.  Google was able
>> to index it, proving that Google's search crawlers run JavaScript.
>> However, it did not seem to follow the links on the page and index the
>> rest of the ASDoc.  I'm not sure how fast a crawler crawls so maybe it
>> just hasn't gotten around to it.  But I think this proves that you can
>>get
>> parts of your Royale apps indexed by Google.  I'm not sure we ever had a
>> great solution for that with Flex.
>>
>> When I find time, I will try to figure out why Google didn't chase the
>> links on the page to the various components in the ASDoc.  But others
>>are
>> certainly welcome to help.  This is not currently a high-priority task
>>for
>> me.  We are using hash-bang anchor links in the ASDoc, but maybe that is
>> no longer supported by Google and we need to find another routing
>>scheme.
>>
>> Thanks,
>> -Alex
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7Cb32b5d34557b4f8dca7d08d5
>7897e295%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547516095370010
>data=Z2w1C%2Faq%2F7CJ88P8qDUZ4E3bZGk70ZMtMP%2BbJzwwTz8%3D=0

Re: 0.9.2 Release

[Justin Mclean]

Hi,

> The nightly builds have been SHA-512 since Feb 12, so yes 0.9.2 will be
> SHA-512 instead of MD5.

Good to hear the change has been made. [1]  However I noticed that the 
extension on the hash file is required to be “.sha512” not “.SHA-512”. [2]  I 
believe this is to do with how the hash files and mirror system interact. [3] 
(i.e. you need check the hashes directly at Apache not from the mirrors)

>  This is just more FUD from Justin.

I’m sorry you took it that way, there is certainly no intention of that. As I 
said that not everyone may not be aware of the changes to policy in this area 
or following the lists this was discussed on. As this is a public mailing list 
it would help you to be a little more respectful in your style of communication.

Thanks,
Justin

1. http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs/ 

2. https://www.apache.org/dev/release-distribution#sigs-and-sums 

3. https://www.apache.org/info/verification.html#Sign 

Re: "Vivid" to become "Jewel"

[Carlos Rovira]

Hi Piotr,

thanks! :), don't worry I can wait for you to come, I can still be
preparing the "scenario" so when you come is all more easy to collaborate
:).

Regarding names and namespace, I'm a great advocate that these things
matters, I know people can use different prefixes if they want, but in the
end, 99% of the people will use what we put on place. The same as people
using spark in flex ends writing .

but Anyway, I want to know that these change was ok with you all, and as
well notify before making changes suddenly in git about this.

Thanks! :)


2018-03-02 20:50 GMT+01:00 Piotr Zarzycki :

> Hi Carlos,
>
> First of all - Great job! :) You are again creating something awesome and I
> can't wait to join you with help. Still many things holds me off. :)
>
> Some thought about the namespace, I would not bother about that. User can
> have different namespace if they want. In the other words I can have this
> one:
>
> xmlns:js="library://ns.apache.org/royale/basic" but I think I could also
> change it to xmlns:basic="library://ns.apache.org/royale/basic" in my app.
>
> Thanks,
> Piotr
>
> 2018-03-02 20:36 GMT+01:00 Carlos Rovira :
>
> > Hi Alex,
> >
> > don't want to disturb the new release, and as I'm working on a branch, I
> > think all this work will no affect that.
> > My plan is to make some real work first, and maybe this weekend make the
> > renaming, but all in the branch.
> > Maybe, if I get a component or two that looks final in this days, we can
> > merge in develop before you cut the release. In that case at that time I
> > could ask you and see what we can't do
> >
> >
> >
> > 2018-03-02 20:31 GMT+01:00 Alex Harui :
> >
> > > Sounds ok to me.  Are you going to try to do that for 0.9.2 or the next
> > > release?
> > >
> > > -Alex
> > >
> > > On 3/2/18, 11:25 AM, "carlos.rov...@gmail.com on behalf of Carlos
> > Rovira"
> > >  wrote:
> > >
> > > >Hi,
> > > >
> > > >now that we solved part of the technical problems to start making the
> > real
> > > >tasks to skin the components, I was thinking in the main concept for
> > > >vivid,
> > > >and think the name is not right. I take that to avoid thinking and
> make
> > > >starting to work on this, but now I think a best name for this UI set
> > > >could
> > > >be "Jewel", as one of the precious stones use to decorate a crown
> (like
> > > >the
> > > >one in our Royale logo).
> > > >
> > > >In the other hand the namespace prefix will be "j" so for example
> we'll
> > be
> > > >writing " that could recall to js and javascript, but more
> > > >simple since a think only one letter is very good ;)
> > > >
> > > >I know this is maybe a little thing, and maybe more "a side" from the
> > code
> > > >things we use to handle, but I always think that concepts and all the
> > > >things that wire all together are as well important so people know we
> > work
> > > >all from various sides and try to get the best.
> > > >
> > > >Let me know what do you think about it
> > > >
> > > >Thanks!
> > > >
> > > >--
> > > >Carlos Rovira
> > > >https://na01.safelinks.protection.outlook.com/?url=
> > > http%3A%2F%2Fabout.me%2
> > > >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> > > 7Cf1c486d4090b477ecee608d5
> > > >8073612d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > > 7C636556155398287246
> > > >data=khkjgr%2BzQu7%2BoLiu43Od2e9pR6yOJ%2BEQFqI0b97Io4w%3D=0
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



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

Re: Quick poll for Jewel Button

[Carlos Rovira]

Ok,

so for now, I'll go with Basic inheritance and will follow naming
conventions. Then we can have a Jewel-Express set...

thanks for your advice

Carlos

2018-03-02 21:19 GMT+01:00 Alex Harui :

> The reason for a separate Button vs TextButton is that there are (or will
> be) lots of buttons that never have text so there is no point to creating
> text elements/nodes for them.  Such as the up/down in NumericStepper,
> play/record/pause in Video/Audio components, bold/italic/underline in a
> Rich Text Editor.  In the Jewel set and for Basic, you are welcome to
> propose different names if you think that Button really should have text
> support and, maybe, a GraphicOnlyButton should be the base for non-text
> Buttons.  The names don't matter much to me.  The PAYG pattern does matter.
>
> In Express, there can be a single Button that has text and image support
> built-in.
>
> And if we do emulations of mx:Button and s:Button, those will have text
> support built-in.  And using Jewel for the default look there would
> probably be a good thing.
>
> My 2 cents,
> -Alex
>
> On 3/2/18, 11:48 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi,
> >
> >let me know what do you think about :
> >
> >* Should Button in Jewel UI Set be named as "Button" or "TextButton"?
> >(I see more natural a "Button" that a "TextButton")
> >
> >
> >* Should the main Button in Jewel UI Set inherit from TextButton in
> >"Basic"
> >or "Express"?
> >(that means to have "enabled", "toolTip"...)
> >
> >
> >responses to some of this question could be interpreted or applied to more
> >Jewel components and how to deal with it as I create them
> >
> >Thanks
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C28c42f8bcea94c1779f708d5
> >80769af2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636556169279454673
> >data=uDCo5Tc34xNdnWtmFYSv2PDHgOXsvberO2TvHZyPVaw%3D=0
>
>


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

Re: Quick poll for Jewel Button

[Alex Harui]

The reason for a separate Button vs TextButton is that there are (or will
be) lots of buttons that never have text so there is no point to creating
text elements/nodes for them.  Such as the up/down in NumericStepper,
play/record/pause in Video/Audio components, bold/italic/underline in a
Rich Text Editor.  In the Jewel set and for Basic, you are welcome to
propose different names if you think that Button really should have text
support and, maybe, a GraphicOnlyButton should be the base for non-text
Buttons.  The names don't matter much to me.  The PAYG pattern does matter.

In Express, there can be a single Button that has text and image support
built-in.

And if we do emulations of mx:Button and s:Button, those will have text
support built-in.  And using Jewel for the default look there would
probably be a good thing.

My 2 cents,
-Alex

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

>Hi,
>
>let me know what do you think about :
>
>* Should Button in Jewel UI Set be named as "Button" or "TextButton"?
>(I see more natural a "Button" that a "TextButton")
>
>
>* Should the main Button in Jewel UI Set inherit from TextButton in
>"Basic"
>or "Express"?
>(that means to have "enabled", "toolTip"...)
>
>
>responses to some of this question could be interpreted or applied to more
>Jewel components and how to deal with it as I create them
>
>Thanks
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C28c42f8bcea94c1779f708d5
>80769af2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636556169279454673
>data=uDCo5Tc34xNdnWtmFYSv2PDHgOXsvberO2TvHZyPVaw%3D=0

Re: Quick poll for Jewel Button

[Piotr Zarzycki]

Hi Carlos,

In my opinion the simpler it is the better. If you can provide simple
component, that should be user responsibility create using beads/css or
other items more sophisticated things.
OR we could do this in a separate module.

I agree with the idea to do not repeat large and heavy components which
were in Flex.

Thanks, Piotr

2018-03-02 20:48 GMT+01:00 Carlos Rovira :

> Hi,
>
> let me know what do you think about :
>
> * Should Button in Jewel UI Set be named as "Button" or "TextButton"?
> (I see more natural a "Button" that a "TextButton")
>
>
> * Should the main Button in Jewel UI Set inherit from TextButton in "Basic"
> or "Express"?
> (that means to have "enabled", "toolTip"...)
>
>
> responses to some of this question could be interpreted or applied to more
> Jewel components and how to deal with it as I create them
>
> Thanks
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: "Vivid" to become "Jewel"

[Piotr Zarzycki]

Hi Carlos,

First of all - Great job! :) You are again creating something awesome and I
can't wait to join you with help. Still many things holds me off. :)

Some thought about the namespace, I would not bother about that. User can
have different namespace if they want. In the other words I can have this
one:

xmlns:js="library://ns.apache.org/royale/basic" but I think I could also
change it to xmlns:basic="library://ns.apache.org/royale/basic" in my app.

Thanks,
Piotr

2018-03-02 20:36 GMT+01:00 Carlos Rovira :

> Hi Alex,
>
> don't want to disturb the new release, and as I'm working on a branch, I
> think all this work will no affect that.
> My plan is to make some real work first, and maybe this weekend make the
> renaming, but all in the branch.
> Maybe, if I get a component or two that looks final in this days, we can
> merge in develop before you cut the release. In that case at that time I
> could ask you and see what we can't do
>
>
>
> 2018-03-02 20:31 GMT+01:00 Alex Harui :
>
> > Sounds ok to me.  Are you going to try to do that for 0.9.2 or the next
> > release?
> >
> > -Alex
> >
> > On 3/2/18, 11:25 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"
> >  wrote:
> >
> > >Hi,
> > >
> > >now that we solved part of the technical problems to start making the
> real
> > >tasks to skin the components, I was thinking in the main concept for
> > >vivid,
> > >and think the name is not right. I take that to avoid thinking and make
> > >starting to work on this, but now I think a best name for this UI set
> > >could
> > >be "Jewel", as one of the precious stones use to decorate a crown (like
> > >the
> > >one in our Royale logo).
> > >
> > >In the other hand the namespace prefix will be "j" so for example we'll
> be
> > >writing " that could recall to js and javascript, but more
> > >simple since a think only one letter is very good ;)
> > >
> > >I know this is maybe a little thing, and maybe more "a side" from the
> code
> > >things we use to handle, but I always think that concepts and all the
> > >things that wire all together are as well important so people know we
> work
> > >all from various sides and try to get the best.
> > >
> > >Let me know what do you think about it
> > >
> > >Thanks!
> > >
> > >--
> > >Carlos Rovira
> > >https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2
> > >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> > 7Cf1c486d4090b477ecee608d5
> > >8073612d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636556155398287246
> > >data=khkjgr%2BzQu7%2BoLiu43Od2e9pR6yOJ%2BEQFqI0b97Io4w%3D=0
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Quick poll for Jewel Button

[Carlos Rovira]

Hi,

let me know what do you think about :

* Should Button in Jewel UI Set be named as "Button" or "TextButton"?
(I see more natural a "Button" that a "TextButton")


* Should the main Button in Jewel UI Set inherit from TextButton in "Basic"
or "Express"?
(that means to have "enabled", "toolTip"...)


responses to some of this question could be interpreted or applied to more
Jewel components and how to deal with it as I create them

Thanks


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

Re: "Vivid" to become "Jewel"

[Carlos Rovira]

Hi Alex,

don't want to disturb the new release, and as I'm working on a branch, I
think all this work will no affect that.
My plan is to make some real work first, and maybe this weekend make the
renaming, but all in the branch.
Maybe, if I get a component or two that looks final in this days, we can
merge in develop before you cut the release. In that case at that time I
could ask you and see what we can't do



2018-03-02 20:31 GMT+01:00 Alex Harui :

> Sounds ok to me.  Are you going to try to do that for 0.9.2 or the next
> release?
>
> -Alex
>
> On 3/2/18, 11:25 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi,
> >
> >now that we solved part of the technical problems to start making the real
> >tasks to skin the components, I was thinking in the main concept for
> >vivid,
> >and think the name is not right. I take that to avoid thinking and make
> >starting to work on this, but now I think a best name for this UI set
> >could
> >be "Jewel", as one of the precious stones use to decorate a crown (like
> >the
> >one in our Royale logo).
> >
> >In the other hand the namespace prefix will be "j" so for example we'll be
> >writing " that could recall to js and javascript, but more
> >simple since a think only one letter is very good ;)
> >
> >I know this is maybe a little thing, and maybe more "a side" from the code
> >things we use to handle, but I always think that concepts and all the
> >things that wire all together are as well important so people know we work
> >all from various sides and try to get the best.
> >
> >Let me know what do you think about it
> >
> >Thanks!
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7Cf1c486d4090b477ecee608d5
> >8073612d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636556155398287246
> >data=khkjgr%2BzQu7%2BoLiu43Od2e9pR6yOJ%2BEQFqI0b97Io4w%3D=0
>
>


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

Re: "Vivid" to become "Jewel"

[Alex Harui]

Sounds ok to me.  Are you going to try to do that for 0.9.2 or the next
release?

-Alex

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

>Hi,
>
>now that we solved part of the technical problems to start making the real
>tasks to skin the components, I was thinking in the main concept for
>vivid,
>and think the name is not right. I take that to avoid thinking and make
>starting to work on this, but now I think a best name for this UI set
>could
>be "Jewel", as one of the precious stones use to decorate a crown (like
>the
>one in our Royale logo).
>
>In the other hand the namespace prefix will be "j" so for example we'll be
>writing " that could recall to js and javascript, but more
>simple since a think only one letter is very good ;)
>
>I know this is maybe a little thing, and maybe more "a side" from the code
>things we use to handle, but I always think that concepts and all the
>things that wire all together are as well important so people know we work
>all from various sides and try to get the best.
>
>Let me know what do you think about it
>
>Thanks!
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7Cf1c486d4090b477ecee608d5
>8073612d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636556155398287246
>data=khkjgr%2BzQu7%2BoLiu43Od2e9pR6yOJ%2BEQFqI0b97Io4w%3D=0

API Report Summary for a Flex Web Browser Application

[Alex Harui]

Hi Folks,

As you may know, we've received a ton of raw data from a user with a
rather large Flex application. There were over 600 MXML files involved,
AIUI.  I've got it crunched down in a spreadsheet.  Alina, are you ok if
we post that spreadsheet somewhere?

I've cut and pasted the dependencies on Flash, MX, and Spark APIs below.
The number next to each API is not an exact count of usage, but the higher
the number is, the more it has been used.  The number is the number of
times the compiler had to go resolve that symbol/string to a definition.
Sometimes, in the process of generating output, the compiler will resolve
a string more than once.

There are: 
-about 260 Flash APIs being "used" over 80,000 times
-about 1400 MX APIs being "used" over 1 million times
-about 650 Spark APIs being "used" over 350,000 times

Of course, the tooling that generated this report might be buggy, but I
think this data gives a sense for how many change to the source code would
be required to replace all Flex APIs with Royale APIs.  The challenge for
creating emulations is to emulate these 2000 or so APIs before September.
That's about 10 a day, if I'm doing my math right, which seems doable.
I'm wondering if we want to emulate the Flash APIs or not, though.  That
seems like a slippery slope towards emulating the entire player, which I
think is too much to take on.  Otherwise, the challenge is to make a
thousands if not millions of search/replace changes and then try to debug
all of the ones that don't work.  If we go with emulations, a single fix
to the emulation component will be reflected in all uses of that component
(of course, there could be side-effect as well).  I think the approach to
take would be to emulate the most popular uses and stub the rest.

Thoughts?
-Alex


flash.display.Bitmap10
flash.display.Bitmap:smoothing  4
flash.display.CapsStyle 54
flash.display.CapsStyle:NONE21
flash.display.DisplayObject 578
flash.display.DisplayObject:addEventListener12
flash.display.DisplayObject:alpha   4
flash.display.DisplayObject:height  22
flash.display.DisplayObject:localToGlobal   13
flash.display.DisplayObject:name17
flash.display.DisplayObject:parent  76
flash.display.DisplayObject:removeEventListener 12
flash.display.DisplayObject:rotation4
flash.display.DisplayObject:stage   1064
flash.display.DisplayObject:toString16
flash.display.DisplayObject:transform   162
flash.display.DisplayObject:visible 69
flash.display.DisplayObject:width   22
flash.display.DisplayObject:x   36
flash.display.DisplayObject:y   36
flash.display.DisplayObjectContainer73
flash.display.DisplayObjectContainer:addEventListener   16
flash.display.DisplayObjectContainer:contains   4
flash.display.DisplayObjectContainer:getChildAt 8
flash.display.DisplayObjectContainer:getChildByName 3
flash.display.DisplayObjectContainer:getChildIndex  39
flash.display.DisplayObjectContainer:hasOwnProperty 4
flash.display.DisplayObjectContainer:height 9
flash.display.DisplayObjectContainer:mouseChildren  3
flash.display.DisplayObjectContainer:numChildren23
flash.display.DisplayObjectContainer:parent 8
flash.display.DisplayObjectContainer:removeChild20
flash.display.DisplayObjectContainer:setChildIndex  12
flash.display.DisplayObjectContainer:tabChildren13
flash.display.DisplayObjectContainer:width  9
flash.display.GradientType  72
flash.display.GradientType:LINEAR   28
flash.display.Graphics  73
flash.display.Graphics:beginFill88
flash.display.Graphics:beginGradientFill16
flash.display.Graphics:clear80
flash.display.Graphics:curveTo  8
flash.display.Graphics:drawCircle   4
flash.display.Graphics:drawEllipse  8
flash.display.Graphics:drawRect 84
flash.display.Graphics:drawRoundRect8
flash.display.Graphics:drawRoundRectComplex 16
flash.display.Graphics:endFill  96
flash.display.Graphics:lineStyle124
flash.display.Graphics:lineTo   60
flash.display.Graphics:moveTo   64
flash.display.InteractiveObject:addEventListener8
flash.display.InteractiveObject:height  8
flash.display.InteractiveObject:mouseEnabled7
flash.display.InterpolationMethod   18
flash.display.InterpolationMethod:LINEAR_RGB7
flash.display.JointStyle54
flash.display.JointStyle:MITER  21
flash.display.LineScaleMode 54
flash.display.LineScaleMode:NORMAL  21
flash.display.Loader18
flash.display.Loader:content5
flash.display.Loader:contentLoaderInfo  18
flash.display.Loader:height 32
flash.display.Loader:load   4
flash.display.Loader:loadBytes  4
flash.display.Loader:mask   4
flash.display.Loader:width  32
flash.display.Loader:x  12
flash.display.Loader:y  12
flash.display.Shape 8
flash.display.Shape:graphics120
flash.display.Shape:visible 8
flash.display.SpreadMethod  18
flash.display.SpreadMethod:PAD  7
flash.display.Sprite11

Re: TypeNames vs ClassName

[Alex Harui]

Again, the principles of PAYG are that there is as little Just-in-case
code as possible.  AIUI, every MDL user will be downloading and
initializing the ClassList prototype just-in-case.  This is not true of
Strings.  It isn't just the cost of instantiation.  There are download and
class initialization costs.  Array operations are not cheap in Flash, not
sure about JS.

There may be other space-delimited lists in world and having a generic
top-level function "addToSpaceDelimitedList" and
"removeFromSpaceDelimitedList" would be opt-in by the users who choose to
manipulate their classNames with these helper functions.  It does not make
sense to me to bake use of these functions into MDL.  The only portion of
the final classname that needs manipulation like this is the className
property itself, not the attribute pieces or typenames.  Also, with
separate will named utility functions, folks could use these functions if
they run into other space delimited lists.

My 2 cents,
-Alex

On 3/2/18, 1:36 AM, "Harbs"  wrote:

>I do agree that this is pretty low on the list of priorities. I did not
>have a head to work on anything “serious” and the class lists was a nice
>distraction for me. I’m certainly fine with however Piotr handles this. I
>would like to point out a few things:
>
>1. Object instantiation is pretty cheap in JS. A CSSClassList object is
>no heavier than an empty String. 8 empty strings use more memory than a
>single CSSClassList.
>2. Array.join() is about the same computational-wise as string
>concatenation.
>3. The “list” is not being added anywhere the empty strings would not be
>added, so it’s no less PAYG than strings.
>4. An instantiated class such as this would fit better in case we need to
>play with class lists in beads because the CSSClassList object could be
>passed around and modified by different classes without exposing private
>variables and/or strands and beads needing to know about each other. I
>don’t think static utility classes are any less PAYG in this case.
>
>Thanks,
>Harbs
>
>> On Mar 2, 2018, at 7:42 AM, Piotr Zarzycki 
>>wrote:
>> 
>> Hi Harbs,
>> 
>> As much as I like Array approach I took Alex's words more serious that
>> having an Array in the game here could be more heavier than String
>> concatenation. It's earlier in the discussion.
>> 
>> Piotr
>> 
>> 
>> 2018-03-02 3:26 GMT+01:00 Alex Harui :
>> 
>>> Very nice, but IMO, this is over-engineering.  We are talking about a
>>> space-delimited list where some portion of it is considered "fixed"
>>> another portion is user-settable and another portion comes from other
>>> attributes.  Some generic StringUtils or ListUtils might be more PAYG,
>>> especially if they are opt-in and just used to manage the user-settable
>>> portion.  Think of it this way:  Every MDL app needs to carry around
>>> ClassList even if they never change the classname.  I don't care too
>>>much
>>> since it is in MDL and not in the core, so keep it if you want to, but
>>>I
>>> can think of lots of other tasks we should be working on than creating
>>> cool classes to manage a list of strings.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 3/1/18, 3:51 PM, "Harbs"  wrote:
>>> 
 What do you think of the CSSClassList class I just committed?
 
 I *think* that makes the pattern more recognizable and probably is
less
 heavy if more than one class can be used.
 
 Harbs
 
> On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki
>
> wrote:
> 
> Harbs, Alex,
> 
> I just pushed implementation of computeFinalClassNames to
> branch feature/type_names_class_name_issue124. You can review
> implementation in this commit [1] and example of usage in Card and
> Button.
> 
> I have tested with Harbs example [3] and with Card by changing
>orders.
> It's
> working.
> 
> [1]
> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fbit.ly%2F
> 
>2HTHaFQ=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57f
>cf
>>> 6
> c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>>> 7C636555451956879397
> =5EDairk%2BdGWuPE20vIR8jGFcRSflwqQIcw48oCPydYU%3D=0
> [2]
> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fbit.ly%2F
> 
>2oJgKOf=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57f
>cf
>>> 6
> c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>>> 7C636555451956879397
> =8hIfKGYzhaInYfubnf3lUKbYZWRUANzEcWHj3Pkn3Ho%3D=0
> [3]
> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fbit.ly%2F
> 
>2F734nx=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57f
>cf
>>> 6
> c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>>> 7C636555451956879397
> =9I9q1KjL5VNE5CJSAVTtwN9hhR2rco4ovIzJjQ74%2FeY%3D=0
> 
> Waiting for your review.
> 
> 

Re: 0.9.2 Release

[Dave Fisher]

Thank you sir!

> On Mar 2, 2018, at 8:36 AM, Alex Harui  wrote:
> 
> The nightly builds have been SHA-512 since Feb 12, so yes 0.9.2 will be
> SHA-512 instead of MD5.  This is just more FUD from Justin.
> 
> -Alex
> 
> On 3/2/18, 8:20 AM, "Dave Fisher"  wrote:
> 
>> Hi Justin,
>> 
>> 
>> 
>>> Also not everyone may be aware are some new considerations around
>>> hashes for releases. [2] But it is easily to comply, compared to the
>>> last release you would need to add a SHA hash file or replace the
>>> existing MD5 file with a SHA file.
>> 
>> (a) Alex is aware.
>> (b) The policy just officially changed this week. I don’t think that
>> instant compliance is expected. Henk is watching - everyone can look here
>> to see how all the projects stack up. [1]
>> 
>> Alex - are you waiting for the next release to make the SHA changes?
>> 
>> Regards,
>> Dave
>> 
>> 
>> 
>> [1] http://checker.apache.org
>> 
>>> 2. https://www.apache.org/dev/release-distribution#sigs-and-sums
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: 0.9.2 Release

[Dave Fisher]

Hi Justin,



> Also not everyone may be aware are some new considerations around hashes for 
> releases. [2] But it is easily to comply, compared to the last release you 
> would need to add a SHA hash file or replace the existing MD5 file with a SHA 
> file.

(a) Alex is aware.
(b) The policy just officially changed this week. I don’t think that instant 
compliance is expected. Henk is watching - everyone can look here to see how 
all the projects stack up. [1]

Alex - are you waiting for the next release to make the SHA changes?

Regards,
Dave



[1] http://checker.apache.org

> 2. https://www.apache.org/dev/release-distribution#sigs-and-sums



signature.asc
Description: Message signed with OpenPGP

Re: 0.9.2 Release

[OmPrakash Muppirala]

On Mar 2, 2018 5:33 AM, "Justin Mclean"  wrote:

Hi,

> I don’t know what the text in the LICENSE file means because the data
does not seem to be the same. Is the LICENSE file out of date?

Perhaps but unlikely as the URL in the LICENSE was changed a few weeks ago
[1]. I’d guess that perhaps the URL in the LICENSE was changed but the
change to the data wasn’t checked in??


Yes, that was my mistake.  I will be fixing this up soon.

Thanks,
Om


Thanks,
Justin

1. https://github.com/apache/royale-asjs/commit/
59f83f7c65ef0d393474f7e65abd0b4759e3648b#diff-9879d6db96fd29134fc802214163b9
5a

Re: 0.9.2 Release

[Justin Mclean]

Hi,

> I don’t know what the text in the LICENSE file means because the data does 
> not seem to be the same. Is the LICENSE file out of date?

Perhaps but unlikely as the URL in the LICENSE was changed a few weeks ago [1]. 
I’d guess that perhaps the URL in the LICENSE was changed but the change to the 
data wasn’t checked in??

Thanks,
Justin

1. 
https://github.com/apache/royale-asjs/commit/59f83f7c65ef0d393474f7e65abd0b4759e3648b#diff-9879d6db96fd29134fc802214163b95a

Re: 0.9.2 Release

[Harbs]

OK. I did not notice that.

I don’t know what the text in the LICENSE file means because the data does not 
seem to be the same. Is the LICENSE file out of date?

Om, can you shed some light on this?

Thanks,
Harbs

> On Mar 2, 2018, at 2:56 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> I have no idea why you are assuming the data in MapCoords.as comes from 
>> https://commons.wikimedia.org/wiki/File:Blank_US_map_1860.svg 
>> 
> 
> Because the current LICENSE file mentions 
> https://upload.wikimedia.org/wikipedia/commons/5/59/Blank_US_map_1860.svg as 
> the source and https://commons.wikimedia.org/wiki/File:Blank_US_map_1860.svg 
> links to 
> https://upload.wikimedia.org/wikipedia/commons/5/59/Blank_US_map_1860.svg. 
> 
> Alex also raised it as a possible licensing issue in the same thread.
> 
> Thanks,
> Justin
> 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Harbs,

Thanks for such a good explanation. I think I will go with your class.



2018-03-02 10:36 GMT+01:00 Harbs :

> I do agree that this is pretty low on the list of priorities. I did not
> have a head to work on anything “serious” and the class lists was a nice
> distraction for me. I’m certainly fine with however Piotr handles this. I
> would like to point out a few things:
>
> 1. Object instantiation is pretty cheap in JS. A CSSClassList object is no
> heavier than an empty String. 8 empty strings use more memory than a single
> CSSClassList.
> 2. Array.join() is about the same computational-wise as string
> concatenation.
> 3. The “list” is not being added anywhere the empty strings would not be
> added, so it’s no less PAYG than strings.
> 4. An instantiated class such as this would fit better in case we need to
> play with class lists in beads because the CSSClassList object could be
> passed around and modified by different classes without exposing private
> variables and/or strands and beads needing to know about each other. I
> don’t think static utility classes are any less PAYG in this case.
>
> Thanks,
> Harbs
>
> > On Mar 2, 2018, at 7:42 AM, Piotr Zarzycki 
> wrote:
> >
> > Hi Harbs,
> >
> > As much as I like Array approach I took Alex's words more serious that
> > having an Array in the game here could be more heavier than String
> > concatenation. It's earlier in the discussion.
> >
> > Piotr
> >
> >
> > 2018-03-02 3:26 GMT+01:00 Alex Harui :
> >
> >> Very nice, but IMO, this is over-engineering.  We are talking about a
> >> space-delimited list where some portion of it is considered "fixed"
> >> another portion is user-settable and another portion comes from other
> >> attributes.  Some generic StringUtils or ListUtils might be more PAYG,
> >> especially if they are opt-in and just used to manage the user-settable
> >> portion.  Think of it this way:  Every MDL app needs to carry around
> >> ClassList even if they never change the classname.  I don't care too
> much
> >> since it is in MDL and not in the core, so keep it if you want to, but I
> >> can think of lots of other tasks we should be working on than creating
> >> cool classes to manage a list of strings.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 3/1/18, 3:51 PM, "Harbs"  wrote:
> >>
> >>> What do you think of the CSSClassList class I just committed?
> >>>
> >>> I *think* that makes the pattern more recognizable and probably is less
> >>> heavy if more than one class can be used.
> >>>
> >>> Harbs
> >>>
>  On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
>  wrote:
> 
>  Harbs, Alex,
> 
>  I just pushed implementation of computeFinalClassNames to
>  branch feature/type_names_class_name_issue124. You can review
>  implementation in this commit [1] and example of usage in Card and
>  Button.
> 
>  I have tested with Harbs example [3] and with Card by changing orders.
>  It's
>  working.
> 
>  [1]
>  https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fbit.ly%2F
>  2HTHaFQ=02%7C01%7Caharui%40adobe.com%
> 7C9ba2ae2d1a6e4fdc774508d57fcf
> >> 6
>  c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
> >> 7C636555451956879397
>  =5EDairk%2BdGWuPE20vIR8jGFcRSflwqQIcw48oCPydYU%3D=0
>  [2]
>  https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fbit.ly%2F
>  2oJgKOf=02%7C01%7Caharui%40adobe.com%
> 7C9ba2ae2d1a6e4fdc774508d57fcf
> >> 6
>  c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
> >> 7C636555451956879397
>  =8hIfKGYzhaInYfubnf3lUKbYZWRUANzEcWHj3Pkn3Ho%3D=0
>  [3]
>  https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fbit.ly%2F
>  2F734nx=02%7C01%7Caharui%40adobe.com%
> 7C9ba2ae2d1a6e4fdc774508d57fcf
> >> 6
>  c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
> >> 7C636555451956879397
>  =9I9q1KjL5VNE5CJSAVTtwN9hhR2rco4ovIzJjQ74%2FeY%3D=0
> 
>  Waiting for your review.
> 
>  Thanks,
>  Piotr
> 
> 
>  2018-02-28 23:31 GMT+01:00 Piotr Zarzycki  >:
> 
> > Let me play with implementation of that function. It seems to me that
> > will
> > be much cleaner than current solution.
> >
> > If user actually wanted to do anythin with className - let the
> > overriding
> > speaks.
> >
> >
> >
> > On Wed, Feb 28, 2018, 21:51 Alex Harui 
> > wrote:
> >
> >> On 2/28/18, 12:27 PM, "Harbs"  wrote:
> >>
> >>> OK. I think that will work for DML components, but what if there’s
> a
> >>> bead
> >>> which needs to add class names? What would be the “right” way to do
> >>> that?
> >>> A bead cannot override the function on the strand.
> >>
> >> Do we have beads that 

Re: 0.9.2 Release

[Harbs]

I have no idea why you are assuming the data in MapCoords.as comes from 
https://commons.wikimedia.org/wiki/File:Blank_US_map_1860.svg 


The data strings are different.

Alex already mentioned SHA.

Thanks,
Harbs

> On Mar 2, 2018, at 9:59 AM, Justin Mclean  wrote:
> 
> Hi,
> 
> AFAIK there’s still an outstanding license issue [1]. The license [3] links 
> to this [4] which doesn't look compatible with the Apache 2.0 license.
> 
> Also not everyone may be aware are some new considerations around hashes for 
> releases. [2] But it is easily to comply, compared to the last release you 
> would need to add a SHA hash file or replace the existing MD5 file with a SHA 
> file.
> 
> Thanks,
> Justin
> 
> 1. 
> https://lists.apache.org/thread.html/a23ba2777a6b2a279597a85467c30da312d765f766e7d0132671de89@%3Ccommits.royale.apache.org%3E
> 2. https://www.apache.org/dev/release-distribution#sigs-and-sums
> 3. https://github.com/apache/royale-asjs/blob/develop/LICENSE
> 4. https://commons.wikimedia.org/wiki/File:Blank_US_map_1860.svg

Re: TypeNames vs ClassName

[Harbs]

I do agree that this is pretty low on the list of priorities. I did not have a 
head to work on anything “serious” and the class lists was a nice distraction 
for me. I’m certainly fine with however Piotr handles this. I would like to 
point out a few things:

1. Object instantiation is pretty cheap in JS. A CSSClassList object is no 
heavier than an empty String. 8 empty strings use more memory than a single 
CSSClassList.
2. Array.join() is about the same computational-wise as string concatenation.
3. The “list” is not being added anywhere the empty strings would not be added, 
so it’s no less PAYG than strings.
4. An instantiated class such as this would fit better in case we need to play 
with class lists in beads because the CSSClassList object could be passed 
around and modified by different classes without exposing private variables 
and/or strands and beads needing to know about each other. I don’t think static 
utility classes are any less PAYG in this case.

Thanks,
Harbs

> On Mar 2, 2018, at 7:42 AM, Piotr Zarzycki  wrote:
> 
> Hi Harbs,
> 
> As much as I like Array approach I took Alex's words more serious that
> having an Array in the game here could be more heavier than String
> concatenation. It's earlier in the discussion.
> 
> Piotr
> 
> 
> 2018-03-02 3:26 GMT+01:00 Alex Harui :
> 
>> Very nice, but IMO, this is over-engineering.  We are talking about a
>> space-delimited list where some portion of it is considered "fixed"
>> another portion is user-settable and another portion comes from other
>> attributes.  Some generic StringUtils or ListUtils might be more PAYG,
>> especially if they are opt-in and just used to manage the user-settable
>> portion.  Think of it this way:  Every MDL app needs to carry around
>> ClassList even if they never change the classname.  I don't care too much
>> since it is in MDL and not in the core, so keep it if you want to, but I
>> can think of lots of other tasks we should be working on than creating
>> cool classes to manage a list of strings.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 3/1/18, 3:51 PM, "Harbs"  wrote:
>> 
>>> What do you think of the CSSClassList class I just committed?
>>> 
>>> I *think* that makes the pattern more recognizable and probably is less
>>> heavy if more than one class can be used.
>>> 
>>> Harbs
>>> 
 On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki 
 wrote:
 
 Harbs, Alex,
 
 I just pushed implementation of computeFinalClassNames to
 branch feature/type_names_class_name_issue124. You can review
 implementation in this commit [1] and example of usage in Card and
 Button.
 
 I have tested with Harbs example [3] and with Card by changing orders.
 It's
 working.
 
 [1]
 https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fbit.ly%2F
 2HTHaFQ=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57fcf
>> 6
 c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>> 7C636555451956879397
 =5EDairk%2BdGWuPE20vIR8jGFcRSflwqQIcw48oCPydYU%3D=0
 [2]
 https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fbit.ly%2F
 2oJgKOf=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57fcf
>> 6
 c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>> 7C636555451956879397
 =8hIfKGYzhaInYfubnf3lUKbYZWRUANzEcWHj3Pkn3Ho%3D=0
 [3]
 https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fbit.ly%2F
 2F734nx=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57fcf
>> 6
 c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>> 7C636555451956879397
 =9I9q1KjL5VNE5CJSAVTtwN9hhR2rco4ovIzJjQ74%2FeY%3D=0
 
 Waiting for your review.
 
 Thanks,
 Piotr
 
 
 2018-02-28 23:31 GMT+01:00 Piotr Zarzycki :
 
> Let me play with implementation of that function. It seems to me that
> will
> be much cleaner than current solution.
> 
> If user actually wanted to do anythin with className - let the
> overriding
> speaks.
> 
> 
> 
> On Wed, Feb 28, 2018, 21:51 Alex Harui 
> wrote:
> 
>> On 2/28/18, 12:27 PM, "Harbs"  wrote:
>> 
>>> OK. I think that will work for DML components, but what if there’s a
>>> bead
>>> which needs to add class names? What would be the “right” way to do
>>> that?
>>> A bead cannot override the function on the strand.
>> 
>> Do we have beads that manipulate className?
>> 
>> IMO, the principle behind how to handle that is knowing whether you
>> are
>> sharing something or not.  There may not be one right way to handle
>> it,
>> but if I had to handle it, I would have the bead set something in the
>> model or presentation model of the component.  And the component would
>> override 

Re: 0.9.2 Release

[Justin Mclean]

Hi,

AFAIK there’s still an outstanding license issue [1]. The license [3] links to 
this [4] which doesn't look compatible with the Apache 2.0 license.

Also not everyone may be aware are some new considerations around hashes for 
releases. [2] But it is easily to comply, compared to the last release you 
would need to add a SHA hash file or replace the existing MD5 file with a SHA 
file.

Thanks,
Justin

1. 
https://lists.apache.org/thread.html/a23ba2777a6b2a279597a85467c30da312d765f766e7d0132671de89@%3Ccommits.royale.apache.org%3E
2. https://www.apache.org/dev/release-distribution#sigs-and-sums
3. https://github.com/apache/royale-asjs/blob/develop/LICENSE
4. https://commons.wikimedia.org/wiki/File:Blank_US_map_1860.svg