Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Alex Harui]

Hi Greg,

I think I understand your point.  I want to point out, though, that the current 
plan for the emulation set is to make Basic beads the fundamental workhorse of 
this emulation set.  What we are doing is taking, say, the beads used in Basic 
ImageButton and re-using those beads with no or little modification in Spark 
ImageButton.  So that means to me that if there is an API parameter of 
flash.display.BitmapData, that we are going to first choose to rename it to 
something like royale.display.BitmapData and have it subclass the class that is 
used to represent bitmap data in Basic.  I'm not sure how OpenFL implements 
flash.display.BitmapData, but it may or may not be compatible with Basic 
because Basic is going to shove the data into an IMG tag and it appears that to 
do that the data would be base64 encoded and look like:  

"data:image/png;base64,
iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP
C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigBJRU5ErkJggg=="

Similarly, I think some Basic beads use BinaryData so our ByteArray might get 
renamed to royale.utils.ByteArray and subclass our BinaryData so it can be 
passed into the Basic beads.  But we will keep your suggestion in mind.  Thanks 
for bringing it up,
-Alex

On 5/17/18, 5:19 PM, "Greg Dove"  wrote:

Alex, your comment about a full-blown emulation component set built on
openfl display objects could perhaps be a different (and interesting)
approach or 'parallel' option in time. But I wasn't really meaning that at
this point.
I wasn't thinking so much on the 'displaylist' side of things.

I was only intending to suggest that for some of the flash dependencies
inside the emulation classes (e.g. use of ByteArray, for example), it might
be a quick solution to use whatever emulation code openfl has for those
already - even if that is only temporary or transitional.
For ByteArray we do have alternate approaches as discussed, but perhaps
using the openfl code could mean less initial work getting things working
where-ever it is used, because there might be very little change required
from the original code.  Perhaps something like BitmapData might be useful
from openfl, for example (I don't think we have 'emulation' for this yet,
right?). If this works, it could speed things up in emulation efforts
perhaps by focusing more on migrating the 'Flex' specific code and not on
the lower level flash player classes that are not yet emulated but
necessary for some things.
As I said, I only noticed the activity for openfl, and have not
investigated what Joshua is doing there, so just wanted to float the
idea... which is done now, so I will leave it to others to figure out if it
makes sense or not!


On Fri, May 18, 2018 at 10:36 AM, Alex Harui 
wrote:

> Hi Greg,
>
> That's an interesting idea.  My inclination is to recommend that migrators
> get rid of their flash*.* dependencies for two reasons:
>
> 1) I think in many cases there are other JS implementations that will work
> better.  Having a Button be an HTMLButtonElement should be better than it
> being implemented on OpenFL's Sprite.
> 2) Not having code rely on flash*.* makes it easier for us to provide a
> third target someday (WebAsm, Native).
>
> But if folks want to pursue an emulation component set that uses OpenFL
> for flash*.*, it could become a viable solution.  Especially for apps that
> had a lot of custom graphical content.
>
> My 2 cents,
> -Alex
>
> On 5/17/18, 2:33 PM, "Greg Dove"  wrote:
>
> Just a quick suggestion about 'emulation' options.
>
> I notice Joshua Granick has been active in terms of working to get the
> openfl js lib to work as an extern. That does sound interesting
> because I
> think that gives access to the work that has already been done there 
in
> terms of emulation of a lot of the flash.* packages.
>
> I only mention it because it might provide a faster route for getting
> some
> of the internal code inside the emulation classes that use various
> native
> flash utils etc work.
> I have not investigated this, just thought I would mention it in case
> it
> was not something that had been considered - I expect Joshua could
> provide
> a lot more detail about this if asked.
>
>
>
>
> On Fri, May 18, 2018 at 9:18 AM, Alex Harui 
> wrote:
>
> > IMO, because of PAYG, BinaryData should not have 

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Greg Dove]

Alex, your comment about a full-blown emulation component set built on
openfl display objects could perhaps be a different (and interesting)
approach or 'parallel' option in time. But I wasn't really meaning that at
this point.
I wasn't thinking so much on the 'displaylist' side of things.

I was only intending to suggest that for some of the flash dependencies
inside the emulation classes (e.g. use of ByteArray, for example), it might
be a quick solution to use whatever emulation code openfl has for those
already - even if that is only temporary or transitional.
For ByteArray we do have alternate approaches as discussed, but perhaps
using the openfl code could mean less initial work getting things working
where-ever it is used, because there might be very little change required
from the original code.  Perhaps something like BitmapData might be useful
from openfl, for example (I don't think we have 'emulation' for this yet,
right?). If this works, it could speed things up in emulation efforts
perhaps by focusing more on migrating the 'Flex' specific code and not on
the lower level flash player classes that are not yet emulated but
necessary for some things.
As I said, I only noticed the activity for openfl, and have not
investigated what Joshua is doing there, so just wanted to float the
idea... which is done now, so I will leave it to others to figure out if it
makes sense or not!


On Fri, May 18, 2018 at 10:36 AM, Alex Harui 
wrote:

> Hi Greg,
>
> That's an interesting idea.  My inclination is to recommend that migrators
> get rid of their flash*.* dependencies for two reasons:
>
> 1) I think in many cases there are other JS implementations that will work
> better.  Having a Button be an HTMLButtonElement should be better than it
> being implemented on OpenFL's Sprite.
> 2) Not having code rely on flash*.* makes it easier for us to provide a
> third target someday (WebAsm, Native).
>
> But if folks want to pursue an emulation component set that uses OpenFL
> for flash*.*, it could become a viable solution.  Especially for apps that
> had a lot of custom graphical content.
>
> My 2 cents,
> -Alex
>
> On 5/17/18, 2:33 PM, "Greg Dove"  wrote:
>
> Just a quick suggestion about 'emulation' options.
>
> I notice Joshua Granick has been active in terms of working to get the
> openfl js lib to work as an extern. That does sound interesting
> because I
> think that gives access to the work that has already been done there in
> terms of emulation of a lot of the flash.* packages.
>
> I only mention it because it might provide a faster route for getting
> some
> of the internal code inside the emulation classes that use various
> native
> flash utils etc work.
> I have not investigated this, just thought I would mention it in case
> it
> was not something that had been considered - I expect Joshua could
> provide
> a lot more detail about this if asked.
>
>
>
>
> On Fri, May 18, 2018 at 9:18 AM, Alex Harui 
> wrote:
>
> > IMO, because of PAYG, BinaryData should not have compress/uncompress.
> > Feel free to create a BinaryDataWithZLib or something like that.
> > BinaryData has no requirement to fully replace ByteArray.  The
> emulation
> > components will probably have a better emulation of ByteArray.
> >
> > My 2 cents,
> > -Alex
> >
> > On 5/17/18, 7:16 AM, "carlos.rov...@gmail.com on behalf of Carlos
> > Rovira"  carlosrov...@apache.org>
> > wrote:
> >
> > So great! I'll be trying it :-)
> >
> > 2018-05-17 15:41 GMT+02:00 Harbs :
> >
> > > Hah! I forgot I wrote that class… ;-)
> > >
> > > Yes. Pako is a zlib port.
> > >
> > > Thanks,
> > > Harbs
> > >
> > > > On May 17, 2018, at 4:22 PM, Carlos Rovira <
> > carlosrov...@apache.org>
> > > wrote:
> > > >
> > > > I see we already has Compressionutils that uses pako, this
> uses
> > zlib?
> > > >
> > > > thanks
> > > >
> > > > 2018-05-17 15:17 GMT+02:00 Carlos Rovira <
> carlosrov...@apache.org
> > >:
> > > >
> > > >> Hi,
> > > >>
> > > >> BinaryData is the new ByteArray in royale right?
> > > >> I was searching for compress/uncompress methods but seems we
> > don't have
> > > yet
> > > >>
> > > >> I'm missing something here? maybe the compress/uncompress
> > algorithms has
> > > >> some license issues and for that reason wasn't implemented?
> > > >>
> > > >> thanks
> > > >>
> > > >>
> > > >> --
> > > >> Carlos Rovira
> > > >> https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%4
> 

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Alex Harui]

I picked this post to respond to in order to write one response instead of 
several.  Comments Inline...

On 5/17/18, 1:39 PM, "Harbs"  wrote:

Snipping relevant pieces to make it more legible…

Let me use a concrete example to illustrate what I mean: Try compiling the 
DateControlsExample. The example does not use ButtonBar in any manner, shape or 
form. Being so, ButtonBar and all related classes should not be included in the 
output. However, both the ButtonBar CSS and ButtonBar and associated classes 
are included in both debug and release code. I think this can only be 
classified as a bug and this is what we need to fix.

It is a bug.  In the framework.  The defaults.css for Basic has a 
.DynamicDataGrid in it.  It shouldn't have that.  (There might be another 
framework bug where a ClassReference in .DynamicDataGrid referenced DataGrid 
which bring in DataGridButtonBar which brings in ButtonBar)   That's an example 
of Class Selectors being used instead of Type Selectors.  If we created an 
actual subclass of DataGrid called DynamicDataGrid then the CSS could use a 
Type Selector instead of a Class Selector and the problem goes away.   IMO, we 
need to decide on some good ways to stop using class selectors or prune class 
selectors.


I don’t understand why the compiler cannot build a list of used classes and 
drop any CSS references not used.

It does have that depending on what you mean by "used".  If "used" means 
referenced by the code, it appears to be working correctly.  If you are 
suggesting that the compiler tracks whether a class is actually instantiated, 
that's a bit harder mainly because we would need to retain that information in 
the SWC somewhere and we don't currently store compile-time information 
elsewhere in the SWC.  We could try to prune more in post-processing for JS 
only.  We could search every JS file for "new Button", but even then, I think 
you'd miss where a className was stored in a variable and then instantiated 
which is what ValuesManager does.  So I'm not sure the compiler can truly know 
what classes got directly instantiated.

I’m not sure we’re talking the same language. The class selector for 
ImageButton will always be (in HTML css) .ImageButton. So if you have a basic 
ImageButton and a Jewel ImageButton, there will be CSS conflicts in the 
compiled HTML CSS.

The above statement isn't true.  I already mentioned upthread that the HTML css 
could be .org_apache_royale_basic_ImageButton.

I think there is a fundamental disagreement here.  I think we should be 
approximating how Type Selectors work.  That is because fully qualified type 
names are essentially already guaranteed to be unique.  The compiler will catch 
duplicates.  IMO, we want to leverage strong typing.  It is Royale's technical 
advantage over all of the manual conventions I see folks having to use in other 
JS frameworks.  I think you want to propose some scheme to use class selectors 
and not use Type Selectors.  This is doable, but requires a manual convention.  
The component developer theoretically already decided on how to make the fully 
qualified component name unique by selecting a unique package name.  Now you 
want the component developer to have to identify another unique name to ensure 
the class selector names don't collide.  And those names are going to want to 
be "friendly" names like "Basic" and "Jewel".  I don't get why using QNames is 
not sufficient.  If it is too verbose in the output, maybe we can find a way to 
shorten it.  IMO, uniqueness is probably better handled by tooling instead of 
manual conventions.

Let's make sure we can't use Type Selectors before discussion a scheme for 
using Class Selectors.  Uniqueness is built in to Type Selectors.

If one problem is with Type Selectors in Royale inheriting styles from Base 
Classes, we should discuss ways to manage that.  Metadata is possible, but 
metadata is expensive at runtime.  There are two parts to how Type Selectors 
work.  The main concern appears to be the ClassReferences kind of CSS, which is 
not handled by the Browser.  The IValuesImpl has to decide whether to look up 
the base class and it would have to fetch and parse metadata at runtime to do 
that.  And, as I mentioned earlier, I'm not sure the compiler can know whether 
the base class is in the output because it was directly instantiated or not.

Historically, the only reason Type Selectors inherit from Base Classes in Flex 
is because of app developer subclassing.  For sure, we the framework developers 
can always take the time to fill out the Type Selectors such that the lookup 
never goes to the Base Class.  But the app devs just want to use a component as 
the top tag in an MXMLComponent or do a cheap "MyButton extends Button" in AS.  
And without inheritance, you don't get any defaults and things blow up.

We could say to the app devs::  "too bad, in Royale you gotta copy the base 

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Alex Harui]

Hi Greg,

That's an interesting idea.  My inclination is to recommend that migrators get 
rid of their flash*.* dependencies for two reasons:

1) I think in many cases there are other JS implementations that will work 
better.  Having a Button be an HTMLButtonElement should be better than it being 
implemented on OpenFL's Sprite.
2) Not having code rely on flash*.* makes it easier for us to provide a third 
target someday (WebAsm, Native).

But if folks want to pursue an emulation component set that uses OpenFL for 
flash*.*, it could become a viable solution.  Especially for apps that had a 
lot of custom graphical content.

My 2 cents,
-Alex

On 5/17/18, 2:33 PM, "Greg Dove"  wrote:

Just a quick suggestion about 'emulation' options.

I notice Joshua Granick has been active in terms of working to get the
openfl js lib to work as an extern. That does sound interesting because I
think that gives access to the work that has already been done there in
terms of emulation of a lot of the flash.* packages.

I only mention it because it might provide a faster route for getting some
of the internal code inside the emulation classes that use various native
flash utils etc work.
I have not investigated this, just thought I would mention it in case it
was not something that had been considered - I expect Joshua could provide
a lot more detail about this if asked.




On Fri, May 18, 2018 at 9:18 AM, Alex Harui 
wrote:

> IMO, because of PAYG, BinaryData should not have compress/uncompress.
> Feel free to create a BinaryDataWithZLib or something like that.
> BinaryData has no requirement to fully replace ByteArray.  The emulation
> components will probably have a better emulation of ByteArray.
>
> My 2 cents,
> -Alex
>
> On 5/17/18, 7:16 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> So great! I'll be trying it :-)
>
> 2018-05-17 15:41 GMT+02:00 Harbs :
>
> > Hah! I forgot I wrote that class… ;-)
> >
> > Yes. Pako is a zlib port.
> >
> > Thanks,
> > Harbs
> >
> > > On May 17, 2018, at 4:22 PM, Carlos Rovira <
> carlosrov...@apache.org>
> > wrote:
> > >
> > > I see we already has Compressionutils that uses pako, this uses
> zlib?
> > >
> > > thanks
> > >
> > > 2018-05-17 15:17 GMT+02:00 Carlos Rovira  >:
> > >
> > >> Hi,
> > >>
> > >> BinaryData is the new ByteArray in royale right?
> > >> I was searching for compress/uncompress methods but seems we
> don't have
> > yet
> > >>
> > >> I'm missing something here? maybe the compress/uncompress
> algorithms has
> > >> some license issues and for that reason wasn't implemented?
> > >>
> > >> thanks
> > >>
> > >>
> > >> --
> > >> Carlos Rovira
> > >> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> > >>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> >
> >
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
>
>
>

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Greg Dove]

Just a quick suggestion about 'emulation' options.

I notice Joshua Granick has been active in terms of working to get the
openfl js lib to work as an extern. That does sound interesting because I
think that gives access to the work that has already been done there in
terms of emulation of a lot of the flash.* packages.

I only mention it because it might provide a faster route for getting some
of the internal code inside the emulation classes that use various native
flash utils etc work.
I have not investigated this, just thought I would mention it in case it
was not something that had been considered - I expect Joshua could provide
a lot more detail about this if asked.




On Fri, May 18, 2018 at 9:18 AM, Alex Harui 
wrote:

> IMO, because of PAYG, BinaryData should not have compress/uncompress.
> Feel free to create a BinaryDataWithZLib or something like that.
> BinaryData has no requirement to fully replace ByteArray.  The emulation
> components will probably have a better emulation of ByteArray.
>
> My 2 cents,
> -Alex
>
> On 5/17/18, 7:16 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> So great! I'll be trying it :-)
>
> 2018-05-17 15:41 GMT+02:00 Harbs :
>
> > Hah! I forgot I wrote that class… ;-)
> >
> > Yes. Pako is a zlib port.
> >
> > Thanks,
> > Harbs
> >
> > > On May 17, 2018, at 4:22 PM, Carlos Rovira <
> carlosrov...@apache.org>
> > wrote:
> > >
> > > I see we already has Compressionutils that uses pako, this uses
> zlib?
> > >
> > > thanks
> > >
> > > 2018-05-17 15:17 GMT+02:00 Carlos Rovira  >:
> > >
> > >> Hi,
> > >>
> > >> BinaryData is the new ByteArray in royale right?
> > >> I was searching for compress/uncompress methods but seems we
> don't have
> > yet
> > >>
> > >> I'm missing something here? maybe the compress/uncompress
> algorithms has
> > >> some license issues and for that reason wasn't implemented?
> > >>
> > >> thanks
> > >>
> > >>
> > >> --
> > >> Carlos Rovira
> > >> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> > >>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> >
> >
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
>
>
>

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Alex Harui]

IMO, because of PAYG, BinaryData should not have compress/uncompress.  Feel 
free to create a BinaryDataWithZLib or something like that.  BinaryData has no 
requirement to fully replace ByteArray.  The emulation components will probably 
have a better emulation of ByteArray.

My 2 cents,
-Alex

On 5/17/18, 7:16 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

So great! I'll be trying it :-)

2018-05-17 15:41 GMT+02:00 Harbs :

> Hah! I forgot I wrote that class… ;-)
>
> Yes. Pako is a zlib port.
>
> Thanks,
> Harbs
>
> > On May 17, 2018, at 4:22 PM, Carlos Rovira 
> wrote:
> >
> > I see we already has Compressionutils that uses pako, this uses zlib?
> >
> > thanks
> >
> > 2018-05-17 15:17 GMT+02:00 Carlos Rovira :
> >
> >> Hi,
> >>
> >> BinaryData is the new ByteArray in royale right?
> >> I was searching for compress/uncompress methods but seems we don't have
> yet
> >>
> >> I'm missing something here? maybe the compress/uncompress algorithms 
has
> >> some license issues and for that reason wasn't implemented?
> >>
> >> thanks
> >>
> >>
> >> --
> >> Carlos Rovira
> >> 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
>
>


-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%2FMbYScSZlwI6ToUq%2BulNTETs%3D=0

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Carlos Rovira]

mmm this one seems not as easy as you post.
If you do that in Jewel, then people wanting to mix with Basic will have a
problem.

I think better things simple and prefer the first scenario, simple and
direct. Think that normaly extending what I call "final" component (and I
said that I don't want to mean strictly final) should not be the normal
case since is more flexible and almost same code to have siblings, and
you'll avoid the problems of large inheritance chain (I want to change
something that is private and I can not access, or there was a change in
the parent component set and now the child is behaving different,...)



2018-05-17 22:46 GMT+02:00 Harbs :

> One more point:
>
> If we go the meta-tags route, we can include in the tag whether to include
> base typenames. Something like the following would tell the compiler that
> the org.apache.royale.html.Button typename is not being used.
>
>[Typename(name="Button", prefix=“basic”, inherits=“false")]
>public class Button extends org.apache.royale.html.Button
>
> > On May 17, 2018, at 8:36 PM, Alex Harui 
> wrote:
> >
> > Also I'm trying to figure out how the compiler will know to prune out
> selectors that are not used.
>
>


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

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Carlos Rovira]

I love that idea of Metadata in class. +1 to that one :)

2018-05-17 22:39 GMT+02:00 Harbs :

> Snipping relevant pieces to make it more legible…
>
> >
> > I agree #1 and #2 are creating problems, but they are not bugs in the
> compiler.  I believe the compiler correctly prunes out any Type Selectors
> that are not used.  The compiler must carry over any class and id selectors
> since there is no way to determine if they are used or not (and it must
> bring in any ClassReferences in selectors).  If you have a strategy for a
> feature enhancement by which the compiler can know to prune more stuff, we
> should discuss that.  Just remember that any strategy must apply to
> user-supplied CSS in fx:Style blocks.  I implemented one such strategy
> already.  If you give a class selector a name that uses a fully qualified
> classname (with hyphens instead of dots, so 
> org_apache_royale_html_TextInput_SomeClass)
> then the compiler will prune that class selector if TextInput is not in the
> output.  IMO, the changes required here are in the framework to use that
> naming scheme on any class selectors used in the framework, and/or stop
> using class selectors in the framework.  We could create subclasses for
> just about every class selector currently in the defaults.css for our SWCs.
> >
> > Also note what I wrote in the wiki about "kinds" of CSS.  I believe that
> the framework code is not fully conforming to the recommended practices in
> that wiki article.  If it did, I think there would be far less extra CSS
> being added to the output. As Carlos mentioned, maybe we should work on a
> test case so we have specific code to talk about.
>
> Let me use a concrete example to illustrate what I mean: Try compiling the
> DateControlsExample. The example does not use ButtonBar in any manner,
> shape or form. Being so, ButtonBar and all related classes should not be
> included in the output. However, both the ButtonBar CSS and ButtonBar and
> associated classes are included in both debug and release code. I think
> this can only be classified as a bug and this is what we need to fix.
>
> I don’t understand why the compiler cannot build a list of used classes
> and drop any CSS references not used.
>
> >
> >#3 has a few different ways it can be resolved. The way that Carlos
> and I both like is by using composite class names such as “basic Button”
> and using a selector .basic.Button{} which requires the element to have
> *both* class names applied.
> >
> >The solution above requires that class selectors are used and not
> type selectors. (The same for other solutions which use fully qualified
> names).
> >
> > That is an appealing solution.  In fact, it might be worth adding a name
> like "basic" or "jewel" to the className list of TLCs so users can control
> styles for individual component sets, but that isn't quite PAYG.  It is
> making everyone pay the price for multiple component sets even if they only
> use one.  Also I'm trying to figure out how the compiler will know to prune
> out selectors that are not used.
> >
> > The Type Selectors in defaults.css for SWCs are using fully qualified
> names already.  When you specify the namespace in the defaults.css then
> just having:
> >
> >   @namespace foo
> >   Application {}
> >
> > really means that selector is foo.Application.  But if you have multiple
> namespaces open, then what would you write?  I'm not sure .basic.s|Button
> is allowed.  Needs more investigation.
>
> I’m not sure we’re talking the same language. The class selector for
> ImageButton will always be (in HTML css) .ImageButton. So if you have a
> basic ImageButton and a Jewel ImageButton, there will be CSS conflicts in
> the compiled HTML CSS.
>
> >
> > Sounds like you are saying we shouldn't support extending Type Selectors
> in Royale for non-HTML components.  I think we can approximate it well
> enough to do it.  I think customers will want it and expect it and it will
> be an attractive feature for Royale.  Royale is all about Types, and we
> should leverage it to help optimize the users output.  It is much easier to
> prune based on type selectors than class selectors.
>
> I’m not sure what you mean here. I definitely think we should support
> things like js|ImageButton{background:none}. The question is what that
> will ultimately output in the final css file.
>
> >Some additional points:
> >* Unless we can figure out a way for the compiler to know which
> typenames are *actually* used, to prevent css of superclasses from being
> imported (i.e. basic Button), other components cannot subclass it. (i.e.
> Jewel should not subclass basic Button to prevent basic Button CSS from
> being unnecessarily included.0
> >
> > Interesting question.  However, a "workaround" might be to make sure the
> Application developer can manually prune out unused ClassReferences.
> Often, optimization has to be left to the app dev.  There is no easy way
> for the framework and 

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

One more point:

If we go the meta-tags route, we can include in the tag whether to include base 
typenames. Something like the following would tell the compiler that the 
org.apache.royale.html.Button typename is not being used.

   [Typename(name="Button", prefix=“basic”, inherits=“false")]
   public class Button extends org.apache.royale.html.Button

> On May 17, 2018, at 8:36 PM, Alex Harui  wrote:
> 
> Also I'm trying to figure out how the compiler will know to prune out 
> selectors that are not used.

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

Snipping relevant pieces to make it more legible…

> 
> I agree #1 and #2 are creating problems, but they are not bugs in the 
> compiler.  I believe the compiler correctly prunes out any Type Selectors 
> that are not used.  The compiler must carry over any class and id selectors 
> since there is no way to determine if they are used or not (and it must bring 
> in any ClassReferences in selectors).  If you have a strategy for a feature 
> enhancement by which the compiler can know to prune more stuff, we should 
> discuss that.  Just remember that any strategy must apply to user-supplied 
> CSS in fx:Style blocks.  I implemented one such strategy already.  If you 
> give a class selector a name that uses a fully qualified classname (with 
> hyphens instead of dots, so org_apache_royale_html_TextInput_SomeClass) then 
> the compiler will prune that class selector if TextInput is not in the 
> output.  IMO, the changes required here are in the framework to use that 
> naming scheme on any class selectors used in the framework, and/or stop using 
> class selectors in the framework.  We could create subclasses for just about 
> every class selector currently in the defaults.css for our SWCs.
> 
> Also note what I wrote in the wiki about "kinds" of CSS.  I believe that the 
> framework code is not fully conforming to the recommended practices in that 
> wiki article.  If it did, I think there would be far less extra CSS being 
> added to the output. As Carlos mentioned, maybe we should work on a test case 
> so we have specific code to talk about.

Let me use a concrete example to illustrate what I mean: Try compiling the 
DateControlsExample. The example does not use ButtonBar in any manner, shape or 
form. Being so, ButtonBar and all related classes should not be included in the 
output. However, both the ButtonBar CSS and ButtonBar and associated classes 
are included in both debug and release code. I think this can only be 
classified as a bug and this is what we need to fix.

I don’t understand why the compiler cannot build a list of used classes and 
drop any CSS references not used.

> 
>#3 has a few different ways it can be resolved. The way that Carlos and I 
> both like is by using composite class names such as “basic Button” and using 
> a selector .basic.Button{} which requires the element to have *both* class 
> names applied.
> 
>The solution above requires that class selectors are used and not type 
> selectors. (The same for other solutions which use fully qualified names).
> 
> That is an appealing solution.  In fact, it might be worth adding a name like 
> "basic" or "jewel" to the className list of TLCs so users can control styles 
> for individual component sets, but that isn't quite PAYG.  It is making 
> everyone pay the price for multiple component sets even if they only use one. 
>  Also I'm trying to figure out how the compiler will know to prune out 
> selectors that are not used.
> 
> The Type Selectors in defaults.css for SWCs are using fully qualified names 
> already.  When you specify the namespace in the defaults.css then just having:
> 
>   @namespace foo
>   Application {}
> 
> really means that selector is foo.Application.  But if you have multiple 
> namespaces open, then what would you write?  I'm not sure .basic.s|Button is 
> allowed.  Needs more investigation.

I’m not sure we’re talking the same language. The class selector for 
ImageButton will always be (in HTML css) .ImageButton. So if you have a basic 
ImageButton and a Jewel ImageButton, there will be CSS conflicts in the 
compiled HTML CSS.

> 
> Sounds like you are saying we shouldn't support extending Type Selectors in 
> Royale for non-HTML components.  I think we can approximate it well enough to 
> do it.  I think customers will want it and expect it and it will be an 
> attractive feature for Royale.  Royale is all about Types, and we should 
> leverage it to help optimize the users output.  It is much easier to prune 
> based on type selectors than class selectors. 

I’m not sure what you mean here. I definitely think we should support things 
like js|ImageButton{background:none}. The question is what that will ultimately 
output in the final css file.

>Some additional points:
>* Unless we can figure out a way for the compiler to know which typenames 
> are *actually* used, to prevent css of superclasses from being imported (i.e. 
> basic Button), other components cannot subclass it. (i.e. Jewel should not 
> subclass basic Button to prevent basic Button CSS from being unnecessarily 
> included.0
> 
> Interesting question.  However, a "workaround" might be to make sure the 
> Application developer can manually prune out unused ClassReferences.  Often, 
> optimization has to be left to the app dev.  There is no easy way for the 
> framework and tool chain to really know.  And I think an app dev can prune 
> class references by declaring the Type Selector in custom CSS and setting 
> 

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Carlos Rovira]

Hi Alex,

2018-05-17 19:36 GMT+02:00 Alex Harui :

> Some comments inline.
>
> On 5/17/18, 4:53 AM, "Harbs"  wrote:
>
> OK. Let’s take a step back.
>
> Here’s what I think is the takeaway of the first part of the
> “refactor” discussion. It seems like there are real issues — some of which
> have been partially resolved by Carlos, and none really have to do
> specifically with a project refactor.
>
> There are multiple issues with CSS and component sets:
> 1. As it stands all CSS for all used component sets are imported into
> the final compiled CSS.
> 2. all classes mentioned in said CSS are imported as well.
> 3. The typenames of different component sets collide because they are
> not qualified.
> 4. typenames which match HTML element names are compiled as element
> selectors instead of class selectors.
>
> I think we all agree that #1 and #2 are bugs which need to be fixed in
> the compiler. The exact changes that are needed should be ironed out.
>
> I agree #1 and #2 are creating problems, but they are not bugs in the
> compiler.  I believe the compiler correctly prunes out any Type Selectors
> that are not used.


Harbs, discover like me that this is not completely true. He saw how some
not used compoenents where in his CSS (maybe one was ButtonBar and the
other don't remember. This is in one of this thread.


> The compiler must carry over any class and id selectors since there is no
> way to determine if they are used or not (and it must bring in any
> ClassReferences in selectors).  If you have a strategy for a feature
> enhancement by which the compiler can know to prune more stuff, we should
> discuss that.  Just remember that any strategy must apply to user-supplied
> CSS in fx:Style blocks.  I implemented one such strategy already.  If you
> give a class selector a name that uses a fully qualified classname (with
> hyphens instead of dots, so org_apache_royale_html_TextInput_SomeClass)
> then the compiler will prune that class selector if TextInput is not in the
> output.  IMO, the changes required here are in the framework to use that
> naming scheme on any class selectors used in the framework, and/or stop
> using class selectors in the framework.  We could create subclasses for
> just about every class selector currently in the defaults.css for our SWCs.
>

When we discussed this I thought and wrote some code like
.org_apache_royale_jewel_Button {}, but finaly this seems to me very
verbose and we will end with things like ".org_apache_royale_jewel_Alert
.org_apache_royale_jewel_Group .org_apache_royale_jewel_TitleBar {}" , that
doesn't seem to me the best way.

Regarding subclassing, I as well considered when we commented, but this
seems to me a very heavy solution to create a class definition (with all
that means) to solve a problem that should not requiere to do a subclass,
so I as well prefer not follow that path.


>
> Also note what I wrote in the wiki about "kinds" of CSS.  I believe that
> the framework code is not fully conforming to the recommended practices in
> that wiki article.  If it did, I think there would be far less extra CSS
> being added to the output. As Carlos mentioned, maybe we should work on a
> test case so we have specific code to talk about.
>
>
definitely it will help me figure your previous email.



>
> #3 has a few different ways it can be resolved. The way that Carlos
> and I both like is by using composite class names such as “basic Button”
> and using a selector .basic.Button{} which requires the element to have
> *both* class names applied.
>
> The solution above requires that class selectors are used and not type
> selectors. (The same for other solutions which use fully qualified names).
>
> That is an appealing solution.  In fact, it might be worth adding a name
> like "basic" or "jewel" to the className list of TLCs so users can control
> styles for individual component sets, but that isn't quite PAYG.  It is
> making everyone pay the price for multiple component sets even if they only
> use one.  Also I'm trying to figure out how the compiler will know to prune
> out selectors that are not used.
>
> The Type Selectors in defaults.css for SWCs are using fully qualified
> names already.  When you specify the namespace in the defaults.css then
> just having:
>
>@namespace foo
>Application {}
>
> really means that selector is foo.Application.  But if you have multiple
> namespaces open, then what would you write?  I'm not sure .basic.s|Button
> is allowed.  Needs more investigation.
>
>
>
> On the other hand, I do agree that folks should have a way of
> declaring styling for HTML element types as in normal css. This takes two
> forms.
>
> The first is css with a namespace of "https://na01.safelinks.
> protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%
> 2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%
> 

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Alex Harui]

Some comments inline.

On 5/17/18, 4:53 AM, "Harbs"  wrote:

OK. Let’s take a step back.

Here’s what I think is the takeaway of the first part of the “refactor” 
discussion. It seems like there are real issues — some of which have been 
partially resolved by Carlos, and none really have to do specifically with a 
project refactor.

There are multiple issues with CSS and component sets:
1. As it stands all CSS for all used component sets are imported into the 
final compiled CSS.
2. all classes mentioned in said CSS are imported as well.
3. The typenames of different component sets collide because they are not 
qualified.
4. typenames which match HTML element names are compiled as element 
selectors instead of class selectors.

I think we all agree that #1 and #2 are bugs which need to be fixed in the 
compiler. The exact changes that are needed should be ironed out.

I agree #1 and #2 are creating problems, but they are not bugs in the compiler. 
 I believe the compiler correctly prunes out any Type Selectors that are not 
used.  The compiler must carry over any class and id selectors since there is 
no way to determine if they are used or not (and it must bring in any 
ClassReferences in selectors).  If you have a strategy for a feature 
enhancement by which the compiler can know to prune more stuff, we should 
discuss that.  Just remember that any strategy must apply to user-supplied CSS 
in fx:Style blocks.  I implemented one such strategy already.  If you give a 
class selector a name that uses a fully qualified classname (with hyphens 
instead of dots, so org_apache_royale_html_TextInput_SomeClass) then the 
compiler will prune that class selector if TextInput is not in the output.  
IMO, the changes required here are in the framework to use that naming scheme 
on any class selectors used in the framework, and/or stop using class selectors 
in the framework.  We could create subclasses for just about every class 
selector currently in the defaults.css for our SWCs.

Also note what I wrote in the wiki about "kinds" of CSS.  I believe that the 
framework code is not fully conforming to the recommended practices in that 
wiki article.  If it did, I think there would be far less extra CSS being added 
to the output. As Carlos mentioned, maybe we should work on a test case so we 
have specific code to talk about.


#3 has a few different ways it can be resolved. The way that Carlos and I 
both like is by using composite class names such as “basic Button” and using a 
selector .basic.Button{} which requires the element to have *both* class names 
applied.

The solution above requires that class selectors are used and not type 
selectors. (The same for other solutions which use fully qualified names).

That is an appealing solution.  In fact, it might be worth adding a name like 
"basic" or "jewel" to the className list of TLCs so users can control styles 
for individual component sets, but that isn't quite PAYG.  It is making 
everyone pay the price for multiple component sets even if they only use one.  
Also I'm trying to figure out how the compiler will know to prune out selectors 
that are not used.

The Type Selectors in defaults.css for SWCs are using fully qualified names 
already.  When you specify the namespace in the defaults.css then just having:

   @namespace foo
   Application {}

really means that selector is foo.Application.  But if you have multiple 
namespaces open, then what would you write?  I'm not sure .basic.s|Button is 
allowed.  Needs more investigation.



On the other hand, I do agree that folks should have a way of declaring 
styling for HTML element types as in normal css. This takes two forms.

The first is css with a namespace of 
"https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%7Cd269492fc0b8447b643f08d5bbecdb28%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636621548320427521=DR6FgV9nHlc%2B81Ougp52gH6t7t0IxGcI6QoBS7idDdM%3D=0
 
”.
 This is treated like normal css as I think it should. This allows folks to 
copy csss into their Royale apps and just have it “work”.
The second is the components in the HTML package. All these elements have 
types (i.e. button, input, h1, etc.) but not typenames. As it stands, they will 
be styled correctly using type selectors as they have no default class names.

So, type selectors should work for HTML components as well as an “dynamic” 
HTML created by “whatever”. The type selectors will probably usually be 
overridden by “regular” Royale components because these will usually have 
styling applied 

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

So great! I'll be trying it :-)

2018-05-17 15:41 GMT+02:00 Harbs :

> Hah! I forgot I wrote that class… ;-)
>
> Yes. Pako is a zlib port.
>
> Thanks,
> Harbs
>
> > On May 17, 2018, at 4:22 PM, Carlos Rovira 
> wrote:
> >
> > I see we already has Compressionutils that uses pako, this uses zlib?
> >
> > thanks
> >
> > 2018-05-17 15:17 GMT+02:00 Carlos Rovira :
> >
> >> Hi,
> >>
> >> BinaryData is the new ByteArray in royale right?
> >> I was searching for compress/uncompress methods but seems we don't have
> yet
> >>
> >> I'm missing something here? maybe the compress/uncompress algorithms has
> >> some license issues and for that reason wasn't implemented?
> >>
> >> thanks
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Harbs]

Hah! I forgot I wrote that class… ;-)

Yes. Pako is a zlib port.

Thanks,
Harbs

> On May 17, 2018, at 4:22 PM, Carlos Rovira  wrote:
> 
> I see we already has Compressionutils that uses pako, this uses zlib?
> 
> thanks
> 
> 2018-05-17 15:17 GMT+02:00 Carlos Rovira :
> 
>> Hi,
>> 
>> BinaryData is the new ByteArray in royale right?
>> I was searching for compress/uncompress methods but seems we don't have yet
>> 
>> I'm missing something here? maybe the compress/uncompress algorithms has
>> some license issues and for that reason wasn't implemented?
>> 
>> thanks
>> 
>> 
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Piotr Zarzycki]

I'm sorry Carlos! Serkan is working on something else!

2018-05-17 15:24 GMT+02:00 Carlos Rovira :

> Ok right, for me is ok to use that class and inflate/deflate methods,
> do you know if that methods use the zlib algorithm? if use that we are
> done, since is the same algorithm used in ByteArray
>
> 2018-05-17 15:22 GMT+02:00 Harbs :
>
> > Yes. The big issue with compression is that it adds a lot of code.
> >
> > The most commonly used JS library for compression is pako.[1] I’m using
> > that personally.
> >
> > We don’t want to include something like this in BinaryData because it
> adds
> > a lot of bulk.
> >
> > HTH,
> > Harbs
> >
> > [1]http://nodeca.github.io/pako/ 
> >
> > > On May 17, 2018, at 4:17 PM, Carlos Rovira 
> > wrote:
> > >
> > > Hi,
> > >
> > > BinaryData is the new ByteArray in royale right?
> > > I was searching for compress/uncompress methods but seems we don't have
> > yet
> > >
> > > I'm missing something here? maybe the compress/uncompress algorithms
> has
> > > some license issues and for that reason wasn't implemented?
> > >
> > > thanks
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

Ok right, for me is ok to use that class and inflate/deflate methods,
do you know if that methods use the zlib algorithm? if use that we are
done, since is the same algorithm used in ByteArray

2018-05-17 15:22 GMT+02:00 Harbs :

> Yes. The big issue with compression is that it adds a lot of code.
>
> The most commonly used JS library for compression is pako.[1] I’m using
> that personally.
>
> We don’t want to include something like this in BinaryData because it adds
> a lot of bulk.
>
> HTH,
> Harbs
>
> [1]http://nodeca.github.io/pako/ 
>
> > On May 17, 2018, at 4:17 PM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > BinaryData is the new ByteArray in royale right?
> > I was searching for compress/uncompress methods but seems we don't have
> yet
> >
> > I'm missing something here? maybe the compress/uncompress algorithms has
> > some license issues and for that reason wasn't implemented?
> >
> > thanks
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

I see we already has Compressionutils that uses pako, this uses zlib?

thanks

2018-05-17 15:17 GMT+02:00 Carlos Rovira :

> Hi,
>
> BinaryData is the new ByteArray in royale right?
> I was searching for compress/uncompress methods but seems we don't have yet
>
> I'm missing something here? maybe the compress/uncompress algorithms has
> some license issues and for that reason wasn't implemented?
>
> thanks
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


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

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Harbs]

Yes. The big issue with compression is that it adds a lot of code.

The most commonly used JS library for compression is pako.[1] I’m using that 
personally.

We don’t want to include something like this in BinaryData because it adds a 
lot of bulk.

HTH,
Harbs

[1]http://nodeca.github.io/pako/ 

> On May 17, 2018, at 4:17 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> BinaryData is the new ByteArray in royale right?
> I was searching for compress/uncompress methods but seems we don't have yet
> 
> I'm missing something here? maybe the compress/uncompress algorithms has
> some license issues and for that reason wasn't implemented?
> 
> thanks
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Piotr Zarzycki]

Hi Carlos,

Yes and it is in progress. Serkan is working on that [1]. I made several
comments and waiting for his update.

[1] https://github.com/apache/royale-asjs/pull/227

Thanks,
Piotr

2018-05-17 15:17 GMT+02:00 Carlos Rovira :

> Hi,
>
> BinaryData is the new ByteArray in royale right?
> I was searching for compress/uncompress methods but seems we don't have yet
>
> I'm missing something here? maybe the compress/uncompress algorithms has
> some license issues and for that reason wasn't implemented?
>
> thanks
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

Hi,

BinaryData is the new ByteArray in royale right?
I was searching for compress/uncompress methods but seems we don't have yet

I'm missing something here? maybe the compress/uncompress algorithms has
some license issues and for that reason wasn't implemented?

thanks


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

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

Look foro "Inject a Font"

2018-05-17 15:12 GMT+02:00 Harbs :

> What was the subject?
>
> > On May 17, 2018, at 4:08 PM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > I think seems something valid, maybe we should think more about possible
> > colateral issue of that method. You should look as well at a thread where
> > Alex proposed as well some valid options
> >
> > 2018-05-17 15:04 GMT+02:00 Harbs :
> >
> >> I just had another thought which might be even more flexible:
> >>
> >> Maybe the compile could parse @includes from CSS and insert them as
> links
> >> in the header HTML automatically.
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On May 17, 2018, at 3:52 PM, Carlos Rovira 
> >> wrote:
> >>>
> 
>  Another angle on this problem might be to allow adding links via the
>  compiler automatically. Not sure exactly what form that might take
> >> though.
> 
> 
> >>> This was something Alex propose, something in the line of @media
> >>> -royale-swf, but with fonts, I think that is the right way.
> >>> For now we can stick with the html template but that should be
> temporal.
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Harbs]

What was the subject?

> On May 17, 2018, at 4:08 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> I think seems something valid, maybe we should think more about possible
> colateral issue of that method. You should look as well at a thread where
> Alex proposed as well some valid options
> 
> 2018-05-17 15:04 GMT+02:00 Harbs :
> 
>> I just had another thought which might be even more flexible:
>> 
>> Maybe the compile could parse @includes from CSS and insert them as links
>> in the header HTML automatically.
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 17, 2018, at 3:52 PM, Carlos Rovira 
>> wrote:
>>> 
 
 Another angle on this problem might be to allow adding links via the
 compiler automatically. Not sure exactly what form that might take
>> though.
 
 
>>> This was something Alex propose, something in the line of @media
>>> -royale-swf, but with fonts, I think that is the right way.
>>> For now we can stick with the html template but that should be temporal.
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

Hi,

I think seems something valid, maybe we should think more about possible
colateral issue of that method. You should look as well at a thread where
Alex proposed as well some valid options

2018-05-17 15:04 GMT+02:00 Harbs :

> I just had another thought which might be even more flexible:
>
> Maybe the compile could parse @includes from CSS and insert them as links
> in the header HTML automatically.
>
> Thanks,
> Harbs
>
> > On May 17, 2018, at 3:52 PM, Carlos Rovira 
> wrote:
> >
> >>
> >> Another angle on this problem might be to allow adding links via the
> >> compiler automatically. Not sure exactly what form that might take
> though.
> >>
> >>
> > This was something Alex propose, something in the line of @media
> > -royale-swf, but with fonts, I think that is the right way.
> > For now we can stick with the html template but that should be temporal.
>
>


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

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Harbs]

I just had another thought which might be even more flexible:

Maybe the compile could parse @includes from CSS and insert them as links in 
the header HTML automatically.

Thanks,
Harbs

> On May 17, 2018, at 3:52 PM, Carlos Rovira  wrote:
> 
>> 
>> Another angle on this problem might be to allow adding links via the
>> compiler automatically. Not sure exactly what form that might take though.
>> 
>> 
> This was something Alex propose, something in the line of @media
> -royale-swf, but with fonts, I think that is the right way.
> For now we can stick with the html template but that should be temporal.

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

Hi Harbs

2018-05-17 14:40 GMT+02:00 Harbs :

> Interesting.
>
> Why is deferred loading a problem? Adding the font to the header should
> have the same effect. Shouldn’t it?
>

No, this way seems to end with the browser capability to load resources in
parallel.


>
> I don’t think we want font flicker anyway.
>
> FWIW, the @import can be added to the theme files by a script too.
>
> I’d be interested in knowing what kind of performance hit @import has
> relative to a standard link. I think avoiding html template is a good thing.
>
> Another angle on this problem might be to allow adding links via the
> compiler automatically. Not sure exactly what form that might take though.
>
>
This was something Alex propose, something in the line of @media
-royale-swf, but with fonts, I think that is the right way.
For now we can stick with the html template but that should be temporal.



> My $0.02,
> Harbs
>
> > On May 17, 2018, at 3:16 PM, Carlos Rovira 
> wrote:
> >
> > we have a bug:
> >
> > https://github.com/apache/royale-compiler/issues/28
> >
> > but as well @import is something we should run away from [1]
> >
> > "You shoud avoid the use of @import because it will defer the loading of
> > the included resource until the file is fetched."
> >
> > [1]
> > https://stackoverflow.com/questions/14676613/how-to-
> import-google-web-font-in-css-file
> >
> >
> > 2018-05-17 14:11 GMT+02:00 Harbs :
> >
> >> More specifically, I believe including this in the css would negate the
> >> need for an HTML template:
> >>
> >> @import url('https://fonts.googleapis.com/css?family=Lato:400,700’);
> >>
> >>> On May 17, 2018, at 3:04 PM, Harbs  wrote:
> >>>
> >>> Why not just include the font in the CSS file?[1]
> >>>
> >>> [1]https://css-tricks.com/snippets/css/using-font-face/ <
> >> https://css-tricks.com/snippets/css/using-font-face/>
>  On May 17, 2018, at 2:57 PM, Carlos Rovira  >> > wrote:
> 
>  One more thing, we have as in MDL the use of an html template:
> 
>  
>  ${basedir}/target/javascript/bin/js-debug/jewel-example-
> >> index-template.html
>  
> 
>  but only to get the FONT:
> 
>  https://fonts.googleapis.com/css?family=Lato:400,700 <
> >> https://fonts.googleapis.com/css?family=Lato:400,700>" rel=
>  "stylesheet">
> >>>
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Harbs]

Interesting. 

Why is deferred loading a problem? Adding the font to the header should have 
the same effect. Shouldn’t it?

I don’t think we want font flicker anyway.

FWIW, the @import can be added to the theme files by a script too.

I’d be interested in knowing what kind of performance hit @import has relative 
to a standard link. I think avoiding html template is a good thing.

Another angle on this problem might be to allow adding links via the compiler 
automatically. Not sure exactly what form that might take though.

My $0.02,
Harbs

> On May 17, 2018, at 3:16 PM, Carlos Rovira  wrote:
> 
> we have a bug:
> 
> https://github.com/apache/royale-compiler/issues/28
> 
> but as well @import is something we should run away from [1]
> 
> "You shoud avoid the use of @import because it will defer the loading of
> the included resource until the file is fetched."
> 
> [1]
> https://stackoverflow.com/questions/14676613/how-to-import-google-web-font-in-css-file
> 
> 
> 2018-05-17 14:11 GMT+02:00 Harbs :
> 
>> More specifically, I believe including this in the css would negate the
>> need for an HTML template:
>> 
>> @import url('https://fonts.googleapis.com/css?family=Lato:400,700’);
>> 
>>> On May 17, 2018, at 3:04 PM, Harbs  wrote:
>>> 
>>> Why not just include the font in the CSS file?[1]
>>> 
>>> [1]https://css-tricks.com/snippets/css/using-font-face/ <
>> https://css-tricks.com/snippets/css/using-font-face/>
 On May 17, 2018, at 2:57 PM, Carlos Rovira > > wrote:
 
 One more thing, we have as in MDL the use of an html template:
 
 
 ${basedir}/target/javascript/bin/js-debug/jewel-example-
>> index-template.html
 
 
 but only to get the FONT:
 
 https://fonts.googleapis.com/css?family=Lato:400,700 <
>> https://fonts.googleapis.com/css?family=Lato:400,700>" rel=
 "stylesheet">
>>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

we have a bug:

https://github.com/apache/royale-compiler/issues/28

but as well @import is something we should run away from [1]

"You shoud avoid the use of @import because it will defer the loading of
the included resource until the file is fetched."

[1]
https://stackoverflow.com/questions/14676613/how-to-import-google-web-font-in-css-file


2018-05-17 14:11 GMT+02:00 Harbs :

> More specifically, I believe including this in the css would negate the
> need for an HTML template:
>
> @import url('https://fonts.googleapis.com/css?family=Lato:400,700’);
>
> > On May 17, 2018, at 3:04 PM, Harbs  wrote:
> >
> > Why not just include the font in the CSS file?[1]
> >
> > [1]https://css-tricks.com/snippets/css/using-font-face/ <
> https://css-tricks.com/snippets/css/using-font-face/>
> >> On May 17, 2018, at 2:57 PM, Carlos Rovira  > wrote:
> >>
> >> One more thing, we have as in MDL the use of an html template:
> >>
> >> 
> >> ${basedir}/target/javascript/bin/js-debug/jewel-example-
> index-template.html
> >> 
> >>
> >> but only to get the FONT:
> >>
> >> https://fonts.googleapis.com/css?family=Lato:400,700 <
> https://fonts.googleapis.com/css?family=Lato:400,700>" rel=
> >> "stylesheet">
> >
>
>


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

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Harbs]

Thanks. FWIW, the compiler option seems to be “theme”.

If the full path needs to be specified, this is a problem. Is there any way to 
specify a theme by just the theme name? (Question for however might know the 
answer.)

Harbs

> On May 17, 2018, at 3:11 PM, Carlos Rovira  wrote:
> 
> I think it should be
> 
> theme_arg=-theme=
> 
> (not tested by be)
> 
> 2018-05-17 14:02 GMT+02:00 Harbs :
> 
>> What compiler option is used to specify a theme? (Assuming the command
>> line is being used — not Maven, ant or what-have-you.)
>> 
>>> On May 17, 2018, at 2:57 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> (renaming to this thread since is not related directly to the old one and
>>> is more a "doc" email)
>>> 
>>> To setup a theme in jewel, the best is look at JewelExample's pom.xml. I
>>> think Alex already make the ANT's files needed to this.
>>> IDE should have some way to achieve this like in Flex. I think this was
>>> made using -theme like in flex. Please look in the list for "-theme"
>> since
>>> I can recall this is how the compiler consume the styles.
>>> 
>>> About how I set up in MAVEN:
>>> 
>>> We have a "master" Theme:
>>> 
>>> 
>>> org.apache.royale.framework
>>> JewelTheme
>>> 0.9.4-SNAPSHOT
>>> swc
>>> theme
>>> js
>>> 
>>> 
>>> This theme is the one that can create all the combinations of other
>> themes,
>>> changing variables in *_themes.sass*
>>> 
>>> //Theme variables (Flat/No Flat - Dark/Light -
>> Primary/Secondary/Emphasized
>>> Color
>>> $flat: false
>>> $dark: false
>>> $primary-color: $blue
>>> $secondary-color: $topaz
>>> $emphasized-color: $emerald
>>> 
>>> So if you set flat to "true", you'll get the generated css flat, and if
>> you
>>> change $blue to $amethyst, should get sass calculate the right colors to
>>> get the final CSS, finaly $dark will make theme dark or light.
>>> 
>>> To avoid people need to use SASS, I decided to create all possible
>> compiled
>>> versions. Right now I just committed the half. I still have to create the
>>> other half themes.
>>> 
>>> So instead of use the above and generate the final css with SASS, people
>>> not using SASS, can change for :
>>> 
>>> 
>>> org.apache.royale.framework
>>> Jewel-Light-NoFlat-Primary-Blue-Theme
>>> 0.9.4-SNAPSHOT
>>> swc
>>> theme
>>> js
>>> 
>>> 
>>> org.apache.royale.framework
>>> Jewel-Light-NoFlat-Secondary-Topaz-Theme
>>> 0.9.4-SNAPSHOT
>>> swc
>>> theme
>>> js
>>> 
>>> 
>>> org.apache.royale.framework
>>> Jewel-Light-NoFlat-Emphasized-Emerald-Theme
>>> 0.9.4-SNAPSHOT
>>> swc
>>> theme
>>> 
>>> 
>>> and that will make you use the three pieces needed. Normaly people will
>> use
>>> in this three ones the same configuration of dark-flat, and you can then
>>> use the color combination you want between primary, secondary and
>>> emphasized.
>>> 
>>> Note that all this themes use JewelTheme code as a master theme to
>> generate
>>> the corresponding CSS
>>> 
>>> in the final app all this style rules will be merged into one thanks to
>> the
>>> royale compiler processing.
>>> 
>>> One more thing, we have as in MDL the use of an html template:
>>> 
>>> 
>>> ${basedir}/target/javascript/bin/js-debug/jewel-example-
>> index-template.html
>>> 
>>> 
>>> but only to get the FONT:
>>> 
>>> https://fonts.googleapis.com/css?family=Lato:400,700; rel=
>>> "stylesheet">
>>> 
>>> I expect at some time we can remove that need since we implement one of
>> the
>>> options Alex expose for the incorporation of different fonts, hopefully
>>> soon.
>>> 
>>> There's no more needs, hope this clear better how to use Jewel.
>>> 
>>> Thanks
>>> 
>>> Carlos
>>> 
>>> 
>>> 2018-05-17 13:33 GMT+02:00 Harbs :
>>> 
 I see the following in the pom:
   
 org.apache.royale.framework
 Jewel-Light-NoFlat-Primary-Blue-Theme
 0.9.4-SNAPSHOT
 swc
 theme
 js
   
 
 It looks like there’s no default theme for Jewel. Should that be fixed?
 
 How are themes specified to the compiler?
 
> On May 17, 2018, at 2:26 PM, Harbs  wrote:
> 
> Oh. I guess that’s why the styling did not work.
> 
> Carlos, what compiler options are needed for Jewel?
> 
> Harbs
> 
>> On May 17, 2018, at 2:23 PM, Piotr Zarzycki <
>> piotrzarzyck...@gmail.com>
 wrote:
>> 
>> This is another issue. You cannot build those examples using IDE. I
 think
>> we should raise on GitHub. I also cannot build those examples in
 Moonshine.
>> Something needs to be configured. Probably some additional args for
>> compiler related to theme etc.
>> 
>> 2018-05-17 13:18 GMT+02:00 Harbs :
>> 
>>> VSCode using asconfigc
>>> 
 On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
 piotrzarzyck...@gmail.com>
>>> wrote:
 
 Harbs,
 
 How did you build the 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

Font should be easily configurable by the user and I think we have a
problem in the compiler to use that kind of css in that article, (I'm
recheck this)


2018-05-17 14:04 GMT+02:00 Harbs :

> Why not just include the font in the CSS file?[1]
>
> [1]https://css-tricks.com/snippets/css/using-font-face/ <
> https://css-tricks.com/snippets/css/using-font-face/>
> > On May 17, 2018, at 2:57 PM, Carlos Rovira 
> wrote:
> >
> > One more thing, we have as in MDL the use of an html template:
> >
> > 
> > ${basedir}/target/javascript/bin/js-debug/jewel-example-
> index-template.html
> > 
> >
> > but only to get the FONT:
> >
> > https://fonts.googleapis.com/css?family=Lato:400,700 <
> https://fonts.googleapis.com/css?family=Lato:400,700>" rel=
> > "stylesheet">
>
>


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

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Harbs]

More specifically, I believe including this in the css would negate the need 
for an HTML template:

@import url('https://fonts.googleapis.com/css?family=Lato:400,700’);

> On May 17, 2018, at 3:04 PM, Harbs  wrote:
> 
> Why not just include the font in the CSS file?[1]
> 
> [1]https://css-tricks.com/snippets/css/using-font-face/ 
> 
>> On May 17, 2018, at 2:57 PM, Carlos Rovira > > wrote:
>> 
>> One more thing, we have as in MDL the use of an html template:
>> 
>> 
>> ${basedir}/target/javascript/bin/js-debug/jewel-example-index-template.html
>> 
>> 
>> but only to get the FONT:
>> 
>> https://fonts.googleapis.com/css?family=Lato:400,700 
>> " rel=
>> "stylesheet">
> 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

I think it should be

theme_arg=-theme=

(not tested by be)

2018-05-17 14:02 GMT+02:00 Harbs :

> What compiler option is used to specify a theme? (Assuming the command
> line is being used — not Maven, ant or what-have-you.)
>
> > On May 17, 2018, at 2:57 PM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > (renaming to this thread since is not related directly to the old one and
> > is more a "doc" email)
> >
> > To setup a theme in jewel, the best is look at JewelExample's pom.xml. I
> > think Alex already make the ANT's files needed to this.
> > IDE should have some way to achieve this like in Flex. I think this was
> > made using -theme like in flex. Please look in the list for "-theme"
> since
> > I can recall this is how the compiler consume the styles.
> >
> > About how I set up in MAVEN:
> >
> > We have a "master" Theme:
> >
> > 
> > org.apache.royale.framework
> > JewelTheme
> > 0.9.4-SNAPSHOT
> > swc
> > theme
> > js
> > 
> >
> > This theme is the one that can create all the combinations of other
> themes,
> > changing variables in *_themes.sass*
> >
> > //Theme variables (Flat/No Flat - Dark/Light -
> Primary/Secondary/Emphasized
> > Color
> > $flat: false
> > $dark: false
> > $primary-color: $blue
> > $secondary-color: $topaz
> > $emphasized-color: $emerald
> >
> > So if you set flat to "true", you'll get the generated css flat, and if
> you
> > change $blue to $amethyst, should get sass calculate the right colors to
> > get the final CSS, finaly $dark will make theme dark or light.
> >
> > To avoid people need to use SASS, I decided to create all possible
> compiled
> > versions. Right now I just committed the half. I still have to create the
> > other half themes.
> >
> > So instead of use the above and generate the final css with SASS, people
> > not using SASS, can change for :
> >
> > 
> > org.apache.royale.framework
> > Jewel-Light-NoFlat-Primary-Blue-Theme
> > 0.9.4-SNAPSHOT
> > swc
> > theme
> > js
> > 
> > 
> > org.apache.royale.framework
> > Jewel-Light-NoFlat-Secondary-Topaz-Theme
> > 0.9.4-SNAPSHOT
> > swc
> > theme
> > js
> > 
> > 
> > org.apache.royale.framework
> > Jewel-Light-NoFlat-Emphasized-Emerald-Theme
> > 0.9.4-SNAPSHOT
> > swc
> > theme
> > 
> >
> > and that will make you use the three pieces needed. Normaly people will
> use
> > in this three ones the same configuration of dark-flat, and you can then
> > use the color combination you want between primary, secondary and
> > emphasized.
> >
> > Note that all this themes use JewelTheme code as a master theme to
> generate
> > the corresponding CSS
> >
> > in the final app all this style rules will be merged into one thanks to
> the
> > royale compiler processing.
> >
> > One more thing, we have as in MDL the use of an html template:
> >
> > 
> > ${basedir}/target/javascript/bin/js-debug/jewel-example-
> index-template.html
> > 
> >
> > but only to get the FONT:
> >
> > https://fonts.googleapis.com/css?family=Lato:400,700; rel=
> > "stylesheet">
> >
> > I expect at some time we can remove that need since we implement one of
> the
> > options Alex expose for the incorporation of different fonts, hopefully
> > soon.
> >
> > There's no more needs, hope this clear better how to use Jewel.
> >
> > Thanks
> >
> > Carlos
> >
> >
> > 2018-05-17 13:33 GMT+02:00 Harbs :
> >
> >> I see the following in the pom:
> >>
> >>  org.apache.royale.framework
> >>  Jewel-Light-NoFlat-Primary-Blue-Theme
> >>  0.9.4-SNAPSHOT
> >>  swc
> >>  theme
> >>  js
> >>
> >>
> >> It looks like there’s no default theme for Jewel. Should that be fixed?
> >>
> >> How are themes specified to the compiler?
> >>
> >>> On May 17, 2018, at 2:26 PM, Harbs  wrote:
> >>>
> >>> Oh. I guess that’s why the styling did not work.
> >>>
> >>> Carlos, what compiler options are needed for Jewel?
> >>>
> >>> Harbs
> >>>
>  On May 17, 2018, at 2:23 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> >> wrote:
> 
>  This is another issue. You cannot build those examples using IDE. I
> >> think
>  we should raise on GitHub. I also cannot build those examples in
> >> Moonshine.
>  Something needs to be configured. Probably some additional args for
>  compiler related to theme etc.
> 
>  2018-05-17 13:18 GMT+02:00 Harbs :
> 
> > VSCode using asconfigc
> >
> >> On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
> >> piotrzarzyck...@gmail.com>
> > wrote:
> >>
> >> Harbs,
> >>
> >> How did you build the examples? Using VSCode or script ant/maven ?
> >>
> >> Thanks,
> >> Piotr
> >>
> >> 2018-05-17 11:55 GMT+02:00 Harbs  harbs.li...@gmail.com>>:
> >>
> >>> FWIW, it looks to me like the only thing that will not work in the
> >> blog
> >>> post is  needs to be  and  needs to
> be
> >>> 
> >>>
> >>> Although 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Harbs]

Why not just include the font in the CSS file?[1]

[1]https://css-tricks.com/snippets/css/using-font-face/ 

> On May 17, 2018, at 2:57 PM, Carlos Rovira  wrote:
> 
> One more thing, we have as in MDL the use of an html template:
> 
> 
> ${basedir}/target/javascript/bin/js-debug/jewel-example-index-template.html
> 
> 
> but only to get the FONT:
> 
> https://fonts.googleapis.com/css?family=Lato:400,700 
> " rel=
> "stylesheet">

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Harbs]

What compiler option is used to specify a theme? (Assuming the command line is 
being used — not Maven, ant or what-have-you.)

> On May 17, 2018, at 2:57 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> (renaming to this thread since is not related directly to the old one and
> is more a "doc" email)
> 
> To setup a theme in jewel, the best is look at JewelExample's pom.xml. I
> think Alex already make the ANT's files needed to this.
> IDE should have some way to achieve this like in Flex. I think this was
> made using -theme like in flex. Please look in the list for "-theme" since
> I can recall this is how the compiler consume the styles.
> 
> About how I set up in MAVEN:
> 
> We have a "master" Theme:
> 
> 
> org.apache.royale.framework
> JewelTheme
> 0.9.4-SNAPSHOT
> swc
> theme
> js
> 
> 
> This theme is the one that can create all the combinations of other themes,
> changing variables in *_themes.sass*
> 
> //Theme variables (Flat/No Flat - Dark/Light - Primary/Secondary/Emphasized
> Color
> $flat: false
> $dark: false
> $primary-color: $blue
> $secondary-color: $topaz
> $emphasized-color: $emerald
> 
> So if you set flat to "true", you'll get the generated css flat, and if you
> change $blue to $amethyst, should get sass calculate the right colors to
> get the final CSS, finaly $dark will make theme dark or light.
> 
> To avoid people need to use SASS, I decided to create all possible compiled
> versions. Right now I just committed the half. I still have to create the
> other half themes.
> 
> So instead of use the above and generate the final css with SASS, people
> not using SASS, can change for :
> 
> 
> org.apache.royale.framework
> Jewel-Light-NoFlat-Primary-Blue-Theme
> 0.9.4-SNAPSHOT
> swc
> theme
> js
> 
> 
> org.apache.royale.framework
> Jewel-Light-NoFlat-Secondary-Topaz-Theme
> 0.9.4-SNAPSHOT
> swc
> theme
> js
> 
> 
> org.apache.royale.framework
> Jewel-Light-NoFlat-Emphasized-Emerald-Theme
> 0.9.4-SNAPSHOT
> swc
> theme
> 
> 
> and that will make you use the three pieces needed. Normaly people will use
> in this three ones the same configuration of dark-flat, and you can then
> use the color combination you want between primary, secondary and
> emphasized.
> 
> Note that all this themes use JewelTheme code as a master theme to generate
> the corresponding CSS
> 
> in the final app all this style rules will be merged into one thanks to the
> royale compiler processing.
> 
> One more thing, we have as in MDL the use of an html template:
> 
> 
> ${basedir}/target/javascript/bin/js-debug/jewel-example-index-template.html
> 
> 
> but only to get the FONT:
> 
> https://fonts.googleapis.com/css?family=Lato:400,700; rel=
> "stylesheet">
> 
> I expect at some time we can remove that need since we implement one of the
> options Alex expose for the incorporation of different fonts, hopefully
> soon.
> 
> There's no more needs, hope this clear better how to use Jewel.
> 
> Thanks
> 
> Carlos
> 
> 
> 2018-05-17 13:33 GMT+02:00 Harbs :
> 
>> I see the following in the pom:
>>
>>  org.apache.royale.framework
>>  Jewel-Light-NoFlat-Primary-Blue-Theme
>>  0.9.4-SNAPSHOT
>>  swc
>>  theme
>>  js
>>
>> 
>> It looks like there’s no default theme for Jewel. Should that be fixed?
>> 
>> How are themes specified to the compiler?
>> 
>>> On May 17, 2018, at 2:26 PM, Harbs  wrote:
>>> 
>>> Oh. I guess that’s why the styling did not work.
>>> 
>>> Carlos, what compiler options are needed for Jewel?
>>> 
>>> Harbs
>>> 
 On May 17, 2018, at 2:23 PM, Piotr Zarzycki 
>> wrote:
 
 This is another issue. You cannot build those examples using IDE. I
>> think
 we should raise on GitHub. I also cannot build those examples in
>> Moonshine.
 Something needs to be configured. Probably some additional args for
 compiler related to theme etc.
 
 2018-05-17 13:18 GMT+02:00 Harbs :
 
> VSCode using asconfigc
> 
>> On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
>> piotrzarzyck...@gmail.com>
> wrote:
>> 
>> Harbs,
>> 
>> How did you build the examples? Using VSCode or script ant/maven ?
>> 
>> Thanks,
>> Piotr
>> 
>> 2018-05-17 11:55 GMT+02:00 Harbs >:
>> 
>>> FWIW, it looks to me like the only thing that will not work in the
>> blog
>>> post is  needs to be  and  needs to be
>>> 
>>> 
>>> Although when I compile styles are definitely missing.
>>> 
>>> Yeah. Jewel is definitely missing important pieces… :-(
>>> 
>>> Harbs
>>> 
 On May 17, 2018, at 12:40 PM, Harbs  wrote:
 
 You are right. I missed this.
 
 What is the minimum change necessary to get this to work?
 
> On May 17, 2018, at 12:24 PM, Carlos Rovira <
>> 

Re: 0.9.3 Release

[Carlos Rovira]

Hi Harbs, just create a new thread from this. check it out! :)

2018-05-17 13:33 GMT+02:00 Harbs :

> I see the following in the pom:
> 
>   org.apache.royale.framework
>   Jewel-Light-NoFlat-Primary-Blue-Theme
>   0.9.4-SNAPSHOT
>   swc
>   theme
>   js
> 
>
> It looks like there’s no default theme for Jewel. Should that be fixed?
>
> How are themes specified to the compiler?
>
> > On May 17, 2018, at 2:26 PM, Harbs  wrote:
> >
> > Oh. I guess that’s why the styling did not work.
> >
> > Carlos, what compiler options are needed for Jewel?
> >
> > Harbs
> >
> >> On May 17, 2018, at 2:23 PM, Piotr Zarzycki 
> wrote:
> >>
> >> This is another issue. You cannot build those examples using IDE. I
> think
> >> we should raise on GitHub. I also cannot build those examples in
> Moonshine.
> >> Something needs to be configured. Probably some additional args for
> >> compiler related to theme etc.
> >>
> >> 2018-05-17 13:18 GMT+02:00 Harbs :
> >>
> >>> VSCode using asconfigc
> >>>
>  On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> >>> wrote:
> 
>  Harbs,
> 
>  How did you build the examples? Using VSCode or script ant/maven ?
> 
>  Thanks,
>  Piotr
> 
>  2018-05-17 11:55 GMT+02:00 Harbs >> harbs.li...@gmail.com>>:
> 
> > FWIW, it looks to me like the only thing that will not work in the
> blog
> > post is  needs to be  and  needs to be
> > 
> >
> > Although when I compile styles are definitely missing.
> >
> > Yeah. Jewel is definitely missing important pieces… :-(
> >
> > Harbs
> >
> >> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >>
> >> You are right. I missed this.
> >>
> >> What is the minimum change necessary to get this to work?
> >>
> >>> On May 17, 2018, at 12:24 PM, Carlos Rovira <
> carlosrov...@apache.org
> > >>
> >>> wrote:
> >>>
> >>> I think you missed one important point I
> >>> posted in other email: All blog post samples posted that are using
> the
> >>> actual names, packages and namespaces. If you release 0.9.3 without
> >>> all
> >>> that, we can destroy out credibility since in all posts we have:
> >>>
> >>> "The example uses the new Jewel UI set that supports themes. Jewel
> >>> will
> > be
> >>> available in the forthcoming 0.9.3 release of Royale. In the
> meanwhile
> > you
> >>> can find it in the develop branch."
> >>>
> >>> and the code is tailored with the actual api.
> >>>
> >>> For that reason, I think is important to hold 0.9.3 until it can
> ship
> > with
> >>> all that we are promising in website and social networks for the
> >>> latest
> > 2
> >>> months. I think this is crucial.
> >>
> >
> >
> 
> 
>  --
> 
>  Piotr Zarzycki
> 
>  Patreon: *https://www.patreon.com/piotrzarzycki <
> >>> https://www.patreon.com/piotrzarzycki>
>   >>> piotrzarzycki>>*
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: *https://www.patreon.com/piotrzarzycki
> >> *
> >
>
>


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

How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

Hi,

(renaming to this thread since is not related directly to the old one and
is more a "doc" email)

To setup a theme in jewel, the best is look at JewelExample's pom.xml. I
think Alex already make the ANT's files needed to this.
IDE should have some way to achieve this like in Flex. I think this was
made using -theme like in flex. Please look in the list for "-theme" since
I can recall this is how the compiler consume the styles.

About how I set up in MAVEN:

We have a "master" Theme:


org.apache.royale.framework
JewelTheme
0.9.4-SNAPSHOT
swc
theme
js


This theme is the one that can create all the combinations of other themes,
changing variables in *_themes.sass*

//Theme variables (Flat/No Flat - Dark/Light - Primary/Secondary/Emphasized
Color
$flat: false
$dark: false
$primary-color: $blue
$secondary-color: $topaz
$emphasized-color: $emerald

So if you set flat to "true", you'll get the generated css flat, and if you
change $blue to $amethyst, should get sass calculate the right colors to
get the final CSS, finaly $dark will make theme dark or light.

To avoid people need to use SASS, I decided to create all possible compiled
versions. Right now I just committed the half. I still have to create the
other half themes.

So instead of use the above and generate the final css with SASS, people
not using SASS, can change for :


org.apache.royale.framework
Jewel-Light-NoFlat-Primary-Blue-Theme
0.9.4-SNAPSHOT
swc
theme
js


org.apache.royale.framework
Jewel-Light-NoFlat-Secondary-Topaz-Theme
0.9.4-SNAPSHOT
swc
theme
js


org.apache.royale.framework
Jewel-Light-NoFlat-Emphasized-Emerald-Theme
0.9.4-SNAPSHOT
swc
theme


and that will make you use the three pieces needed. Normaly people will use
in this three ones the same configuration of dark-flat, and you can then
use the color combination you want between primary, secondary and
emphasized.

Note that all this themes use JewelTheme code as a master theme to generate
the corresponding CSS

in the final app all this style rules will be merged into one thanks to the
royale compiler processing.

One more thing, we have as in MDL the use of an html template:


${basedir}/target/javascript/bin/js-debug/jewel-example-index-template.html


but only to get the FONT:

https://fonts.googleapis.com/css?family=Lato:400,700; rel=
"stylesheet">

I expect at some time we can remove that need since we implement one of the
options Alex expose for the incorporation of different fonts, hopefully
soon.

There's no more needs, hope this clear better how to use Jewel.

Thanks

Carlos


2018-05-17 13:33 GMT+02:00 Harbs :

> I see the following in the pom:
> 
>   org.apache.royale.framework
>   Jewel-Light-NoFlat-Primary-Blue-Theme
>   0.9.4-SNAPSHOT
>   swc
>   theme
>   js
> 
>
> It looks like there’s no default theme for Jewel. Should that be fixed?
>
> How are themes specified to the compiler?
>
> > On May 17, 2018, at 2:26 PM, Harbs  wrote:
> >
> > Oh. I guess that’s why the styling did not work.
> >
> > Carlos, what compiler options are needed for Jewel?
> >
> > Harbs
> >
> >> On May 17, 2018, at 2:23 PM, Piotr Zarzycki 
> wrote:
> >>
> >> This is another issue. You cannot build those examples using IDE. I
> think
> >> we should raise on GitHub. I also cannot build those examples in
> Moonshine.
> >> Something needs to be configured. Probably some additional args for
> >> compiler related to theme etc.
> >>
> >> 2018-05-17 13:18 GMT+02:00 Harbs :
> >>
> >>> VSCode using asconfigc
> >>>
>  On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> >>> wrote:
> 
>  Harbs,
> 
>  How did you build the examples? Using VSCode or script ant/maven ?
> 
>  Thanks,
>  Piotr
> 
>  2018-05-17 11:55 GMT+02:00 Harbs >> harbs.li...@gmail.com>>:
> 
> > FWIW, it looks to me like the only thing that will not work in the
> blog
> > post is  needs to be  and  needs to be
> > 
> >
> > Although when I compile styles are definitely missing.
> >
> > Yeah. Jewel is definitely missing important pieces… :-(
> >
> > Harbs
> >
> >> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >>
> >> You are right. I missed this.
> >>
> >> What is the minimum change necessary to get this to work?
> >>
> >>> On May 17, 2018, at 12:24 PM, Carlos Rovira <
> carlosrov...@apache.org
> > >>
> >>> wrote:
> >>>
> >>> I think you missed one important point I
> >>> posted in other email: All blog post samples posted that are using
> the
> >>> actual names, packages and namespaces. If you release 0.9.3 without
> >>> all
> >>> that, we can destroy out credibility since in all posts we have:
> >>>
> >>> "The example uses the new 

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

OK. Let’s take a step back.

Here’s what I think is the takeaway of the first part of the “refactor” 
discussion. It seems like there are real issues — some of which have been 
partially resolved by Carlos, and none really have to do specifically with a 
project refactor.

There are multiple issues with CSS and component sets:
1. As it stands all CSS for all used component sets are imported into the final 
compiled CSS.
2. all classes mentioned in said CSS are imported as well.
3. The typenames of different component sets collide because they are not 
qualified.
4. typenames which match HTML element names are compiled as element selectors 
instead of class selectors.

I think we all agree that #1 and #2 are bugs which need to be fixed in the 
compiler. The exact changes that are needed should be ironed out.

#3 has a few different ways it can be resolved. The way that Carlos and I both 
like is by using composite class names such as “basic Button” and using a 
selector .basic.Button{} which requires the element to have *both* class names 
applied.

The solution above requires that class selectors are used and not type 
selectors. (The same for other solutions which use fully qualified names).

On the other hand, I do agree that folks should have a way of declaring styling 
for HTML element types as in normal css. This takes two forms.

The first is css with a namespace of "http://www.w3.org/1999/xhtml 
”. This is treated like normal css as I think it 
should. This allows folks to copy csss into their Royale apps and just have it 
“work”.
The second is the components in the HTML package. All these elements have types 
(i.e. button, input, h1, etc.) but not typenames. As it stands, they will be 
styled correctly using type selectors as they have no default class names.

So, type selectors should work for HTML components as well as an “dynamic” HTML 
created by “whatever”. The type selectors will probably usually be overridden 
by “regular” Royale components because these will usually have styling applied 
by either class names or inline css.

Some additional points:
* Unless we can figure out a way for the compiler to know which typenames are 
*actually* used, to prevent css of superclasses from being imported (i.e. basic 
Button), other components cannot subclass it. (i.e. Jewel should not subclass 
basic Button to prevent basic Button CSS from being unnecessarily included.0
* We will need a lookup of “standard” prefixes for the compiler to use so it 
knows what typenames to use for different packages.

Harbs

> On May 17, 2018, at 12:26 AM, Alex Harui  wrote:
> 
> Changing the subject line...
> 
> What is the failure case?  I think I've gotten lost somewhere.
> 
> IMO, the goal is to approximate Type Selectors (effectively extend Type 
> Selectors to other types not specified by W3C), and AIUI, order of class 
> selectors is about specificity and order of appearance in the CSS file.  So 
> one possible improvement to the current situation is to make the compiler 
> output the class selectors that are supposed to approximate class selectors 
> first in the final css file so all later class selectors override it.  IOW, 
> do a better job at making our class selectors that are supposed to act like 
> type selectors be overridden just like a type selector would.
> 
> Thoughts?
> -Alex
> 
> On 5/16/18, 12:52 PM, "Harbs"  wrote:
> 
>I guess it depends.
> 
>As long as the styling is set by class selectors, it will work because 
> class selectors trump type selectors.
> 
>I think it would at least be better than what we have now.
> 
>> On May 16, 2018, at 10:42 PM, Alex Harui  wrote:
>> 
>> Would that work?  I think any TLC with an HTMLButtonElement as its element 
>> (or sub-element) will still be affected by any Button type selector in some 
>> CSS file.  Or maybe I don't fully understand what you are proposing.
>> 
>> -Alex
>> 
>> On 5/16/18, 9:41 AM, "Harbs"  wrote:
>> 
>>   Sure. I wonder if we should handle different namespaces differently.
>> 
>>   Maybe the following two namespaces should get proper type selectors, while 
>> any others would get class selectors?
>> 
>>   
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%7C9b1582ba79124743cf6f08d5bb4be38b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636620856972038920=l94LsFAHe4i1NHoCalhlCKlF5L8yvpbrlh5qgmVhyGE%3D=0
>>   library://ns.apache.org/royale/html 
>> 
>>   Harbs
>> 
>>> On May 15, 2018, at 6:52 PM, Alex Harui  wrote:
>>> 
>>> The goal of typenames is to do the best job we can of emulating Type 
>>> Selectors.  I understand it isn't perfect, but the browser does have Type 
>>> Selectors and we can't really stop people from expecting Type Selectors to 
>>> work, and wishing it would work on the rest of Royale.

Re: 0.9.3 Release

[Harbs]

I see the following in the pom:

  org.apache.royale.framework
  Jewel-Light-NoFlat-Primary-Blue-Theme
  0.9.4-SNAPSHOT
  swc
  theme
  js


It looks like there’s no default theme for Jewel. Should that be fixed?

How are themes specified to the compiler?

> On May 17, 2018, at 2:26 PM, Harbs  wrote:
> 
> Oh. I guess that’s why the styling did not work.
> 
> Carlos, what compiler options are needed for Jewel?
> 
> Harbs
> 
>> On May 17, 2018, at 2:23 PM, Piotr Zarzycki  
>> wrote:
>> 
>> This is another issue. You cannot build those examples using IDE. I think
>> we should raise on GitHub. I also cannot build those examples in Moonshine.
>> Something needs to be configured. Probably some additional args for
>> compiler related to theme etc.
>> 
>> 2018-05-17 13:18 GMT+02:00 Harbs :
>> 
>>> VSCode using asconfigc
>>> 
 On May 17, 2018, at 12:57 PM, Piotr Zarzycki 
>>> wrote:
 
 Harbs,
 
 How did you build the examples? Using VSCode or script ant/maven ?
 
 Thanks,
 Piotr
 
 2018-05-17 11:55 GMT+02:00 Harbs > harbs.li...@gmail.com>>:
 
> FWIW, it looks to me like the only thing that will not work in the blog
> post is  needs to be  and  needs to be
> 
> 
> Although when I compile styles are definitely missing.
> 
> Yeah. Jewel is definitely missing important pieces… :-(
> 
> Harbs
> 
>> On May 17, 2018, at 12:40 PM, Harbs  wrote:
>> 
>> You are right. I missed this.
>> 
>> What is the minimum change necessary to get this to work?
>> 
>>> On May 17, 2018, at 12:24 PM, Carlos Rovira  >>
>>> wrote:
>>> 
>>> I think you missed one important point I
>>> posted in other email: All blog post samples posted that are using the
>>> actual names, packages and namespaces. If you release 0.9.3 without
>>> all
>>> that, we can destroy out credibility since in all posts we have:
>>> 
>>> "The example uses the new Jewel UI set that supports themes. Jewel
>>> will
> be
>>> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
> you
>>> can find it in the develop branch."
>>> 
>>> and the code is tailored with the actual api.
>>> 
>>> For that reason, I think is important to hold 0.9.3 until it can ship
> with
>>> all that we are promising in website and social networks for the
>>> latest
> 2
>>> months. I think this is crucial.
>> 
> 
> 
 
 
 --
 
 Piotr Zarzycki
 
 Patreon: *https://www.patreon.com/piotrzarzycki <
>>> https://www.patreon.com/piotrzarzycki>
 >> piotrzarzycki>>*
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>> Piotr Zarzycki
>> 
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> *
> 

Re: 0.9.3 Release

[Harbs]

Oh. I guess that’s why the styling did not work.

Carlos, what compiler options are needed for Jewel?

Harbs

> On May 17, 2018, at 2:23 PM, Piotr Zarzycki  wrote:
> 
> This is another issue. You cannot build those examples using IDE. I think
> we should raise on GitHub. I also cannot build those examples in Moonshine.
> Something needs to be configured. Probably some additional args for
> compiler related to theme etc.
> 
> 2018-05-17 13:18 GMT+02:00 Harbs :
> 
>> VSCode using asconfigc
>> 
>>> On May 17, 2018, at 12:57 PM, Piotr Zarzycki 
>> wrote:
>>> 
>>> Harbs,
>>> 
>>> How did you build the examples? Using VSCode or script ant/maven ?
>>> 
>>> Thanks,
>>> Piotr
>>> 
>>> 2018-05-17 11:55 GMT+02:00 Harbs  harbs.li...@gmail.com>>:
>>> 
 FWIW, it looks to me like the only thing that will not work in the blog
 post is  needs to be  and  needs to be
 
 
 Although when I compile styles are definitely missing.
 
 Yeah. Jewel is definitely missing important pieces… :-(
 
 Harbs
 
> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> 
> You are right. I missed this.
> 
> What is the minimum change necessary to get this to work?
> 
>> On May 17, 2018, at 12:24 PM, Carlos Rovira >>
>> wrote:
>> 
>> I think you missed one important point I
>> posted in other email: All blog post samples posted that are using the
>> actual names, packages and namespaces. If you release 0.9.3 without
>> all
>> that, we can destroy out credibility since in all posts we have:
>> 
>> "The example uses the new Jewel UI set that supports themes. Jewel
>> will
 be
>> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
 you
>> can find it in the develop branch."
>> 
>> and the code is tailored with the actual api.
>> 
>> For that reason, I think is important to hold 0.9.3 until it can ship
 with
>> all that we are promising in website and social networks for the
>> latest
 2
>> months. I think this is crucial.
> 
 
 
>>> 
>>> 
>>> --
>>> 
>>> Piotr Zarzycki
>>> 
>>> Patreon: *https://www.patreon.com/piotrzarzycki <
>> https://www.patreon.com/piotrzarzycki>
>>> > piotrzarzycki>>*
>> 
>> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

Re: 0.9.3 Release

[Piotr Zarzycki]

This is another issue. You cannot build those examples using IDE. I think
we should raise on GitHub. I also cannot build those examples in Moonshine.
Something needs to be configured. Probably some additional args for
compiler related to theme etc.

2018-05-17 13:18 GMT+02:00 Harbs :

> VSCode using asconfigc
>
> > On May 17, 2018, at 12:57 PM, Piotr Zarzycki 
> wrote:
> >
> > Harbs,
> >
> > How did you build the examples? Using VSCode or script ant/maven ?
> >
> > Thanks,
> > Piotr
> >
> > 2018-05-17 11:55 GMT+02:00 Harbs >:
> >
> >> FWIW, it looks to me like the only thing that will not work in the blog
> >> post is  needs to be  and  needs to be
> >> 
> >>
> >> Although when I compile styles are definitely missing.
> >>
> >> Yeah. Jewel is definitely missing important pieces… :-(
> >>
> >> Harbs
> >>
> >>> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >>>
> >>> You are right. I missed this.
> >>>
> >>> What is the minimum change necessary to get this to work?
> >>>
>  On May 17, 2018, at 12:24 PM, Carlos Rovira  >> >>
> wrote:
> 
>  I think you missed one important point I
>  posted in other email: All blog post samples posted that are using the
>  actual names, packages and namespaces. If you release 0.9.3 without
> all
>  that, we can destroy out credibility since in all posts we have:
> 
>  "The example uses the new Jewel UI set that supports themes. Jewel
> will
> >> be
>  available in the forthcoming 0.9.3 release of Royale. In the meanwhile
> >> you
>  can find it in the develop branch."
> 
>  and the code is tailored with the actual api.
> 
>  For that reason, I think is important to hold 0.9.3 until it can ship
> >> with
>  all that we are promising in website and social networks for the
> latest
> >> 2
>  months. I think this is crucial.
> >>>
> >>
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki <
> https://www.patreon.com/piotrzarzycki>
> >  piotrzarzycki>>*
>
>


-- 

Piotr Zarzycki

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

Re: 0.9.3 Release

[Harbs]

Please make the list and we’ll take the discussion from there.

> On May 17, 2018, at 2:01 PM, Carlos Rovira  wrote:
> 
> anyway, now that build is working for me is a matter of making the list of
> package name changes if you like

Re: 0.9.3 Release

[Harbs]

VSCode using asconfigc

> On May 17, 2018, at 12:57 PM, Piotr Zarzycki  
> wrote:
> 
> Harbs,
> 
> How did you build the examples? Using VSCode or script ant/maven ?
> 
> Thanks,
> Piotr
> 
> 2018-05-17 11:55 GMT+02:00 Harbs  >:
> 
>> FWIW, it looks to me like the only thing that will not work in the blog
>> post is  needs to be  and  needs to be
>> 
>> 
>> Although when I compile styles are definitely missing.
>> 
>> Yeah. Jewel is definitely missing important pieces… :-(
>> 
>> Harbs
>> 
>>> On May 17, 2018, at 12:40 PM, Harbs  wrote:
>>> 
>>> You are right. I missed this.
>>> 
>>> What is the minimum change necessary to get this to work?
>>> 
 On May 17, 2018, at 12:24 PM, Carlos Rovira > >> wrote:
 
 I think you missed one important point I
 posted in other email: All blog post samples posted that are using the
 actual names, packages and namespaces. If you release 0.9.3 without all
 that, we can destroy out credibility since in all posts we have:
 
 "The example uses the new Jewel UI set that supports themes. Jewel will
>> be
 available in the forthcoming 0.9.3 release of Royale. In the meanwhile
>> you
 can find it in the develop branch."
 
 and the code is tailored with the actual api.
 
 For that reason, I think is important to hold 0.9.3 until it can ship
>> with
 all that we are promising in website and social networks for the latest
>> 2
 months. I think this is crucial.
>>> 
>> 
>> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki 
> 
>  >*

Jenkins build is back to normal : royale-asjs #742

[apacheroyaleci]

See 

Re: 0.9.3 Release

[Carlos Rovira]

Hi,

jsonly build is finaly fixed.
Looking at the code fixed seems to me almost dead code and things very old
unused now.
as well I was not aware since is based on ANT and not maven, that I thought
all build process in Royale was based on Maven.

anyway, now that build is working for me is a matter of making the list of
package name changes if you like

thanks


2018-05-17 12:03 GMT+02:00 Carlos Rovira :

> Harbs,
> take into account that I don't use to setup ANT files, only Maven.
> ANT files needs to be done, I hope others can contribute that work.
>
> 2018-05-17 11:55 GMT+02:00 Harbs :
>
>> FWIW, it looks to me like the only thing that will not work in the blog
>> post is  needs to be  and  needs to be
>> 
>>
>> Although when I compile styles are definitely missing.
>>
>> Yeah. Jewel is definitely missing important pieces… :-(
>>
>> Harbs
>>
>> > On May 17, 2018, at 12:40 PM, Harbs  wrote:
>> >
>> > You are right. I missed this.
>> >
>> > What is the minimum change necessary to get this to work?
>> >
>> >> On May 17, 2018, at 12:24 PM, Carlos Rovira > > wrote:
>> >>
>> >>  I think you missed one important point I
>> >> posted in other email: All blog post samples posted that are using the
>> >> actual names, packages and namespaces. If you release 0.9.3 without all
>> >> that, we can destroy out credibility since in all posts we have:
>> >>
>> >> "The example uses the new Jewel UI set that supports themes. Jewel
>> will be
>> >> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
>> you
>> >> can find it in the develop branch."
>> >>
>> >> and the code is tailored with the actual api.
>> >>
>> >> For that reason, I think is important to hold 0.9.3 until it can ship
>> with
>> >> all that we are promising in website and social networks for the
>> latest 2
>> >> months. I think this is crucial.
>> >
>>
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


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

Jenkins build is back to normal : royale-asjs_jsonly #811

[apacheroyaleci]

See 

Re: 0.9.3 Release

[Carlos Rovira]

Harbs,
take into account that I don't use to setup ANT files, only Maven.
ANT files needs to be done, I hope others can contribute that work.

2018-05-17 11:55 GMT+02:00 Harbs :

> FWIW, it looks to me like the only thing that will not work in the blog
> post is  needs to be  and  needs to be
> 
>
> Although when I compile styles are definitely missing.
>
> Yeah. Jewel is definitely missing important pieces… :-(
>
> Harbs
>
> > On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >
> > You are right. I missed this.
> >
> > What is the minimum change necessary to get this to work?
> >
> >> On May 17, 2018, at 12:24 PM, Carlos Rovira  > wrote:
> >>
> >>  I think you missed one important point I
> >> posted in other email: All blog post samples posted that are using the
> >> actual names, packages and namespaces. If you release 0.9.3 without all
> >> that, we can destroy out credibility since in all posts we have:
> >>
> >> "The example uses the new Jewel UI set that supports themes. Jewel will
> be
> >> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
> you
> >> can find it in the develop branch."
> >>
> >> and the code is tailored with the actual api.
> >>
> >> For that reason, I think is important to hold 0.9.3 until it can ship
> with
> >> all that we are promising in website and social networks for the latest
> 2
> >> months. I think this is crucial.
> >
>
>


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

Re: 0.9.3 Release

[Piotr Zarzycki]

Harbs,

How did you build the examples? Using VSCode or script ant/maven ?

Thanks,
Piotr

2018-05-17 11:55 GMT+02:00 Harbs :

> FWIW, it looks to me like the only thing that will not work in the blog
> post is  needs to be  and  needs to be
> 
>
> Although when I compile styles are definitely missing.
>
> Yeah. Jewel is definitely missing important pieces… :-(
>
> Harbs
>
> > On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >
> > You are right. I missed this.
> >
> > What is the minimum change necessary to get this to work?
> >
> >> On May 17, 2018, at 12:24 PM, Carlos Rovira  > wrote:
> >>
> >>  I think you missed one important point I
> >> posted in other email: All blog post samples posted that are using the
> >> actual names, packages and namespaces. If you release 0.9.3 without all
> >> that, we can destroy out credibility since in all posts we have:
> >>
> >> "The example uses the new Jewel UI set that supports themes. Jewel will
> be
> >> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
> you
> >> can find it in the develop branch."
> >>
> >> and the code is tailored with the actual api.
> >>
> >> For that reason, I think is important to hold 0.9.3 until it can ship
> with
> >> all that we are promising in website and social networks for the latest
> 2
> >> months. I think this is crucial.
> >
>
>


-- 

Piotr Zarzycki

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

Re: 0.9.3 Release

[Harbs]

FWIW, it looks to me like the only thing that will not work in the blog post is 
 needs to be  and  needs to be 


Although when I compile styles are definitely missing.

Yeah. Jewel is definitely missing important pieces… :-(

Harbs

> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> 
> You are right. I missed this.
> 
> What is the minimum change necessary to get this to work?
> 
>> On May 17, 2018, at 12:24 PM, Carlos Rovira > > wrote:
>> 
>>  I think you missed one important point I
>> posted in other email: All blog post samples posted that are using the
>> actual names, packages and namespaces. If you release 0.9.3 without all
>> that, we can destroy out credibility since in all posts we have:
>> 
>> "The example uses the new Jewel UI set that supports themes. Jewel will be
>> available in the forthcoming 0.9.3 release of Royale. In the meanwhile you
>> can find it in the develop branch."
>> 
>> and the code is tailored with the actual api.
>> 
>> For that reason, I think is important to hold 0.9.3 until it can ship with
>> all that we are promising in website and social networks for the latest 2
>> months. I think this is crucial.
> 

Re: 0.9.3 Release

[Harbs]

You are right. I missed this.

What is the minimum change necessary to get this to work?

> On May 17, 2018, at 12:24 PM, Carlos Rovira  wrote:
> 
>  I think you missed one important point I
> posted in other email: All blog post samples posted that are using the
> actual names, packages and namespaces. If you release 0.9.3 without all
> that, we can destroy out credibility since in all posts we have:
> 
> "The example uses the new Jewel UI set that supports themes. Jewel will be
> available in the forthcoming 0.9.3 release of Royale. In the meanwhile you
> can find it in the develop branch."
> 
> and the code is tailored with the actual api.
> 
> For that reason, I think is important to hold 0.9.3 until it can ship with
> all that we are promising in website and social networks for the latest 2
> months. I think this is crucial.

Re: 0.9.3 Release

[Carlos Rovira]

2018-05-17 11:16 GMT+02:00 Harbs :

> Definitely a plan.
>

Good! :)


>
> My guess is that if we agree on changing package paths, there will likely
> be other classes that should be considered.
>

For sure I think a 1.0 version should not have "core" packages in "Basic"
SWC nor "html" packages in "Core" SWC. I'm pretty sure there's more other
cases that we need to structure, reorganize and clean.


> My preference would be to have this discussion after we finish the project
> refactor discussion because I think it’s going to be related to the outcome
> of that.
>

For me we can do that in parallel but if the rest think the same for me is
ok.


>
> Either way, I don’t think discussion should hold up the 0.9.3 release.
> We’re already past due for a release. We want to “release early and release
> often”… ;-)
>
>
As Piotr, I don't agree with this. I think you missed one important point I
posted in other email: All blog post samples posted that are using the
actual names, packages and namespaces. If you release 0.9.3 without all
that, we can destroy out credibility since in all posts we have:

"The example uses the new Jewel UI set that supports themes. Jewel will be
available in the forthcoming 0.9.3 release of Royale. In the meanwhile you
can find it in the develop branch."

and the code is tailored with the actual api.

For that reason, I think is important to hold 0.9.3 until it can ship with
all that we are promising in website and social networks for the latest 2
months. I think this is crucial.



> Thanks,
> Harbs
>
> > On May 17, 2018, at 12:07 PM, Carlos Rovira 
> wrote:
> >
> > Ok,
> >
> > what if:
> >
> > * I take the time to generate a list of classes with package name changes
> > * Make a thread with the list to expose it
> > * Let's see from there if people can live with it (We'll call people to
> > express about this changes and could see if are or not dramatic to them)
> >
> > Sounds this like a plan?
> >
> > Thanks
> >
> >
> >
> > 2018-05-17 10:58 GMT+02:00 Harbs :
> >
> >> Sure. Same here.
> >>
> >> But things are much more stable now. As we move closer to “1.0”, I think
> >> we should be more careful about breaking changes and documenting them
> when
> >> we decide they are necessary.
> >>
> >> As far as these specific changes go: We haven’t even come to a
> conclusion
> >> on what (if any) package names should change yet, and including those
> >> changes in a release is premature. If we do change package names, I’m of
> >> the opinion that they should be decided on and all happen at once to
> >> minimize impact on end-users.
> >>
> >> Does that help clarify things?
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On May 17, 2018, at 11:49 AM, Justin Mclean 
> >> wrote:
> >>>
> >>> Hi,
> >>>
>  We are at the point where people are using Royale in production. While
> >> we can make breaking changes if they are warranted, they should be kept
> to
> >> an absolute minimum and be carefully considered and well documented if
> we
> >> do.
> >>>
> >>> There has been many previous breaking changes that broke the
> application
> >> I was working on and some more major than this and cost me a lot of
> time to
> >> fix. Until you make it version 1.0 I think people will expect that some
> >> things may break with a new version. So why should this be an exception
> to
> >> what has happened before? Saying that however, what would be good to
> see is
> >> to provide guidance to what users need to change so their app works with
> >> any changes / backward compatibility issues.
> >>>
> >>> Thanks,
> >>> Justin
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Carlos Rovira]

Hi Alex,

I think I need some example code to understand what you try to explain
here. I don't get to follow your explanation. Can you post some sample code
to explain it better?
thanks!

2018-05-16 23:43 GMT+02:00 Alex Harui :

> Typo in there:
>
> "...make the compiler output the class selectors that are supposed to
> approximate type selectors..."
>
> Sorry,
> -Alex
>
> On 5/16/18, 2:26 PM, "Alex Harui"  wrote:
>
> Changing the subject line...
>
> What is the failure case?  I think I've gotten lost somewhere.
>
> IMO, the goal is to approximate Type Selectors (effectively extend
> Type Selectors to other types not specified by W3C), and AIUI, order of
> class selectors is about specificity and order of appearance in the CSS
> file.  So one possible improvement to the current situation is to make the
> compiler output the class selectors that are supposed to approximate class
> selectors first in the final css file so all later class selectors override
> it.  IOW, do a better job at making our class selectors that are supposed
> to act like type selectors be overridden just like a type selector would.
>
> Thoughts?
> -Alex
>
> On 5/16/18, 12:52 PM, "Harbs"  wrote:
>
> I guess it depends.
>
> As long as the styling is set by class selectors, it will work
> because class selectors trump type selectors.
>
> I think it would at least be better than what we have now.
>
> > On May 16, 2018, at 10:42 PM, Alex Harui
>  wrote:
> >
> > Would that work?  I think any TLC with an HTMLButtonElement as
> its element (or sub-element) will still be affected by any Button type
> selector in some CSS file.  Or maybe I don't fully understand what you are
> proposing.
> >
> > -Alex
> >
> > On 5/16/18, 9:41 AM, "Harbs"  wrote:
> >
> >Sure. I wonder if we should handle different namespaces
> differently.
> >
> >Maybe the following two namespaces should get proper type
> selectors, while any others would get class selectors?
> >
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%
> 7C9b1582ba79124743cf6f08d5bb4be38b%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636620856972038920=l94LsFAHe4i1NHoCalhlCKlF5L8yvp
> brlh5qgmVhyGE%3D=0
> >library://ns.apache.org/royale/html  royale/html>
> >
> >Harbs
> >
> >> On May 15, 2018, at 6:52 PM, Alex Harui
>  wrote:
> >>
> >> The goal of typenames is to do the best job we can of emulating
> Type Selectors.  I understand it isn't perfect, but the browser does have
> Type Selectors and we can't really stop people from expecting Type
> Selectors to work, and wishing it would work on the rest of Royale.
> >>
> >> On 5/15/18, 8:37 AM, "Harbs"  wrote:
> >>
> >>   Makes sense, but there’s two problems with that:
> >>
> >>   1. That makes the assumption that components of a specific
> name implement the HTML component of the same name.
> >>   2. Classes take precedence over element selectors, so that
> styling is too easily overridden.
> >>
> >>
> >>> On May 15, 2018, at 6:11 PM, Alex Harui
>  wrote:
> >>>
> >>> Certain typenames match up against HTMLElement names and are
> thus valid Type selectors so are not transformed into Class Selectors.
> >>>
> >>> -Alex
> >>>
> >>> On 5/15/18, 2:09 AM, "Harbs"  wrote:
> >>>
> >>>  Interesting. It looks to me like a bug.
> >>>
> >>>  The theme CSS compiles into this:
> >>>  Button {
> >>>  border: 1px solid #808080;
> >>>  padding: 4px;
> >>>  background-color: #f8f8f8;
> >>>  margin: 0px;
> >>>  border-radius: 2px;
> >>>  }
> >>>  Button:hover {
> >>>  border: 1px solid #808080;
> >>>  padding: 4px;
> >>>  background-color: #e8e8e8;
> >>>  }
> >>>  Button:active {
> >>>  border: 1px solid #808080;
> >>>  padding: 4px;
> >>>  background-color: #d8d8d8;
> >>>  }
> >>>
> >>>  Instead of this:
> >>>
> >>>  .Button {
> >>>  border: 1px solid #808080;
> >>>  padding: 4px;
> >>>  background-color: #f8f8f8;
> >>>  margin: 0px;
> >>>  border-radius: 2px;
> >>>  }
> >>>  .Button:hover {
> >>>  border: 1px solid #808080;
> 

Re: 0.9.3 Release

[Harbs]

Definitely a plan.

My guess is that if we agree on changing package paths, there will likely be 
other classes that should be considered.

My preference would be to have this discussion after we finish the project 
refactor discussion because I think it’s going to be related to the outcome of 
that.

Either way, I don’t think discussion should hold up the 0.9.3 release. We’re 
already past due for a release. We want to “release early and release often”… 
;-)

Thanks,
Harbs

> On May 17, 2018, at 12:07 PM, Carlos Rovira  wrote:
> 
> Ok,
> 
> what if:
> 
> * I take the time to generate a list of classes with package name changes
> * Make a thread with the list to expose it
> * Let's see from there if people can live with it (We'll call people to
> express about this changes and could see if are or not dramatic to them)
> 
> Sounds this like a plan?
> 
> Thanks
> 
> 
> 
> 2018-05-17 10:58 GMT+02:00 Harbs :
> 
>> Sure. Same here.
>> 
>> But things are much more stable now. As we move closer to “1.0”, I think
>> we should be more careful about breaking changes and documenting them when
>> we decide they are necessary.
>> 
>> As far as these specific changes go: We haven’t even come to a conclusion
>> on what (if any) package names should change yet, and including those
>> changes in a release is premature. If we do change package names, I’m of
>> the opinion that they should be decided on and all happen at once to
>> minimize impact on end-users.
>> 
>> Does that help clarify things?
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 17, 2018, at 11:49 AM, Justin Mclean 
>> wrote:
>>> 
>>> Hi,
>>> 
 We are at the point where people are using Royale in production. While
>> we can make breaking changes if they are warranted, they should be kept to
>> an absolute minimum and be carefully considered and well documented if we
>> do.
>>> 
>>> There has been many previous breaking changes that broke the application
>> I was working on and some more major than this and cost me a lot of time to
>> fix. Until you make it version 1.0 I think people will expect that some
>> things may break with a new version. So why should this be an exception to
>> what has happened before? Saying that however, what would be good to see is
>> to provide guidance to what users need to change so their app works with
>> any changes / backward compatibility issues.
>>> 
>>> Thanks,
>>> Justin
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: 0.9.3 Release

[Piotr Zarzycki]

I think better focus on discussion and have proper solution. Than make the
release.

2018-05-17 11:07 GMT+02:00 Carlos Rovira :

> Ok,
>
> what if:
>
> * I take the time to generate a list of classes with package name changes
> * Make a thread with the list to expose it
> * Let's see from there if people can live with it (We'll call people to
> express about this changes and could see if are or not dramatic to them)
>
> Sounds this like a plan?
>
> Thanks
>
>
>
> 2018-05-17 10:58 GMT+02:00 Harbs :
>
> > Sure. Same here.
> >
> > But things are much more stable now. As we move closer to “1.0”, I think
> > we should be more careful about breaking changes and documenting them
> when
> > we decide they are necessary.
> >
> > As far as these specific changes go: We haven’t even come to a conclusion
> > on what (if any) package names should change yet, and including those
> > changes in a release is premature. If we do change package names, I’m of
> > the opinion that they should be decided on and all happen at once to
> > minimize impact on end-users.
> >
> > Does that help clarify things?
> >
> > Thanks,
> > Harbs
> >
> > > On May 17, 2018, at 11:49 AM, Justin Mclean 
> > wrote:
> > >
> > > Hi,
> > >
> > >> We are at the point where people are using Royale in production. While
> > we can make breaking changes if they are warranted, they should be kept
> to
> > an absolute minimum and be carefully considered and well documented if we
> > do.
> > >
> > > There has been many previous breaking changes that broke the
> application
> > I was working on and some more major than this and cost me a lot of time
> to
> > fix. Until you make it version 1.0 I think people will expect that some
> > things may break with a new version. So why should this be an exception
> to
> > what has happened before? Saying that however, what would be good to see
> is
> > to provide guidance to what users need to change so their app works with
> > any changes / backward compatibility issues.
> > >
> > > Thanks,
> > > Justin
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: 0.9.3 Release

[Harbs]

Sure. Same here.

But things are much more stable now. As we move closer to “1.0”, I think we 
should be more careful about breaking changes and documenting them when we 
decide they are necessary.

As far as these specific changes go: We haven’t even come to a conclusion on 
what (if any) package names should change yet, and including those changes in a 
release is premature. If we do change package names, I’m of the opinion that 
they should be decided on and all happen at once to minimize impact on 
end-users.

Does that help clarify things?

Thanks,
Harbs

> On May 17, 2018, at 11:49 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> We are at the point where people are using Royale in production. While we 
>> can make breaking changes if they are warranted, they should be kept to an 
>> absolute minimum and be carefully considered and well documented if we do.
> 
> There has been many previous breaking changes that broke the application I 
> was working on and some more major than this and cost me a lot of time to 
> fix. Until you make it version 1.0 I think people will expect that some 
> things may break with a new version. So why should this be an exception to 
> what has happened before? Saying that however, what would be good to see is 
> to provide guidance to what users need to change so their app works with any 
> changes / backward compatibility issues.
> 
> Thanks,
> Justin

Build failed in Jenkins: royale-asjs_jsonly #810

[apacheroyaleci]

See 


Changes:

[yishayjobs] Adding HideComboPopupOnMouseDownBead

[yishayjobs] Get rid of redundant imports

[carlosrovira] fix some packages still with all names that was left since was 
not

--
[...truncated 1.76 MB...]
[mxmlc] org.apache.royale.html.ButtonBar depends on 
org.apache.royale.html.List
[mxmlc] 

 removing require: org.apache.royale.core.IRollOverModel
[mxmlc] 

 removing require: org.apache.royale.core.ISelectionModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.List'
[mxmlc] org.apache.royale.html.List depends on 
org.apache.royale.html.DataContainer
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderModel
[mxmlc] 

 removing require: org.apache.royale.core.IListPresentationModel
[mxmlc] 

 removing require: org.apache.royale.html.beads.models.ListPresentationModel
[mxmlc] Dependencies calculated for 'org.apache.royale.html.DataContainer'
[mxmlc] org.apache.royale.html.DataContainer depends on 
org.apache.royale.core.DataContainerBase
[mxmlc] 

 removing require: org.apache.royale.core.DataItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IChild
[mxmlc] 

 removing require: org.apache.royale.core.IDataProviderItemRendererMapper
[mxmlc] 

 removing require: org.apache.royale.core.IFactory
[mxmlc] 

 removing require: org.apache.royale.core.IItemRenderer
[mxmlc] 

 removing require: org.apache.royale.core.IItemRendererClassFactory
[mxmlc] 

 removing require: org.apache.royale.core.IListView
[mxmlc] 

 removing require: org.apache.royale.core.ValuesManager
[mxmlc] 

 removing require: org.apache.royale.events.Event
[mxmlc] 

 removing require: org.apache.royale.events.ItemAddedEvent
[mxmlc] 

 removing require: org.apache.royale.events.ItemRemovedEvent
[mxmlc] 

 removing require: org.apache.royale.utils.loadBeadFromValuesManager
[mxmlc] 

 removing 

Re: 0.9.3 Release

[Harbs]

Yes. It definitely makes sense to me.

Let’s get the 0.9.3 release out without breaking changes. If we decide to keep 
Carlos’ changes and/or modify them, there’s no reason it cannot go into 0.9.4.

Thanks,
Harbs

> On May 17, 2018, at 11:30 AM, Piotr Zarzycki  
> wrote:
> 
> Carlos,
> 
> Those changes were not properly discussed. Let's wait till the end of the
> discussion and proper fix. I personally prefer wait even another month than
> release something what can change significantly.
> 
> Is that make sense to others ?
> 
> Thanks, Piotr
> 
> 2018-05-17 10:26 GMT+02:00 Carlos Rovira :
> 
>> Hi,
>> 
>> just find the imports with problems, fix them and committed. If there's no
>> others this should fix the release.
>> 
>> If you see the commit, the changes are easy, and no more of some secs to do
>> for our users, in case they use this core classes.
>> 
>> Let's see what Jenkins reports in the following build
>> 
>> 
>> 2018-05-17 10:16 GMT+02:00 Carlos Rovira :
>> 
>>> Hi Piotr,
>>> 
>>> I think we are getting sufficient progress I the discussion thread to
>>> still think about a revert. I'm most for change things from this point,
>>> that should be the normal way from 0.9.2 to 1.0. We can as well hold a
>> bit
>>> the release until we have cleared all this. As I said, if we revert, and
>>> release 0.9.3 with old code, blog examples will not work at all, and that
>>> will suppose lots of people in the internet trying us and failing.
>>> 
>>> Think that:
>>> 
>>> 1) There's no breaking changes at all about functionality
>>> 2) The change was only:
>>> a) move things from Basic to Core
>>> b) rename packages on some of that 2.a) things
>>> 
>>> 
>>> So the real problem now for me is 2.b) and that's the reason why jsonly
>>> build is failing, since we have things in framework with not examples
>>> referencing it, and since SWCs does not validate CSS beads, when used
>> that
>>> CSS in final app that fails. I think that's for me a major problem, and
>>> will prefer to focus in find that code and fixing it.
>>> 
>>> I'm trying to focus this morning on doing this, and hope to fix on that
>>> way jsonly
>>> 
>>> 
>>> 2018-05-17 10:08 GMT+02:00 Piotr Zarzycki :
>>> 
 It's not about the minor changes in his app in my opinion. In the result
 of
 the discussion it may end up that you will revert everything and
>> solution
 will be completely different. What will be the experience of the created
 app on the user sight ?
 
 2018-05-17 10:05 GMT+02:00 Carlos Rovira :
 
> Hi Harbs,
> 
> that was returned to the old way, actually we have the same than
>> before
> refactor:
> 
> import org.apache.royale.html.Group;
> 
> public class NodeElementBase extends Group
> 
> Maybe the problem is that we don't have any example of ButtonBar in
> examples? and thus I was not aware of that concrete component?
> 
> I'll try to see that and if we need, I'll create and example now for
 that.
> 
> The change to solve this in your code base is really easy and direct:
> 
> search all "import org.apache.royale.html.supportClasses.DataGroup;"
 and
> replace with "import org.apache.royale.core.DataGroup;"
> 
> (for me is clear that DataGroup is a Core piece, that will be used not
 as
> Basic or Jewel implementation, but as a "core" piece used for the rest
 of
> UI sets)
> 
> I'll be looking at it right now
> 
> Thanks for exposing it! :)
> 
> Carlos
> 
> 
> 
> 2018-05-17 8:49 GMT+02:00 Harbs :
> 
>> Having trouble getting this email to “take”. Trying a paste link
> instead...
>> 
>> It looks like it does have issues.
>> 
>> I just pulled the 0.9.3 branch.
>> 
>> I get a lot of these warnings when I compile the framework:
>> https://paste.apache.org/Wy9t 
>> 
>> I used it to compile my app, and I get runtime errors due to missing
>> components. This seems to be due to HTML not subclassing Group.
>> 
>> Here’s an example of elements which go AWAL:
>> https://paste.apache.org/s9og 
>> 
>> Everything below “ul" is missing.
>> 
>> Harbs
>> 
>>> On May 16, 2018, at 10:45 PM, Alex Harui > > wrote:
>>> 
>>> I'm pretty sure the branches were cut before the changes in
 question.
>> You can pull down the branches and build them to verify.  Or look at
> their
>> history on GitHub.
>>> 
>>> Om, did you see a date for when Maven SCM would be released?  The
 only
>> response I got from the Maven folks was to build Maven SCM from
 sources.
>> If it is going to be more 

Re: 0.9.3 Release

[Harbs]

> I only what to said at this regard, that I expect, as we have alll things
> working and think about release 1.0, that before that release, is very
> normal to change packages and names right?

No. I disagree with this.

We are at the point where people are using Royale in production. While we can 
make breaking changes if they are warranted, they should be kept to an absolute 
minimum and be carefully considered and well documented if we do.

My $0.02,
Harbs

> On May 17, 2018, at 11:32 AM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> ok, as I said, package names are not something crucial. It's only something
> we can put back to their old names.
> I only what to said at this regard, that I expect, as we have alll things
> working and think about release 1.0, that before that release, is very
> normal to change packages and names right? (maybe our most near examples
> where Flex releases from beta codenames to final i.e: Jumbo to Flex 4.0,
> many changes where done by Adobe that broke existing applications, but that
> was nothing people will think was bad, since they prefer a better names and
> organization for the major release and to follow in the future)
> 
> If you finally, with all that said, want me to change packages to all way,
> I can do that. As I stated, this is not crucial, only library place is
> (Basic to Core).
> 
> thanks
> 
> 
> 
> 2018-05-17 10:10 GMT+02:00 Harbs :
> 
>> Hi Carlos,
>> 
>> The problem is that any existing applications which subclass or import
>> DataGroup (for example) will break by upgrading to 0.9.3. We don’t want
>> release breaking changes unless we decide that breaking changes are
>> necessary.
>> 
>> We are still discussing that whole topic and this release will likely
>> happen before that discussion is finished.
>> 
>> IMO, it’s better to release less features than release breaking changes
>> which might be reverted.
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 17, 2018, at 11:05 AM, Carlos Rovira 
>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> that was returned to the old way, actually we have the same than before
>>> refactor:
>>> 
>>> import org.apache.royale.html.Group;
>>> 
>>> public class NodeElementBase extends Group
>>> 
>>> Maybe the problem is that we don't have any example of ButtonBar in
>>> examples? and thus I was not aware of that concrete component?
>>> 
>>> I'll try to see that and if we need, I'll create and example now for
>> that.
>>> 
>>> The change to solve this in your code base is really easy and direct:
>>> 
>>> search all "import org.apache.royale.html.supportClasses.DataGroup;" and
>>> replace with "import org.apache.royale.core.DataGroup;"
>>> 
>>> (for me is clear that DataGroup is a Core piece, that will be used not as
>>> Basic or Jewel implementation, but as a "core" piece used for the rest of
>>> UI sets)
>>> 
>>> I'll be looking at it right now
>>> 
>>> Thanks for exposing it! :)
>>> 
>>> Carlos
>>> 
>>> 
>>> 
>>> 2018-05-17 8:49 GMT+02:00 Harbs :
>>> 
 Having trouble getting this email to “take”. Trying a paste link
>> instead...
 
 It looks like it does have issues.
 
 I just pulled the 0.9.3 branch.
 
 I get a lot of these warnings when I compile the framework:
 https://paste.apache.org/Wy9t 
 
 I used it to compile my app, and I get runtime errors due to missing
 components. This seems to be due to HTML not subclassing Group.
 
 Here’s an example of elements which go AWAL:
 https://paste.apache.org/s9og 
 
 Everything below “ul" is missing.
 
 Harbs
 
> On May 16, 2018, at 10:45 PM, Alex Harui > wrote:
> 
> I'm pretty sure the branches were cut before the changes in question.
 You can pull down the branches and build them to verify.  Or look at
>> their
 history on GitHub.
> 
> Om, did you see a date for when Maven SCM would be released?  The only
 response I got from the Maven folks was to build Maven SCM from sources.
 If it is going to be more than a week, I might actually try that.
> 
> -Alex
> 
 
 
>>> 
>>> 
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: 0.9.3 Release

[Carlos Rovira]

for me that's ok Piotr too

thanks

2018-05-17 10:30 GMT+02:00 Piotr Zarzycki :

> Carlos,
>
> Those changes were not properly discussed. Let's wait till the end of the
> discussion and proper fix. I personally prefer wait even another month than
> release something what can change significantly.
>
> Is that make sense to others ?
>
> Thanks, Piotr
>
> 2018-05-17 10:26 GMT+02:00 Carlos Rovira :
>
> > Hi,
> >
> > just find the imports with problems, fix them and committed. If there's
> no
> > others this should fix the release.
> >
> > If you see the commit, the changes are easy, and no more of some secs to
> do
> > for our users, in case they use this core classes.
> >
> > Let's see what Jenkins reports in the following build
> >
> >
> > 2018-05-17 10:16 GMT+02:00 Carlos Rovira :
> >
> > > Hi Piotr,
> > >
> > > I think we are getting sufficient progress I the discussion thread to
> > > still think about a revert. I'm most for change things from this point,
> > > that should be the normal way from 0.9.2 to 1.0. We can as well hold a
> > bit
> > > the release until we have cleared all this. As I said, if we revert,
> and
> > > release 0.9.3 with old code, blog examples will not work at all, and
> that
> > > will suppose lots of people in the internet trying us and failing.
> > >
> > > Think that:
> > >
> > > 1) There's no breaking changes at all about functionality
> > > 2) The change was only:
> > >  a) move things from Basic to Core
> > >  b) rename packages on some of that 2.a) things
> > >
> > >
> > > So the real problem now for me is 2.b) and that's the reason why jsonly
> > > build is failing, since we have things in framework with not examples
> > > referencing it, and since SWCs does not validate CSS beads, when used
> > that
> > > CSS in final app that fails. I think that's for me a major problem, and
> > > will prefer to focus in find that code and fixing it.
> > >
> > > I'm trying to focus this morning on doing this, and hope to fix on that
> > > way jsonly
> > >
> > >
> > > 2018-05-17 10:08 GMT+02:00 Piotr Zarzycki :
> > >
> > >> It's not about the minor changes in his app in my opinion. In the
> result
> > >> of
> > >> the discussion it may end up that you will revert everything and
> > solution
> > >> will be completely different. What will be the experience of the
> created
> > >> app on the user sight ?
> > >>
> > >> 2018-05-17 10:05 GMT+02:00 Carlos Rovira :
> > >>
> > >> > Hi Harbs,
> > >> >
> > >> > that was returned to the old way, actually we have the same than
> > before
> > >> > refactor:
> > >> >
> > >> > import org.apache.royale.html.Group;
> > >> >
> > >> > public class NodeElementBase extends Group
> > >> >
> > >> > Maybe the problem is that we don't have any example of ButtonBar in
> > >> > examples? and thus I was not aware of that concrete component?
> > >> >
> > >> > I'll try to see that and if we need, I'll create and example now for
> > >> that.
> > >> >
> > >> > The change to solve this in your code base is really easy and
> direct:
> > >> >
> > >> > search all "import org.apache.royale.html.
> supportClasses.DataGroup;"
> > >> and
> > >> > replace with "import org.apache.royale.core.DataGroup;"
> > >> >
> > >> > (for me is clear that DataGroup is a Core piece, that will be used
> not
> > >> as
> > >> > Basic or Jewel implementation, but as a "core" piece used for the
> rest
> > >> of
> > >> > UI sets)
> > >> >
> > >> > I'll be looking at it right now
> > >> >
> > >> > Thanks for exposing it! :)
> > >> >
> > >> > Carlos
> > >> >
> > >> >
> > >> >
> > >> > 2018-05-17 8:49 GMT+02:00 Harbs :
> > >> >
> > >> > > Having trouble getting this email to “take”. Trying a paste link
> > >> > instead...
> > >> > >
> > >> > > It looks like it does have issues.
> > >> > >
> > >> > > I just pulled the 0.9.3 branch.
> > >> > >
> > >> > > I get a lot of these warnings when I compile the framework:
> > >> > > https://paste.apache.org/Wy9t 
> > >> > >
> > >> > > I used it to compile my app, and I get runtime errors due to
> missing
> > >> > > components. This seems to be due to HTML not subclassing Group.
> > >> > >
> > >> > > Here’s an example of elements which go AWAL:
> > >> > > https://paste.apache.org/s9og 
> > >> > >
> > >> > > Everything below “ul" is missing.
> > >> > >
> > >> > > Harbs
> > >> > >
> > >> > > > On May 16, 2018, at 10:45 PM, Alex Harui
>  > >> > > > wrote:
> > >> > > >
> > >> > > > I'm pretty sure the branches were cut before the changes in
> > >> question.
> > >> > > You can pull down the branches and build them to verify.  Or look
> at
> > >> > their
> > >> > > history on GitHub.
> > >> > > >
> > >> > > > Om, did you see a date for when Maven SCM would be released?
> The
> > >> only
> > >> > 

Re: 0.9.3 Release

[Carlos Rovira]

Hi Harbs,

ok, as I said, package names are not something crucial. It's only something
we can put back to their old names.
I only what to said at this regard, that I expect, as we have alll things
working and think about release 1.0, that before that release, is very
normal to change packages and names right? (maybe our most near examples
where Flex releases from beta codenames to final i.e: Jumbo to Flex 4.0,
many changes where done by Adobe that broke existing applications, but that
was nothing people will think was bad, since they prefer a better names and
organization for the major release and to follow in the future)

If you finally, with all that said, want me to change packages to all way,
I can do that. As I stated, this is not crucial, only library place is
(Basic to Core).

thanks



2018-05-17 10:10 GMT+02:00 Harbs :

> Hi Carlos,
>
> The problem is that any existing applications which subclass or import
> DataGroup (for example) will break by upgrading to 0.9.3. We don’t want
> release breaking changes unless we decide that breaking changes are
> necessary.
>
> We are still discussing that whole topic and this release will likely
> happen before that discussion is finished.
>
> IMO, it’s better to release less features than release breaking changes
> which might be reverted.
>
> Thanks,
> Harbs
>
> > On May 17, 2018, at 11:05 AM, Carlos Rovira 
> wrote:
> >
> > Hi Harbs,
> >
> > that was returned to the old way, actually we have the same than before
> > refactor:
> >
> > import org.apache.royale.html.Group;
> >
> > public class NodeElementBase extends Group
> >
> > Maybe the problem is that we don't have any example of ButtonBar in
> > examples? and thus I was not aware of that concrete component?
> >
> > I'll try to see that and if we need, I'll create and example now for
> that.
> >
> > The change to solve this in your code base is really easy and direct:
> >
> > search all "import org.apache.royale.html.supportClasses.DataGroup;" and
> > replace with "import org.apache.royale.core.DataGroup;"
> >
> > (for me is clear that DataGroup is a Core piece, that will be used not as
> > Basic or Jewel implementation, but as a "core" piece used for the rest of
> > UI sets)
> >
> > I'll be looking at it right now
> >
> > Thanks for exposing it! :)
> >
> > Carlos
> >
> >
> >
> > 2018-05-17 8:49 GMT+02:00 Harbs :
> >
> >> Having trouble getting this email to “take”. Trying a paste link
> instead...
> >>
> >> It looks like it does have issues.
> >>
> >> I just pulled the 0.9.3 branch.
> >>
> >> I get a lot of these warnings when I compile the framework:
> >> https://paste.apache.org/Wy9t 
> >>
> >> I used it to compile my app, and I get runtime errors due to missing
> >> components. This seems to be due to HTML not subclassing Group.
> >>
> >> Here’s an example of elements which go AWAL:
> >> https://paste.apache.org/s9og 
> >>
> >> Everything below “ul" is missing.
> >>
> >> Harbs
> >>
> >>> On May 16, 2018, at 10:45 PM, Alex Harui  >> > wrote:
> >>>
> >>> I'm pretty sure the branches were cut before the changes in question.
> >> You can pull down the branches and build them to verify.  Or look at
> their
> >> history on GitHub.
> >>>
> >>> Om, did you see a date for when Maven SCM would be released?  The only
> >> response I got from the Maven folks was to build Maven SCM from sources.
> >> If it is going to be more than a week, I might actually try that.
> >>>
> >>> -Alex
> >>>
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: 0.9.3 Release

[Carlos Rovira]

Hi,

just find the imports with problems, fix them and committed. If there's no
others this should fix the release.

If you see the commit, the changes are easy, and no more of some secs to do
for our users, in case they use this core classes.

Let's see what Jenkins reports in the following build


2018-05-17 10:16 GMT+02:00 Carlos Rovira :

> Hi Piotr,
>
> I think we are getting sufficient progress I the discussion thread to
> still think about a revert. I'm most for change things from this point,
> that should be the normal way from 0.9.2 to 1.0. We can as well hold a bit
> the release until we have cleared all this. As I said, if we revert, and
> release 0.9.3 with old code, blog examples will not work at all, and that
> will suppose lots of people in the internet trying us and failing.
>
> Think that:
>
> 1) There's no breaking changes at all about functionality
> 2) The change was only:
>  a) move things from Basic to Core
>  b) rename packages on some of that 2.a) things
>
>
> So the real problem now for me is 2.b) and that's the reason why jsonly
> build is failing, since we have things in framework with not examples
> referencing it, and since SWCs does not validate CSS beads, when used that
> CSS in final app that fails. I think that's for me a major problem, and
> will prefer to focus in find that code and fixing it.
>
> I'm trying to focus this morning on doing this, and hope to fix on that
> way jsonly
>
>
> 2018-05-17 10:08 GMT+02:00 Piotr Zarzycki :
>
>> It's not about the minor changes in his app in my opinion. In the result
>> of
>> the discussion it may end up that you will revert everything and solution
>> will be completely different. What will be the experience of the created
>> app on the user sight ?
>>
>> 2018-05-17 10:05 GMT+02:00 Carlos Rovira :
>>
>> > Hi Harbs,
>> >
>> > that was returned to the old way, actually we have the same than before
>> > refactor:
>> >
>> > import org.apache.royale.html.Group;
>> >
>> > public class NodeElementBase extends Group
>> >
>> > Maybe the problem is that we don't have any example of ButtonBar in
>> > examples? and thus I was not aware of that concrete component?
>> >
>> > I'll try to see that and if we need, I'll create and example now for
>> that.
>> >
>> > The change to solve this in your code base is really easy and direct:
>> >
>> > search all "import org.apache.royale.html.supportClasses.DataGroup;"
>> and
>> > replace with "import org.apache.royale.core.DataGroup;"
>> >
>> > (for me is clear that DataGroup is a Core piece, that will be used not
>> as
>> > Basic or Jewel implementation, but as a "core" piece used for the rest
>> of
>> > UI sets)
>> >
>> > I'll be looking at it right now
>> >
>> > Thanks for exposing it! :)
>> >
>> > Carlos
>> >
>> >
>> >
>> > 2018-05-17 8:49 GMT+02:00 Harbs :
>> >
>> > > Having trouble getting this email to “take”. Trying a paste link
>> > instead...
>> > >
>> > > It looks like it does have issues.
>> > >
>> > > I just pulled the 0.9.3 branch.
>> > >
>> > > I get a lot of these warnings when I compile the framework:
>> > > https://paste.apache.org/Wy9t 
>> > >
>> > > I used it to compile my app, and I get runtime errors due to missing
>> > > components. This seems to be due to HTML not subclassing Group.
>> > >
>> > > Here’s an example of elements which go AWAL:
>> > > https://paste.apache.org/s9og 
>> > >
>> > > Everything below “ul" is missing.
>> > >
>> > > Harbs
>> > >
>> > > > On May 16, 2018, at 10:45 PM, Alex Harui > > > > wrote:
>> > > >
>> > > > I'm pretty sure the branches were cut before the changes in
>> question.
>> > > You can pull down the branches and build them to verify.  Or look at
>> > their
>> > > history on GitHub.
>> > > >
>> > > > Om, did you see a date for when Maven SCM would be released?  The
>> only
>> > > response I got from the Maven folks was to build Maven SCM from
>> sources.
>> > > If it is going to be more than a week, I might actually try that.
>> > > >
>> > > > -Alex
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Carlos Rovira
>> > http://about.me/carlosrovira
>> >
>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> *
>>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


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

Re: 0.9.3 Release

[Carlos Rovira]

Hi Piotr,

I think we are getting sufficient progress I the discussion thread to still
think about a revert. I'm most for change things from this point, that
should be the normal way from 0.9.2 to 1.0. We can as well hold a bit the
release until we have cleared all this. As I said, if we revert, and
release 0.9.3 with old code, blog examples will not work at all, and that
will suppose lots of people in the internet trying us and failing.

Think that:

1) There's no breaking changes at all about functionality
2) The change was only:
 a) move things from Basic to Core
 b) rename packages on some of that 2.a) things


So the real problem now for me is 2.b) and that's the reason why jsonly
build is failing, since we have things in framework with not examples
referencing it, and since SWCs does not validate CSS beads, when used that
CSS in final app that fails. I think that's for me a major problem, and
will prefer to focus in find that code and fixing it.

I'm trying to focus this morning on doing this, and hope to fix on that way
jsonly


2018-05-17 10:08 GMT+02:00 Piotr Zarzycki :

> It's not about the minor changes in his app in my opinion. In the result of
> the discussion it may end up that you will revert everything and solution
> will be completely different. What will be the experience of the created
> app on the user sight ?
>
> 2018-05-17 10:05 GMT+02:00 Carlos Rovira :
>
> > Hi Harbs,
> >
> > that was returned to the old way, actually we have the same than before
> > refactor:
> >
> > import org.apache.royale.html.Group;
> >
> > public class NodeElementBase extends Group
> >
> > Maybe the problem is that we don't have any example of ButtonBar in
> > examples? and thus I was not aware of that concrete component?
> >
> > I'll try to see that and if we need, I'll create and example now for
> that.
> >
> > The change to solve this in your code base is really easy and direct:
> >
> > search all "import org.apache.royale.html.supportClasses.DataGroup;" and
> > replace with "import org.apache.royale.core.DataGroup;"
> >
> > (for me is clear that DataGroup is a Core piece, that will be used not as
> > Basic or Jewel implementation, but as a "core" piece used for the rest of
> > UI sets)
> >
> > I'll be looking at it right now
> >
> > Thanks for exposing it! :)
> >
> > Carlos
> >
> >
> >
> > 2018-05-17 8:49 GMT+02:00 Harbs :
> >
> > > Having trouble getting this email to “take”. Trying a paste link
> > instead...
> > >
> > > It looks like it does have issues.
> > >
> > > I just pulled the 0.9.3 branch.
> > >
> > > I get a lot of these warnings when I compile the framework:
> > > https://paste.apache.org/Wy9t 
> > >
> > > I used it to compile my app, and I get runtime errors due to missing
> > > components. This seems to be due to HTML not subclassing Group.
> > >
> > > Here’s an example of elements which go AWAL:
> > > https://paste.apache.org/s9og 
> > >
> > > Everything below “ul" is missing.
> > >
> > > Harbs
> > >
> > > > On May 16, 2018, at 10:45 PM, Alex Harui  > > > wrote:
> > > >
> > > > I'm pretty sure the branches were cut before the changes in question.
> > > You can pull down the branches and build them to verify.  Or look at
> > their
> > > history on GitHub.
> > > >
> > > > Om, did you see a date for when Maven SCM would be released?  The
> only
> > > response I got from the Maven folks was to build Maven SCM from
> sources.
> > > If it is going to be more than a week, I might actually try that.
> > > >
> > > > -Alex
> > > >
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



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

Re: 0.9.3 Release

[Harbs]

It might be that we decide that DataGroup does belong in Core with a “core” 
package path, but I don’t even think there’s a list of classes which were 
changed. Maybe there are too many. Maybe there are others which should be 
changed. Maybe we’ll decide that it’s not worth it to change any. I don’t know.

Changing package paths is not something we should do lightly, and if we do make 
changes, it should only happen in a single release and all changes should be 
carefully considered. There has not been nearly enough discussion on that yet.

Thanks,
Harbs

> On May 17, 2018, at 11:10 AM, Harbs  wrote:
> 
> Hi Carlos,
> 
> The problem is that any existing applications which subclass or import 
> DataGroup (for example) will break by upgrading to 0.9.3. We don’t want 
> release breaking changes unless we decide that breaking changes are necessary.
> 
> We are still discussing that whole topic and this release will likely happen 
> before that discussion is finished.
> 
> IMO, it’s better to release less features than release breaking changes which 
> might be reverted.
> 
> Thanks,
> Harbs
> 
>> On May 17, 2018, at 11:05 AM, Carlos Rovira  wrote:
>> 
>> Hi Harbs,
>> 
>> that was returned to the old way, actually we have the same than before
>> refactor:
>> 
>> import org.apache.royale.html.Group;
>> 
>> public class NodeElementBase extends Group
>> 
>> Maybe the problem is that we don't have any example of ButtonBar in
>> examples? and thus I was not aware of that concrete component?
>> 
>> I'll try to see that and if we need, I'll create and example now for that.
>> 
>> The change to solve this in your code base is really easy and direct:
>> 
>> search all "import org.apache.royale.html.supportClasses.DataGroup;" and
>> replace with "import org.apache.royale.core.DataGroup;"
>> 
>> (for me is clear that DataGroup is a Core piece, that will be used not as
>> Basic or Jewel implementation, but as a "core" piece used for the rest of
>> UI sets)
>> 
>> I'll be looking at it right now
>> 
>> Thanks for exposing it! :)
>> 
>> Carlos
>> 
>> 
>> 
>> 2018-05-17 8:49 GMT+02:00 Harbs :
>> 
>>> Having trouble getting this email to “take”. Trying a paste link instead...
>>> 
>>> It looks like it does have issues.
>>> 
>>> I just pulled the 0.9.3 branch.
>>> 
>>> I get a lot of these warnings when I compile the framework:
>>> https://paste.apache.org/Wy9t 
>>> 
>>> I used it to compile my app, and I get runtime errors due to missing
>>> components. This seems to be due to HTML not subclassing Group.
>>> 
>>> Here’s an example of elements which go AWAL:
>>> https://paste.apache.org/s9og 
>>> 
>>> Everything below “ul" is missing.
>>> 
>>> Harbs
>>> 
 On May 16, 2018, at 10:45 PM, Alex Harui >> > wrote:
 
 I'm pretty sure the branches were cut before the changes in question.
>>> You can pull down the branches and build them to verify.  Or look at their
>>> history on GitHub.
 
 Om, did you see a date for when Maven SCM would be released?  The only
>>> response I got from the Maven folks was to build Maven SCM from sources.
>>> If it is going to be more than a week, I might actually try that.
 
 -Alex
 
>>> 
>>> 
>> 
>> 
>> -- 
>> Carlos Rovira
>> http://about.me/carlosrovira
> 

Re: 0.9.3 Release

[Piotr Zarzycki]

It's not about the minor changes in his app in my opinion. In the result of
the discussion it may end up that you will revert everything and solution
will be completely different. What will be the experience of the created
app on the user sight ?

2018-05-17 10:05 GMT+02:00 Carlos Rovira :

> Hi Harbs,
>
> that was returned to the old way, actually we have the same than before
> refactor:
>
> import org.apache.royale.html.Group;
>
> public class NodeElementBase extends Group
>
> Maybe the problem is that we don't have any example of ButtonBar in
> examples? and thus I was not aware of that concrete component?
>
> I'll try to see that and if we need, I'll create and example now for that.
>
> The change to solve this in your code base is really easy and direct:
>
> search all "import org.apache.royale.html.supportClasses.DataGroup;" and
> replace with "import org.apache.royale.core.DataGroup;"
>
> (for me is clear that DataGroup is a Core piece, that will be used not as
> Basic or Jewel implementation, but as a "core" piece used for the rest of
> UI sets)
>
> I'll be looking at it right now
>
> Thanks for exposing it! :)
>
> Carlos
>
>
>
> 2018-05-17 8:49 GMT+02:00 Harbs :
>
> > Having trouble getting this email to “take”. Trying a paste link
> instead...
> >
> > It looks like it does have issues.
> >
> > I just pulled the 0.9.3 branch.
> >
> > I get a lot of these warnings when I compile the framework:
> > https://paste.apache.org/Wy9t 
> >
> > I used it to compile my app, and I get runtime errors due to missing
> > components. This seems to be due to HTML not subclassing Group.
> >
> > Here’s an example of elements which go AWAL:
> > https://paste.apache.org/s9og 
> >
> > Everything below “ul" is missing.
> >
> > Harbs
> >
> > > On May 16, 2018, at 10:45 PM, Alex Harui  > > wrote:
> > >
> > > I'm pretty sure the branches were cut before the changes in question.
> > You can pull down the branches and build them to verify.  Or look at
> their
> > history on GitHub.
> > >
> > > Om, did you see a date for when Maven SCM would be released?  The only
> > response I got from the Maven folks was to build Maven SCM from sources.
> > If it is going to be more than a week, I might actually try that.
> > >
> > > -Alex
> > >
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: 0.9.3 Release

[Carlos Rovira]

Hi Harbs,

that was returned to the old way, actually we have the same than before
refactor:

import org.apache.royale.html.Group;

public class NodeElementBase extends Group

Maybe the problem is that we don't have any example of ButtonBar in
examples? and thus I was not aware of that concrete component?

I'll try to see that and if we need, I'll create and example now for that.

The change to solve this in your code base is really easy and direct:

search all "import org.apache.royale.html.supportClasses.DataGroup;" and
replace with "import org.apache.royale.core.DataGroup;"

(for me is clear that DataGroup is a Core piece, that will be used not as
Basic or Jewel implementation, but as a "core" piece used for the rest of
UI sets)

I'll be looking at it right now

Thanks for exposing it! :)

Carlos



2018-05-17 8:49 GMT+02:00 Harbs :

> Having trouble getting this email to “take”. Trying a paste link instead...
>
> It looks like it does have issues.
>
> I just pulled the 0.9.3 branch.
>
> I get a lot of these warnings when I compile the framework:
> https://paste.apache.org/Wy9t 
>
> I used it to compile my app, and I get runtime errors due to missing
> components. This seems to be due to HTML not subclassing Group.
>
> Here’s an example of elements which go AWAL:
> https://paste.apache.org/s9og 
>
> Everything below “ul" is missing.
>
> Harbs
>
> > On May 16, 2018, at 10:45 PM, Alex Harui  > wrote:
> >
> > I'm pretty sure the branches were cut before the changes in question.
> You can pull down the branches and build them to verify.  Or look at their
> history on GitHub.
> >
> > Om, did you see a date for when Maven SCM would be released?  The only
> response I got from the Maven folks was to build Maven SCM from sources.
> If it is going to be more than a week, I might actually try that.
> >
> > -Alex
> >
>
>


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

Re: 0.9.3 Release

[Harbs]

I believe it’s 88cffe995de541584024cbf38eb016acfc677f98.

There are some later commits that we might want to apply to the 0.9.3 branch, 
but that shouldn’t be a big deal.

If it’s easier, you can also branch off feature/revert-refactor. That takes 
88cffe9 and has a few commits applied to it.

Thanks,
Harbs

> On May 17, 2018, at 10:48 AM, Alex Harui  wrote:
> 
> Bummer.  I checked the logs and you are correct.  I thought I'd made the 
> branches before those changes.
> 
> I will probably see if the Maven release plugin will let me create branches 
> from a particular Git commit.  I'll look into it next week.  Do you have a 
> particular commit hash we should use?
> 
> -Alex

Re: 0.9.3 Release

[Piotr Zarzycki]

I do mean let's have it radical changes, but not partially as it is now. It
looks like discussion may bring us some solution.

Thanks,
Piotr

On Thu, May 17, 2018, 8:50 AM Harbs  wrote:

> Having trouble getting this email to “take”. Trying a paste link instead...
>
> It looks like it does have issues.
>
> I just pulled the 0.9.3 branch.
>
> I get a lot of these warnings when I compile the framework:
> https://paste.apache.org/Wy9t 
>
> I used it to compile my app, and I get runtime errors due to missing
> components. This seems to be due to HTML not subclassing Group.
>
> Here’s an example of elements which go AWAL:
> https://paste.apache.org/s9og 
>
> Everything below “ul" is missing.
>
> Harbs
>
> > On May 16, 2018, at 10:45 PM, Alex Harui  > wrote:
> >
> > I'm pretty sure the branches were cut before the changes in question.
> You can pull down the branches and build them to verify.  Or look at their
> history on GitHub.
> >
> > Om, did you see a date for when Maven SCM would be released?  The only
> response I got from the Maven folks was to build Maven SCM from sources.
> If it is going to be more than a week, I might actually try that.
> >
> > -Alex
> >
>
>

Re: 0.9.3 Release

[Harbs]

Having trouble getting this email to “take”...

It looks like it does have issues.

I just pulled the 0.9.3 branch.

I get a lot of these warnings when I compile the framework:
 [java] 
/Apache/royale-asjs/frameworks/projects/DragDrop/src/main/royale/org/apache/royale/html/beads/ButtonBarReorderBead.as(43):
 col: 9 Warning: Definition 
org.apache.royale.html.supportClasses.DataItemRenderer could not be found.
 [java] 
 [java] import org.apache.royale.html.supportClasses.DataItemRenderer;
 [java]^
 [java] 
 [java] 
/Apache/royale-asjs/frameworks/projects/DragDrop/src/main/royale/org/apache/royale/html/beads/DragDropListView.as(29):
 col: 9 Warning: Definition org.apache.royale.html.supportClasses.DataGroup 
could not be found.
 [java] 
 [java] import org.apache.royale.html.supportClasses.DataGroup;
 [java]^

I used it to compile my app, and I get runtime errors due to missing 
components. This seems to be due to HTML not subclassing Group.

Here’s an example of elements which go AWAL:









Everything below  is missing.

> On May 16, 2018, at 10:45 PM, Alex Harui  > wrote:
> 
> I'm pretty sure the branches were cut before the changes in question.  You 
> can pull down the branches and build them to verify.  Or look at their 
> history on GitHub.
> 
> Om, did you see a date for when Maven SCM would be released?  The only 
> response I got from the Maven folks was to build Maven SCM from sources.  If 
> it is going to be more than a week, I might actually try that.
> 
> -Alex
> 

Re: 0.9.3 Release

[Piotr Zarzycki]

Hi Guys,

We definitely cannot have in release breaking changes. We may have another
customer.

I would like to avoid impression for him where in 0.9.3 we have some
changes in the next release there is radical another direction.

It would be great if we could merge at least compiler if there were some
positive changes there to release branch.

I really would be happy to have that fix [1], however if it's not an option
that's ok.

[1] https://github.com/apache/royale-asjs/issues/222

Thanks,
Piotr

On Wed, May 16, 2018, 9:45 PM Alex Harui  wrote:

> I'm pretty sure the branches were cut before the changes in question.  You
> can pull down the branches and build them to verify.  Or look at their
> history on GitHub.
>
> Om, did you see a date for when Maven SCM would be released?  The only
> response I got from the Maven folks was to build Maven SCM from sources.
> If it is going to be more than a week, I might actually try that.
>
> -Alex
>
> On 5/16/18, 11:46 AM, "Harbs"  wrote:
>
> Right now I’m pretty sure we have classes with changed package names.
> That will break existing applications.
>
> I doubt we’re going to be finished with the “refactor” discussion
> before we get the 0.9.3 release out. I’d like to be sure that no package
> names are changed in this release. I don’t really care how we do that.
>
> Thanks,
> Harbs
>
>
> > On May 16, 2018, at 7:54 PM, OmPrakash Muppirala <
> bigosma...@gmail.com> wrote:
> >
> > On Wed, May 16, 2018, 9:42 AM Harbs  wrote:
> >
> >> Can we make sure the release does not have any breaking changes
> currently
> >> in develop?
> >
> >
> > The fixes need to go into develop so that we can simply cut a release
> > branch of off develop.  If not we will have to cherry pick.
> >
> > What is the status of develop?  Are there any tickets we can keep
> track of?
> >
> > Thanks,
> > Om
> >
> >
> >
> >>> On May 16, 2018, at 2:58 AM, OmPrakash Muppirala <
> bigosma...@gmail.com>
> >> wrote:
> >>>
> >>> On Mon, May 14, 2018 at 12:56 PM, Alex Harui   >> aha...@adobe.com>> wrote:
> >>>
>  Update:  I’ve been trying to get the release script to work on
> Windows
>  with Powershell.  I didn’t have to go through the links Om used.
> It
> >> just
>  worked for me, but I’ve been getting other failures that I’ve been
> >> cleaning
>  up.  Annoyingly, I have to reboot my computer before each attempt
> >> because
>  something makes the repo folder appear locked until I reboot.
> 
> 
> 
>  So finally, today, I was able to reproduce Om’s issue about Git
> Add, but
>  it is really about the command-line for Git Add being too long,
> not
> >> about
>  filenames being too long.  I found this PR in the Maven project
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fmaven-scm%2Fpull%2F30=02%7C01%7Caharui%40adobe.com%7C148581f8c5044ef904ff08d5bb5d5ed2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636620932105097613=PxuJZQc8UOa2%2BQpmZY93SAsxnSn2Q6pK04%2BYi1kJK%2FE%3D=0.
> I’m tempted to wait until
>  the next Maven release so we don’t have to spend time refactoring
> our
> >> build
>  scripts to try to work around it.
> 
> >>>
> >>> Alex, I think that should be fine.  It looks like the new version
> of
> >>> maven-scm will be released imminently.  Let's wait for it :-)
> >>>
> >>> If you are going to do the release, can you make sure that you
> create
> >>> upgrade to the latest versions of node.js and npm?  It appears
> that the
> >>> version mismatches are causing the `npm WARN tar invalid entry `
> logs
> >>> during installation.  That should hopefully fix:
> >>>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fissues%2F231=02%7C01%7Caharui%40adobe.com%7C148581f8c5044ef904ff08d5bb5d5ed2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636620932105097613=VOKTeSnHdtVN2KmYI%2FvNfS7u%2BrgcnlcIJf%2BhhKyG3RE%3D=0
> <
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fissues%2F231=02%7C01%7Caharui%40adobe.com%7C148581f8c5044ef904ff08d5bb5d5ed2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636620932105097613=VOKTeSnHdtVN2KmYI%2FvNfS7u%2BrgcnlcIJf%2BhhKyG3RE%3D=0
> >
> >>>
> >>> Thanks,
> >>> Om
> >>>
> >>>
> 
> 
>  Thanks,
> 
>  -Alex
> 
> 
> 
>  *From: *"omup...@gmail.com"  on behalf of
> OmPrakash
>  Muppirala 
>  *Date: *Monday, May 7, 2018 at 11:23 AM
> 
>  *To: *Alex Harui 
>  *Cc: