Re: Let's bump Royale version to 1.0

[Serkan Taş]

Congratulations Alex,

Serkan...

18.02.2020 10:42 tarihinde Alex Harui yazdı:

Today, I received permission to disclose that Alina & Pashmina's team has 88 of 
their modules ready for release (tested and validated by their QA team).  They 
still have more modules to migrate before they deliver to their customer, but it is 
a good sign that the emulation is sufficient for many needs.

Once I can merge the "has" branch and re-stabilize, I will hope that's the last 
big change we need for a while.  I have heard that there are other migration efforts 
underway using migration and I'm sure they will keep finding bugs, but I'm feeling better 
about the emulation code.

-Alex

On 12/18/19, 9:05 AM, "Alex Harui"  wrote:

 Every day, I hope to hear news that Alina & Pashmina or Serkan or somebody else has 
deployed a production app using the MXRoyale and/or Spark Royale emulation components.  But 
instead, I see more bugs being filed for "obvious" things. You can look at the 
issues list of open and fixed issues and the commits that fixed them to get a feel for it.  
Each of us has their own threshold of how good a 1.0 version should be, so if more of you can 
look at these bugs and think it is ok for a 1.0 to have these problems, then great, let's 
release the next version as 1.0, but when I try to remember what Flex 1.0 was like, I think 
it didn't have these kinds of problems.
 
 As Carlos said below, we get one chance to make a good first impression, so I am being conservative.  But it isn't my decision alone.  It is really up to the rest of you.
 
 -Alex
 
 On 12/18/19, 6:41 AM, "Carlos Rovira"  wrote:
 
 Hi Piotr,
 
 I'm afraid my perception is that we need to get to 1.0 in a natural way. I

 mean: releasing 1.0 and giving exposure in all ways we can (webs, 
social
 media, magazines,...), means people will try us. If they try and fail, 
will
 never come back. So think about this as "only on bullet in your gun", 
if
 you fail de shot, that will be bad for all the work we are done. I'm 
ok to
 release 1.0 as soon as we see from "bird eye perspective" that all 
things
 work as we expect.
 
 For me that things are:
 
 * Documentation will need to have at least some missing pages of features

 like: DataBindnig, Loading External Data (HTTPSerice, RemoteObject, 
JSON),
 View States, Item Renderers. Things like this are essential.
 * Emulation components need to be in a shape that allow migrations in a
 good degree. I think people approaching direct migration with emulation
 components will many issues. I don't take into account look and feel of
 emulation components, just functionality and working from a flex code
 perspective, and just normal use cases with MX/Spark code, not third 
party
 libraries that we have no control over. Simple apps like TDF, and 
examples
 should work.
 
 If we decided we want to bypass the previous, at least we need to ensure

 "first try" of Royale for a newcomer (someone that knows very few 
about the
 tech) is successful. This is most important things of all. The other 
two
 are needed if we want people does not get frustrated and have 
solutions on
 their own and stay with us. The opposite is people can have a first try
 successful but abandon Royale due to unfinished things.
 
 I think 0.9.7-SNAPSHOT captures in a realistic number where we are.

 Technology works, and most people using it now can do lots of things, 
but
 we still need to cover some things to reach that 1.0. We are not too 
far
 but I think is still some month in the future.
 
 just my 2 :)
 
 Carlos
 
 
 
 
 El mié., 18 dic. 2019 a las 10:30, Piotr Zarzycki (<

 piotrzarzyck...@gmail.com>) escribió:
 
 > Hello,

 >
 > This thread is old and this was the last message from me. What has 
changed
 > on your end guys ?
 >
 > Thanks,
 > Piotr
 >
 > wt., 30 kwi 2019 o 10:07 Piotr Zarzycki 
 > napisał(a):
 >
 > > Hi Guys,
 > >
 > > Thank you so far for a great discussion. I see that there is an 
obvious
 > > needs to improve documentation the most.
 > >
 > > I would like to express my personal feelings regarding releasing 
anything
 > > what is not 1.0 after 0.9.6. Based on my experience with this 
project I
 > > don't believe that releasing 0.9.7, 0.9.8 till 1.0 etc. will take 
less
 > than
 > > 6-8 months form now on. Even if we will have automatic release 
process I
 > > cannot believe that is going to happen in a less time than I 
mention.
 > >
   

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Hi Piotr,

no. I think we crossed the line some time ago and Royale is now a real and
usable technology.

But we did this issue [1] to talk about things still needed. One required
by Alex was MXRoyale, that seems to be on good way, other like CSS issues
was untouched (I tried to fix some, but with no success and couldn't get
responses to some threads open to guide me on it).

If 1.0 has a special meaning for others not so close to the project is that
"we open doors for all people to start using it" and that means to have
more responsibility to show the project is really valid for masses and
respond to some basic questions:

   - "Do we have most of the documentation ready?" or, if people start
   using it will find the most of the docs needed available. Don't think so,
   just to put a random example, recently a user asked for compiler options,
   and we still don't have that in our docs. I think we could solve this if
   all people involved in Royale could spend some days working on it. But this
   usually means Andrew and me.
   - "Can we release each month or 2 months?", I don't think so. I tried
   the release process and after the maven improvements that break the CI
   steps in Nov-Dec, I tried to fix it with no success, while investing
   several hours. I hope to reach again to that, and see what can I do to help
   on that. Actually, while I'm pro to have ant and maven builds for users, I
   don't understand why we are mixing that with the release process. I think
   we are auto imposing an unnecessary burden with this requeriment. I think
   release process could be greatly simplified if we just use maven, as many
   other projects do (that's the actual way people are doing things, so doing
   that way we're embracing a good practice). So users can build with Ant or
   Maven (what they prefer), but we just need to release with maven on CI,
   that is the natural tool to do that. I think that will solve this point
   without problem, and will remove an actual huge barrier.
   - Actual issues like in the issue [1]: Bindings (we are sponsoring Greg
   this days to fix actual issues and create tests to make bindings
   infrastructure more robust, that are what, in my experience, generates most
   of the problems that appears to users at early stages in Royale) or some
   Jewel issues are in the works today (Virtual DataGrid, Tree,...I need to
   finish dark themes too). Other issues like CSS compiler problems, were
   untouched
   - I need to fix Moonshine mvn sdk compilation too

We already discussed most of this. We have just one bullet. If people
testing Royale has some solid point that Royale is not ok due to not have
enough docs, or having some issues with trying to build some example or
app, then we will have many problems to fix that feeling for people that
tries it.

For that reason, I'm for going naturally to 1.0 instead to bump.

That's what I mean/feel, but if others think we should go 1.0, then I'll
not oppose, but want to warn about it.

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


El mar., 18 feb. 2020 a las 9:57, Piotr Zarzycki ()
escribió:

> Hi Carlos,
>
> Are you have in mind that Royale is not enough good for 1.0 ? I don't
> understand full what do you mean here.
>
> wt., 18 lut 2020 o 09:52 Carlos Rovira 
> napisał(a):
>
> > Hi Alex,
> > very good news. Congrats to all of you working on emulation! :).
> > There's as well other migration efforts based on Jewel and in good
> > progress, but with issues to manage over time. It could be a good time to
> > start trying to release, but I'll try to go 0.9.7 and continue improving
> > until release process could be really easy to do. As well docs continue
> to
> > be something we need if we want to have success for 1.0.
> >
> > El mar., 18 feb. 2020 a las 8:42, Alex Harui ( >)
> > escribió:
> >
> > > Today, I received permission to disclose that Alina & Pashmina's team
> has
> > > 88 of their modules ready for release (tested and validated by their QA
> > > team).  They still have more modules to migrate before they deliver to
> > > their customer, but it is a good sign that the emulation is sufficient
> > for
> > > many needs.
> > >
> > > Once I can merge the "has" branch and re-stabilize, I will hope that's
> > the
> > > last big change we need for a while.  I have heard that there are other
> > > migration efforts underway using migration and I'm sure they will keep
> > > finding bugs, but I'm feeling better about the emulation code.
> > >
> > > -Alex
> > >
> > > On 12/18/19, 9:05 AM, "Alex Harui"  wrote:
> > >
> > > Every day, I hope to hear news that Alina & Pashmina or Serkan or
> > > somebody else has deployed a production app using the MXRoyale and/or
> > Spark
> > > Royale emulation components.  But instead, I see more bugs being filed
> > for
> > > "obvious" things. You can look at the issues list of open and fixed
> > issues
> > > and the commits that fixed them to get a feel for it.  Each of us has
> > their
> > 

Re: Let's bump Royale version to 1.0

[Piotr Zarzycki]

Hi Carlos,

Are you have in mind that Royale is not enough good for 1.0 ? I don't
understand full what do you mean here.

wt., 18 lut 2020 o 09:52 Carlos Rovira  napisał(a):

> Hi Alex,
> very good news. Congrats to all of you working on emulation! :).
> There's as well other migration efforts based on Jewel and in good
> progress, but with issues to manage over time. It could be a good time to
> start trying to release, but I'll try to go 0.9.7 and continue improving
> until release process could be really easy to do. As well docs continue to
> be something we need if we want to have success for 1.0.
>
> El mar., 18 feb. 2020 a las 8:42, Alex Harui ()
> escribió:
>
> > Today, I received permission to disclose that Alina & Pashmina's team has
> > 88 of their modules ready for release (tested and validated by their QA
> > team).  They still have more modules to migrate before they deliver to
> > their customer, but it is a good sign that the emulation is sufficient
> for
> > many needs.
> >
> > Once I can merge the "has" branch and re-stabilize, I will hope that's
> the
> > last big change we need for a while.  I have heard that there are other
> > migration efforts underway using migration and I'm sure they will keep
> > finding bugs, but I'm feeling better about the emulation code.
> >
> > -Alex
> >
> > On 12/18/19, 9:05 AM, "Alex Harui"  wrote:
> >
> > Every day, I hope to hear news that Alina & Pashmina or Serkan or
> > somebody else has deployed a production app using the MXRoyale and/or
> Spark
> > Royale emulation components.  But instead, I see more bugs being filed
> for
> > "obvious" things. You can look at the issues list of open and fixed
> issues
> > and the commits that fixed them to get a feel for it.  Each of us has
> their
> > own threshold of how good a 1.0 version should be, so if more of you can
> > look at these bugs and think it is ok for a 1.0 to have these problems,
> > then great, let's release the next version as 1.0, but when I try to
> > remember what Flex 1.0 was like, I think it didn't have these kinds of
> > problems.
> >
> > As Carlos said below, we get one chance to make a good first
> > impression, so I am being conservative.  But it isn't my decision alone.
> > It is really up to the rest of you.
> >
> > -Alex
> >
> > On 12/18/19, 6:41 AM, "Carlos Rovira" 
> wrote:
> >
> > Hi Piotr,
> >
> > I'm afraid my perception is that we need to get to 1.0 in a
> > natural way. I
> > mean: releasing 1.0 and giving exposure in all ways we can (webs,
> > social
> > media, magazines,...), means people will try us. If they try and
> > fail, will
> > never come back. So think about this as "only on bullet in your
> > gun", if
> > you fail de shot, that will be bad for all the work we are done.
> > I'm ok to
> > release 1.0 as soon as we see from "bird eye perspective" that
> all
> > things
> > work as we expect.
> >
> > For me that things are:
> >
> > * Documentation will need to have at least some missing pages of
> > features
> > like: DataBindnig, Loading External Data (HTTPSerice,
> > RemoteObject, JSON),
> > View States, Item Renderers. Things like this are essential.
> > * Emulation components need to be in a shape that allow
> migrations
> > in a
> > good degree. I think people approaching direct migration with
> > emulation
> > components will many issues. I don't take into account look and
> > feel of
> > emulation components, just functionality and working from a flex
> > code
> > perspective, and just normal use cases with MX/Spark code, not
> > third party
> > libraries that we have no control over. Simple apps like TDF, and
> > examples
> > should work.
> >
> > If we decided we want to bypass the previous, at least we need to
> > ensure
> > "first try" of Royale for a newcomer (someone that knows very few
> > about the
> > tech) is successful. This is most important things of all. The
> > other two
> > are needed if we want people does not get frustrated and have
> > solutions on
> > their own and stay with us. The opposite is people can have a
> > first try
> > successful but abandon Royale due to unfinished things.
> >
> > I think 0.9.7-SNAPSHOT captures in a realistic number where we
> are.
> > Technology works, and most people using it now can do lots of
> > things, but
> > we still need to cover some things to reach that 1.0. We are not
> > too far
> > but I think is still some month in the future.
> >
> > just my 2 :)
> >
> > Carlos
> >
> >
> >
> >
> > El mié., 18 dic. 2019 a las 10:30, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > Hello,
> > >
> > > This thread is old and this was the last message from me. What
> > has changed
> > > on 

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Hi Alex,
very good news. Congrats to all of you working on emulation! :).
There's as well other migration efforts based on Jewel and in good
progress, but with issues to manage over time. It could be a good time to
start trying to release, but I'll try to go 0.9.7 and continue improving
until release process could be really easy to do. As well docs continue to
be something we need if we want to have success for 1.0.

El mar., 18 feb. 2020 a las 8:42, Alex Harui ()
escribió:

> Today, I received permission to disclose that Alina & Pashmina's team has
> 88 of their modules ready for release (tested and validated by their QA
> team).  They still have more modules to migrate before they deliver to
> their customer, but it is a good sign that the emulation is sufficient for
> many needs.
>
> Once I can merge the "has" branch and re-stabilize, I will hope that's the
> last big change we need for a while.  I have heard that there are other
> migration efforts underway using migration and I'm sure they will keep
> finding bugs, but I'm feeling better about the emulation code.
>
> -Alex
>
> On 12/18/19, 9:05 AM, "Alex Harui"  wrote:
>
> Every day, I hope to hear news that Alina & Pashmina or Serkan or
> somebody else has deployed a production app using the MXRoyale and/or Spark
> Royale emulation components.  But instead, I see more bugs being filed for
> "obvious" things. You can look at the issues list of open and fixed issues
> and the commits that fixed them to get a feel for it.  Each of us has their
> own threshold of how good a 1.0 version should be, so if more of you can
> look at these bugs and think it is ok for a 1.0 to have these problems,
> then great, let's release the next version as 1.0, but when I try to
> remember what Flex 1.0 was like, I think it didn't have these kinds of
> problems.
>
> As Carlos said below, we get one chance to make a good first
> impression, so I am being conservative.  But it isn't my decision alone.
> It is really up to the rest of you.
>
> -Alex
>
> On 12/18/19, 6:41 AM, "Carlos Rovira"  wrote:
>
> Hi Piotr,
>
> I'm afraid my perception is that we need to get to 1.0 in a
> natural way. I
> mean: releasing 1.0 and giving exposure in all ways we can (webs,
> social
> media, magazines,...), means people will try us. If they try and
> fail, will
> never come back. So think about this as "only on bullet in your
> gun", if
> you fail de shot, that will be bad for all the work we are done.
> I'm ok to
> release 1.0 as soon as we see from "bird eye perspective" that all
> things
> work as we expect.
>
> For me that things are:
>
> * Documentation will need to have at least some missing pages of
> features
> like: DataBindnig, Loading External Data (HTTPSerice,
> RemoteObject, JSON),
> View States, Item Renderers. Things like this are essential.
> * Emulation components need to be in a shape that allow migrations
> in a
> good degree. I think people approaching direct migration with
> emulation
> components will many issues. I don't take into account look and
> feel of
> emulation components, just functionality and working from a flex
> code
> perspective, and just normal use cases with MX/Spark code, not
> third party
> libraries that we have no control over. Simple apps like TDF, and
> examples
> should work.
>
> If we decided we want to bypass the previous, at least we need to
> ensure
> "first try" of Royale for a newcomer (someone that knows very few
> about the
> tech) is successful. This is most important things of all. The
> other two
> are needed if we want people does not get frustrated and have
> solutions on
> their own and stay with us. The opposite is people can have a
> first try
> successful but abandon Royale due to unfinished things.
>
> I think 0.9.7-SNAPSHOT captures in a realistic number where we are.
> Technology works, and most people using it now can do lots of
> things, but
> we still need to cover some things to reach that 1.0. We are not
> too far
> but I think is still some month in the future.
>
> just my 2 :)
>
> Carlos
>
>
>
>
> El mié., 18 dic. 2019 a las 10:30, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Hello,
> >
> > This thread is old and this was the last message from me. What
> has changed
> > on your end guys ?
> >
> > Thanks,
> > Piotr
> >
> > wt., 30 kwi 2019 o 10:07 Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> > napisał(a):
> >
> > > Hi Guys,
> > >
> > > Thank you so far for a great discussion. I see that there is
> an obvious
> > > needs to improve documentation the most.
> > >
> > > I would like to 

Re: Let's bump Royale version to 1.0

[Alex Harui]

Today, I received permission to disclose that Alina & Pashmina's team has 88 of 
their modules ready for release (tested and validated by their QA team).  They 
still have more modules to migrate before they deliver to their customer, but 
it is a good sign that the emulation is sufficient for many needs.

Once I can merge the "has" branch and re-stabilize, I will hope that's the last 
big change we need for a while.  I have heard that there are other migration 
efforts underway using migration and I'm sure they will keep finding bugs, but 
I'm feeling better about the emulation code.

-Alex

On 12/18/19, 9:05 AM, "Alex Harui"  wrote:

Every day, I hope to hear news that Alina & Pashmina or Serkan or somebody 
else has deployed a production app using the MXRoyale and/or Spark Royale 
emulation components.  But instead, I see more bugs being filed for "obvious" 
things. You can look at the issues list of open and fixed issues and the 
commits that fixed them to get a feel for it.  Each of us has their own 
threshold of how good a 1.0 version should be, so if more of you can look at 
these bugs and think it is ok for a 1.0 to have these problems, then great, 
let's release the next version as 1.0, but when I try to remember what Flex 1.0 
was like, I think it didn't have these kinds of problems.

As Carlos said below, we get one chance to make a good first impression, so 
I am being conservative.  But it isn't my decision alone.  It is really up to 
the rest of you.

-Alex

On 12/18/19, 6:41 AM, "Carlos Rovira"  wrote:

Hi Piotr,

I'm afraid my perception is that we need to get to 1.0 in a natural 
way. I
mean: releasing 1.0 and giving exposure in all ways we can (webs, social
media, magazines,...), means people will try us. If they try and fail, 
will
never come back. So think about this as "only on bullet in your gun", if
you fail de shot, that will be bad for all the work we are done. I'm ok 
to
release 1.0 as soon as we see from "bird eye perspective" that all 
things
work as we expect.

For me that things are:

* Documentation will need to have at least some missing pages of 
features
like: DataBindnig, Loading External Data (HTTPSerice, RemoteObject, 
JSON),
View States, Item Renderers. Things like this are essential.
* Emulation components need to be in a shape that allow migrations in a
good degree. I think people approaching direct migration with emulation
components will many issues. I don't take into account look and feel of
emulation components, just functionality and working from a flex code
perspective, and just normal use cases with MX/Spark code, not third 
party
libraries that we have no control over. Simple apps like TDF, and 
examples
should work.

If we decided we want to bypass the previous, at least we need to ensure
"first try" of Royale for a newcomer (someone that knows very few about 
the
tech) is successful. This is most important things of all. The other two
are needed if we want people does not get frustrated and have solutions 
on
their own and stay with us. The opposite is people can have a first try
successful but abandon Royale due to unfinished things.

I think 0.9.7-SNAPSHOT captures in a realistic number where we are.
Technology works, and most people using it now can do lots of things, 
but
we still need to cover some things to reach that 1.0. We are not too far
but I think is still some month in the future.

just my 2 :)

Carlos




El mié., 18 dic. 2019 a las 10:30, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Hello,
>
> This thread is old and this was the last message from me. What has 
changed
> on your end guys ?
>
> Thanks,
> Piotr
>
> wt., 30 kwi 2019 o 10:07 Piotr Zarzycki 
> napisał(a):
>
> > Hi Guys,
> >
> > Thank you so far for a great discussion. I see that there is an 
obvious
> > needs to improve documentation the most.
> >
> > I would like to express my personal feelings regarding releasing 
anything
> > what is not 1.0 after 0.9.6. Based on my experience with this 
project I
> > don't believe that releasing 0.9.7, 0.9.8 till 1.0 etc. will take 
less
> than
> > 6-8 months form now on. Even if we will have automatic release 
process I
> > cannot believe that is going to happen in a less time than I 
mention.
> >
> > Why I'm thinking like that:
> > - Justin just provided to the contributors generous offer - it's 
been
> > couple of days and there is 

Re: Let's bump Royale version to 1.0

[Alex Harui]

Every day, I hope to hear news that Alina & Pashmina or Serkan or somebody else 
has deployed a production app using the MXRoyale and/or Spark Royale emulation 
components.  But instead, I see more bugs being filed for "obvious" things. You 
can look at the issues list of open and fixed issues and the commits that fixed 
them to get a feel for it.  Each of us has their own threshold of how good a 
1.0 version should be, so if more of you can look at these bugs and think it is 
ok for a 1.0 to have these problems, then great, let's release the next version 
as 1.0, but when I try to remember what Flex 1.0 was like, I think it didn't 
have these kinds of problems.

As Carlos said below, we get one chance to make a good first impression, so I 
am being conservative.  But it isn't my decision alone.  It is really up to the 
rest of you.

-Alex

On 12/18/19, 6:41 AM, "Carlos Rovira"  wrote:

Hi Piotr,

I'm afraid my perception is that we need to get to 1.0 in a natural way. I
mean: releasing 1.0 and giving exposure in all ways we can (webs, social
media, magazines,...), means people will try us. If they try and fail, will
never come back. So think about this as "only on bullet in your gun", if
you fail de shot, that will be bad for all the work we are done. I'm ok to
release 1.0 as soon as we see from "bird eye perspective" that all things
work as we expect.

For me that things are:

* Documentation will need to have at least some missing pages of features
like: DataBindnig, Loading External Data (HTTPSerice, RemoteObject, JSON),
View States, Item Renderers. Things like this are essential.
* Emulation components need to be in a shape that allow migrations in a
good degree. I think people approaching direct migration with emulation
components will many issues. I don't take into account look and feel of
emulation components, just functionality and working from a flex code
perspective, and just normal use cases with MX/Spark code, not third party
libraries that we have no control over. Simple apps like TDF, and examples
should work.

If we decided we want to bypass the previous, at least we need to ensure
"first try" of Royale for a newcomer (someone that knows very few about the
tech) is successful. This is most important things of all. The other two
are needed if we want people does not get frustrated and have solutions on
their own and stay with us. The opposite is people can have a first try
successful but abandon Royale due to unfinished things.

I think 0.9.7-SNAPSHOT captures in a realistic number where we are.
Technology works, and most people using it now can do lots of things, but
we still need to cover some things to reach that 1.0. We are not too far
but I think is still some month in the future.

just my 2 :)

Carlos




El mié., 18 dic. 2019 a las 10:30, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Hello,
>
> This thread is old and this was the last message from me. What has changed
> on your end guys ?
>
> Thanks,
> Piotr
>
> wt., 30 kwi 2019 o 10:07 Piotr Zarzycki 
> napisał(a):
>
> > Hi Guys,
> >
> > Thank you so far for a great discussion. I see that there is an obvious
> > needs to improve documentation the most.
> >
> > I would like to express my personal feelings regarding releasing 
anything
> > what is not 1.0 after 0.9.6. Based on my experience with this project I
> > don't believe that releasing 0.9.7, 0.9.8 till 1.0 etc. will take less
> than
> > 6-8 months form now on. Even if we will have automatic release process I
> > cannot believe that is going to happen in a less time than I mention.
> >
> > Why I'm thinking like that:
> > - Justin just provided to the contributors generous offer - it's been
> > couple of days and there is absolutely no response.
> > - I've seen as part of the responses some concrete issues towards code 
in
> > SDK. I don't believe that there will be anyone who fix them UNLESS
> someone
> > need that stuff in his application which has been under development in
> his
> > daily job. Which leads me to conclusion that we will wait months before
> > anything from that list will be fixed.
> >
> > How Royale is going on right now?
> > In my original email I expressed that it is enough good to bump it to 
1.0
> > - which gets us more credibility and push us to a better light. I got
> clear
> > responses from community that the only thing which is in the way of to
> 1.0
> > is documentation.
> >
> > W have one production app in Royale, another one has been created by
> > Carlos. I'm working on the third one. Justin mention fourth one which 
I'm
> > reviewing right now because it is written in Flex - it 

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Hi Piotr,

I'm afraid my perception is that we need to get to 1.0 in a natural way. I
mean: releasing 1.0 and giving exposure in all ways we can (webs, social
media, magazines,...), means people will try us. If they try and fail, will
never come back. So think about this as "only on bullet in your gun", if
you fail de shot, that will be bad for all the work we are done. I'm ok to
release 1.0 as soon as we see from "bird eye perspective" that all things
work as we expect.

For me that things are:

* Documentation will need to have at least some missing pages of features
like: DataBindnig, Loading External Data (HTTPSerice, RemoteObject, JSON),
View States, Item Renderers. Things like this are essential.
* Emulation components need to be in a shape that allow migrations in a
good degree. I think people approaching direct migration with emulation
components will many issues. I don't take into account look and feel of
emulation components, just functionality and working from a flex code
perspective, and just normal use cases with MX/Spark code, not third party
libraries that we have no control over. Simple apps like TDF, and examples
should work.

If we decided we want to bypass the previous, at least we need to ensure
"first try" of Royale for a newcomer (someone that knows very few about the
tech) is successful. This is most important things of all. The other two
are needed if we want people does not get frustrated and have solutions on
their own and stay with us. The opposite is people can have a first try
successful but abandon Royale due to unfinished things.

I think 0.9.7-SNAPSHOT captures in a realistic number where we are.
Technology works, and most people using it now can do lots of things, but
we still need to cover some things to reach that 1.0. We are not too far
but I think is still some month in the future.

just my 2 :)

Carlos




El mié., 18 dic. 2019 a las 10:30, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Hello,
>
> This thread is old and this was the last message from me. What has changed
> on your end guys ?
>
> Thanks,
> Piotr
>
> wt., 30 kwi 2019 o 10:07 Piotr Zarzycki 
> napisał(a):
>
> > Hi Guys,
> >
> > Thank you so far for a great discussion. I see that there is an obvious
> > needs to improve documentation the most.
> >
> > I would like to express my personal feelings regarding releasing anything
> > what is not 1.0 after 0.9.6. Based on my experience with this project I
> > don't believe that releasing 0.9.7, 0.9.8 till 1.0 etc. will take less
> than
> > 6-8 months form now on. Even if we will have automatic release process I
> > cannot believe that is going to happen in a less time than I mention.
> >
> > Why I'm thinking like that:
> > - Justin just provided to the contributors generous offer - it's been
> > couple of days and there is absolutely no response.
> > - I've seen as part of the responses some concrete issues towards code in
> > SDK. I don't believe that there will be anyone who fix them UNLESS
> someone
> > need that stuff in his application which has been under development in
> his
> > daily job. Which leads me to conclusion that we will wait months before
> > anything from that list will be fixed.
> >
> > How Royale is going on right now?
> > In my original email I expressed that it is enough good to bump it to 1.0
> > - which gets us more credibility and push us to a better light. I got
> clear
> > responses from community that the only thing which is in the way of to
> 1.0
> > is documentation.
> >
> > W have one production app in Royale, another one has been created by
> > Carlos. I'm working on the third one. Justin mention fourth one which I'm
> > reviewing right now because it is written in Flex - it looks there won't
> be
> > problem with porting to Royale. To me it is enough proof that Royale is
> as
> > good as is to expose itself for more wider audience. Because this is
> > exactly what will happen when we bump to that magic 1.0.
> > People on this project are talking about community, my proposition to
> bump
> > Royale to 1.0 is towards community with hope that it helps grow thanks to
> > that step. With hope that finally I will see on the list more people,
> with
> > hope that I will see someone who doesn't have background in ActionScript,
> > but was curious about the project.
> >
> > In this thread I don't see rejection to my idea, so I'm going to work to
> > improve some areas and start release with bumped version to 1.0, whether
> it
> > will be after 0.9.7, 0.9.8 it doesn't matter - What's really matter is
> that
> > we are not facing in current version any walls during development, so
> this
> > is enough to me giving that framework 1.0.
> >
> > Thanks,
> > Piotr
> >
> > pon., 29 kwi 2019 o 19:44 Carlos Rovira 
> > napisał(a):
> >
> >> Hi Justin,
> >>
> >> great initiative, but some thoughts:
> >>
> >> 1.- As Olaf said, Alex or I are just two more devs, so we can say what
> >> should we do. That's the apache way! :), only work 

Re: Let's bump Royale version to 1.0

[Piotr Zarzycki]

Hello,

This thread is old and this was the last message from me. What has changed
on your end guys ?

Thanks,
Piotr

wt., 30 kwi 2019 o 10:07 Piotr Zarzycki 
napisał(a):

> Hi Guys,
>
> Thank you so far for a great discussion. I see that there is an obvious
> needs to improve documentation the most.
>
> I would like to express my personal feelings regarding releasing anything
> what is not 1.0 after 0.9.6. Based on my experience with this project I
> don't believe that releasing 0.9.7, 0.9.8 till 1.0 etc. will take less than
> 6-8 months form now on. Even if we will have automatic release process I
> cannot believe that is going to happen in a less time than I mention.
>
> Why I'm thinking like that:
> - Justin just provided to the contributors generous offer - it's been
> couple of days and there is absolutely no response.
> - I've seen as part of the responses some concrete issues towards code in
> SDK. I don't believe that there will be anyone who fix them UNLESS someone
> need that stuff in his application which has been under development in his
> daily job. Which leads me to conclusion that we will wait months before
> anything from that list will be fixed.
>
> How Royale is going on right now?
> In my original email I expressed that it is enough good to bump it to 1.0
> - which gets us more credibility and push us to a better light. I got clear
> responses from community that the only thing which is in the way of to 1.0
> is documentation.
>
> W have one production app in Royale, another one has been created by
> Carlos. I'm working on the third one. Justin mention fourth one which I'm
> reviewing right now because it is written in Flex - it looks there won't be
> problem with porting to Royale. To me it is enough proof that Royale is as
> good as is to expose itself for more wider audience. Because this is
> exactly what will happen when we bump to that magic 1.0.
> People on this project are talking about community, my proposition to bump
> Royale to 1.0 is towards community with hope that it helps grow thanks to
> that step. With hope that finally I will see on the list more people, with
> hope that I will see someone who doesn't have background in ActionScript,
> but was curious about the project.
>
> In this thread I don't see rejection to my idea, so I'm going to work to
> improve some areas and start release with bumped version to 1.0, whether it
> will be after 0.9.7, 0.9.8 it doesn't matter - What's really matter is that
> we are not facing in current version any walls during development, so this
> is enough to me giving that framework 1.0.
>
> Thanks,
> Piotr
>
> pon., 29 kwi 2019 o 19:44 Carlos Rovira 
> napisał(a):
>
>> Hi Justin,
>>
>> great initiative, but some thoughts:
>>
>> 1.- As Olaf said, Alex or I are just two more devs, so we can say what
>> should we do. That's the apache way! :), only work towards the goal and
>> giving advice to make things happen. We decisions are community managed
>>
>> 2.- I think is very generous offer so people can contribute and earn some
>> money and a great plan,
>>
>> Some things you should take into account for the rewarding plan:
>>
>> * We just get results of the poll about releasing published few minutes
>> ago. Seems people wants to focus docs first and release second (from 61
>> votes).
>> * In the other hand, I see Alex is still fighting with the release
>> process.
>> He stated that probably this week he will have the process ready to be
>> tested by someone.
>> If he get to that point that will be awesome, and hope others could be the
>> first one in try to "push the button". If that works ok, we'll have a
>> 0.9.6
>> release (I think the one by Alex), and then a 0.9.7 (by that new release
>> manager). At that point, I figure we can plan 0.9.8, 0.9.9 and Finlay 1.0.
>> For me release should happen at least from month to month. have sense?
>>
>> Just my my thoughts, but hope other want to share here what they can do
>> and
>> work to earn some money too! :)
>>
>>
>>
>> >
>> > --
>> > Carlos Rovira
>> > http://about.me/carlosrovira
>> >
>> >
>> >
>> >
>>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>


-- 

Piotr Zarzycki

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

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Josh Tynjala]

I meant that the VersionBead would contain the Royale SDK version. A separate 
version bead for the app's version would be useful too, but that's not what I 
was suggesting.

- Josh

On 2019/04/30 20:14:31, Mark Kessler  wrote: 
> Well that would work in addition too, but not replace what I'm talking
> about.  I'm talking about the SDK having a built in version.  A
> version bead would be more building an app using the SDK and the app
> having it's own version.
> 
> 
> -Mark K
> 
> On Tue, Apr 30, 2019 at 2:39 PM Piotr Zarzycki
>  wrote:
> >
> > +1 to Josh's idea that we provide bead with logic which serves version.
> >
> > Thanks,
> > Piotr
> 

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Alex Harui]

I'm fine with starting with your example.  Are other versions in Royale 
including the build number?  Are you expecting the build systems to update that 
file on each build?  That might be trickier.  The Maven builds check for 
uncommitted files.

Regarding your other response, I'm not sure that grep worked with Ant on 
Windows.  It would be best to either have Ant generate the entire file or use 
its replaceregex task on a known pattern.

My 2 cents,
-Alex

On 4/30/19, 4:02 PM, "Mark Kessler"  wrote:

Don't need every SWC with a version.  Just one for the whole SDK would
be fine.  I proposed just a single one stored in the core.  We can
modify the build file to just point to the single file instead of
doing a path search.  See the start of my example [1].


[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKesslerConsulting%2Froyale-asjs%2Fcommit%2F84262f3a2e56cc6b58ccdf283d039c94fb10cafbdata=02%7C01%7Caharui%40adobe.com%7Cd74e4fe942624e46e11708d6cdbfdac8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636922621260197257sdata=9UFENmZCH%2BwoK3OJHx1e%2B85bu%2FhIeIr%2F94QS4NYO5xA%3Dreserved=0

-Mark K


On Tue, Apr 30, 2019 at 6:42 PM Alex Harui  wrote:
>
> To be more specific:
>
> Version.as in Flex was included into every class.  I do not recommend 
doing that in Royale.  It didn't have enough value for the cost.
>
> FlexVersion.as in Flex was used for runtime versioning.  Code could use 
it to take different paths.  I hope we don't need that in Royale.
>
> The Flex and Royale compilers will put the compiler version in SWFs but 
do not put any string in JS output.  Someday, the Royale compiler may be 
released separately from the SWCs.  Royale may stop releasing certain SWCs in 
the future if there is no interest in maintaining them.  Then we will have to 
decide whether to update the version of those SWCs after they are frozen.  
Royale SWCs do not carry version information on a per-SWC basis.  But in some 
future, you could be using some version of the Royale compiler to compile with 
SWCs from different versions of the Royale SDKs.
>
> This version information is defined in the pom for folks using Maven.  It 
is not defined at all for other build mechanisms (Ant, command-line, IDEs) 
because the non-Maven artifacts do not have versions in the file names.  That's 
on purpose.  We want to make it easy for non-Maven users to swap versions of 
SDKs.  Maven users prioritize explicit dependency information over swapping of 
SDK versions.
>
> In summary, Royale may not be released like Flex where all SWCs are 
updated for each release along with a compiler.  So I'm not exactly sure what 
problem is trying to be solved, but it won't hurt to have a version bead or 
version constant.  And if someone wants to propose a way to get the compiler to 
inject a version string in JS output, that's fine too, but keep in mind that 
all of these verions strings might get removed during minification so they will 
probably need to be an exported public variable/constant.
>
> It would be great to have the version automatically updated for each 
release, but I think the number of places we currently change are small so 
having one more place probably is ok.  All it takes is a volunteer to create 
the PRs or commit the code.
>
> My 2 cents,
> -Alex
>
>

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Mark Kessler]

Don't need every SWC with a version.  Just one for the whole SDK would
be fine.  I proposed just a single one stored in the core.  We can
modify the build file to just point to the single file instead of
doing a path search.  See the start of my example [1].


[1] 
https://github.com/KesslerConsulting/royale-asjs/commit/84262f3a2e56cc6b58ccdf283d039c94fb10cafb

-Mark K


On Tue, Apr 30, 2019 at 6:42 PM Alex Harui  wrote:
>
> To be more specific:
>
> Version.as in Flex was included into every class.  I do not recommend doing 
> that in Royale.  It didn't have enough value for the cost.
>
> FlexVersion.as in Flex was used for runtime versioning.  Code could use it to 
> take different paths.  I hope we don't need that in Royale.
>
> The Flex and Royale compilers will put the compiler version in SWFs but do 
> not put any string in JS output.  Someday, the Royale compiler may be 
> released separately from the SWCs.  Royale may stop releasing certain SWCs in 
> the future if there is no interest in maintaining them.  Then we will have to 
> decide whether to update the version of those SWCs after they are frozen.  
> Royale SWCs do not carry version information on a per-SWC basis.  But in some 
> future, you could be using some version of the Royale compiler to compile 
> with SWCs from different versions of the Royale SDKs.
>
> This version information is defined in the pom for folks using Maven.  It is 
> not defined at all for other build mechanisms (Ant, command-line, IDEs) 
> because the non-Maven artifacts do not have versions in the file names.  
> That's on purpose.  We want to make it easy for non-Maven users to swap 
> versions of SDKs.  Maven users prioritize explicit dependency information 
> over swapping of SDK versions.
>
> In summary, Royale may not be released like Flex where all SWCs are updated 
> for each release along with a compiler.  So I'm not exactly sure what problem 
> is trying to be solved, but it won't hurt to have a version bead or version 
> constant.  And if someone wants to propose a way to get the compiler to 
> inject a version string in JS output, that's fine too, but keep in mind that 
> all of these verions strings might get removed during minification so they 
> will probably need to be an exported public variable/constant.
>
> It would be great to have the version automatically updated for each release, 
> but I think the number of places we currently change are small so having one 
> more place probably is ok.  All it takes is a volunteer to create the PRs or 
> commit the code.
>
> My 2 cents,
> -Alex
>
>

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Mark Kessler]

We can through an old mechanism that appears to be left from the
Apache Flex side that does just this.

Around line1192 of the root build.xml [1].  It specifically hunts down
files called "Version.as" and uses RegEx to update the version number
and build number.  So when the SDK is built for release, it will
automatically update the Version.as files using the "release.version"
property.  Meaning after we create the file(Version.as) having the
correct version format inside it it will be something that stays
up-to-date automatically.  Little tweaks needed it looks like, but it
should work.

build.xml lines look like this:















I won't have a chance to test the build.xml right now to finish it,
but here is what the rest of it would look like [2] (very short).

Usage for the end user:

import org.apache.royale.core.Version;

trace(Version.CURRENT_VERSION);


[1] https://github.com/apache/royale-asjs/blob/develop/build.xml
[2] 
https://github.com/KesslerConsulting/royale-asjs/commit/84262f3a2e56cc6b58ccdf283d039c94fb10cafb

-Mark K

On Tue, Apr 30, 2019 at 5:17 PM Carlos Rovira  wrote:
>
> Well,
> since others techs make that maybe it would be ok to have it baked. Right
> now I don't have a strong opinion about what to do maybe others could bring
> more light, but Version class seems ok to me, and hope we could have it get
> the version directly without manual modifications what will very cumbersome
> to manage for releases, niglhly builds, etc..
>

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Alex Harui]

To be more specific:

Version.as in Flex was included into every class.  I do not recommend doing 
that in Royale.  It didn't have enough value for the cost.

FlexVersion.as in Flex was used for runtime versioning.  Code could use it to 
take different paths.  I hope we don't need that in Royale.

The Flex and Royale compilers will put the compiler version in SWFs but do not 
put any string in JS output.  Someday, the Royale compiler may be released 
separately from the SWCs.  Royale may stop releasing certain SWCs in the future 
if there is no interest in maintaining them.  Then we will have to decide 
whether to update the version of those SWCs after they are frozen.  Royale SWCs 
do not carry version information on a per-SWC basis.  But in some future, you 
could be using some version of the Royale compiler to compile with SWCs from 
different versions of the Royale SDKs.

This version information is defined in the pom for folks using Maven.  It is 
not defined at all for other build mechanisms (Ant, command-line, IDEs) because 
the non-Maven artifacts do not have versions in the file names.  That's on 
purpose.  We want to make it easy for non-Maven users to swap versions of SDKs. 
 Maven users prioritize explicit dependency information over swapping of SDK 
versions.

In summary, Royale may not be released like Flex where all SWCs are updated for 
each release along with a compiler.  So I'm not exactly sure what problem is 
trying to be solved, but it won't hurt to have a version bead or version 
constant.  And if someone wants to propose a way to get the compiler to inject 
a version string in JS output, that's fine too, but keep in mind that all of 
these verions strings might get removed during minification so they will 
probably need to be an exported public variable/constant.

It would be great to have the version automatically updated for each release, 
but I think the number of places we currently change are small so having one 
more place probably is ok.  All it takes is a volunteer to create the PRs or 
commit the code.

My 2 cents,
-Alex



On 4/30/19, 2:17 PM, "Carlos Rovira"  wrote:

Well,
since others techs make that maybe it would be ok to have it baked. Right
now I don't have a strong opinion about what to do maybe others could bring
more light, but Version class seems ok to me, and hope we could have it get
the version directly without manual modifications what will very cumbersome
to manage for releases, niglhly builds, etc..

El mar., 30 abr. 2019 a las 22:14, Mark Kessler (<
kesslerconsult...@gmail.com>) escribió:

> Well that would work in addition too, but not replace what I'm talking
> about.  I'm talking about the SDK having a built in version.  A
> version bead would be more building an app using the SDK and the app
> having it's own version.
>
>
> -Mark K
>
> On Tue, Apr 30, 2019 at 2:39 PM Piotr Zarzycki
>  wrote:
> >
> > +1 to Josh's idea that we provide bead with logic which serves version.
> >
> > Thanks,
> > Piotr
>


-- 
Carlos Rovira

https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C5cf03e97fd1e4d637be208d6cdb14239%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636922558582228586sdata=lF%2FwGT5b6MoKml%2BocTXLOxuaukVn7%2BkkdgRmUE59EuY%3Dreserved=0

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Carlos Rovira]

Well,
since others techs make that maybe it would be ok to have it baked. Right
now I don't have a strong opinion about what to do maybe others could bring
more light, but Version class seems ok to me, and hope we could have it get
the version directly without manual modifications what will very cumbersome
to manage for releases, niglhly builds, etc..

El mar., 30 abr. 2019 a las 22:14, Mark Kessler (<
kesslerconsult...@gmail.com>) escribió:

> Well that would work in addition too, but not replace what I'm talking
> about.  I'm talking about the SDK having a built in version.  A
> version bead would be more building an app using the SDK and the app
> having it's own version.
>
>
> -Mark K
>
> On Tue, Apr 30, 2019 at 2:39 PM Piotr Zarzycki
>  wrote:
> >
> > +1 to Josh's idea that we provide bead with logic which serves version.
> >
> > Thanks,
> > Piotr
>


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

Re: extending IUIBase with interfaces (was: Re: Version property (was: Let's bump Royale version to 1.0))

[Alex Harui]

Hi Carlos,

I've said this before:  I feel bad sometimes that Flex taught folks some 
questionable programming practices.

The short answer:
-Don't reference concrete classes
-Choose composition patterns over inheritance

The long answer:

Yishay and Andrew are headed in the right direction.  A good goal for Royale is 
to try to avoid references to concrete classes (other than what your class 
subclasses).  Referencing concrete classes essentially breaks PAYG by creating 
an unreplaceable chain of dependencies.  Flex referenced too many concrete 
classes and we all paid for it.

But addition to using interfaces, we should try to remember that Royale is more 
about composition than inheritance.  Beads are composed into instances to 
implement functionality.  Hopefully, many beads can be re-used on other 
instances with different base class ancestry if the API surfaces are designed 
correctly.

And, not only are beads best referenced via their interfaces, you can also ask 
"has" instead of "is".  IOW, you can ask if an instance "has" a bead instead of 
just testing if the instance "is" (implements) an interface.

The first word in PAYG is Pay.  PAYG is not Free-AYG.  Somebody has to pay.  
The more features you use, the more you pay in download size and performance, 
especially at startup.  The point of PAYG and beads is to enable optimization.  
If you want to make cookies and you buy each ingredient separately it will take 
up more space and weight because of the packaging as opposed to buying one bag 
of ready-to-bake cookie mix.  But the point of having separate ingredients is 
so you can replace white flour with whole wheat or rye or gluten-free easily.

If it turns out there is significant overhead in some set of beads, you can 
choose to inline them, just like any other inlining optimization.  That is a 
manual process today.  Inlining is effectively copying code, so it sounds like 
that is what you are doing today.  But the copying of code should only be a 
last resort after proving that the composition patterns have too much overhead. 
 The inlining will have its own overhead, usually in download size, as you 
mentioned.

I explained the "exploded component" concept a while back.  It attempts to 
illustrate composition by showing how, in MXML, a component can really be 
declared as its beads.  For example:



Could be written more verbosely as:


   



  


Then a ToggleButton could be implemented by simply replacing the controller 
(and probably the view).


   



  


So it is only for convenience, so you don't have to type all of these tags, 
that we create a top-level component (TLC) called Button that pre-packages some 
set of beads and write glue code that proxies some of the bead APIs to the 
TLC's API such as:

public class Button extends UIBase
{
   public function set label(value:String):void
   {
  model.label = value;
   }
}

The point, relative to this topic, is there is a cost to this convenience, 
which is the line or two of glue code.

So, with beads, it is only for convenience that the TLC implements these PAYG 
interfaces.  If you package up the implementation of IClassSelectorListSupport 
into a bead, that bead should be able to be composed into different classes 
with different base classes.  We actually have a choice of whether to add the 
glue code that proxies that implementation to the API surface.  If you do that 
proxying, then other code can look like:

if (myInstance is IClassSelectorListSupport)
   (myInstance as IClassSelectorListSupport).someAPi = "foo";

But the other option is the "has" pattern, which looks like:

Var foo:IClassSelectorListSupport = 
myInstance.getBeadByType(IClassSelectorListSupport);
If (foo)
foo.someAPI = "foo";

I've not done any measuring of which is better, but the latter does not require 
glue code, which allows someone to just drop in any IClassSelectorListSupport 
bead on some other random instance they've created and not make any assumptions 
about base classes or proxy code to interfaces.  For example:


  

  


This instance, declared in MXML without the overhead of creating a TLC and 
proxying code to the API surface, would work with the "has" code, but not the 
"is" code.

Is it all worth it?  I don't know.  I'm waiting to see folks try it, especially 
in more complex apps.  But for sure, composition "has" patterns are more 
flexible than traditional "is" patterns.

This "has" pattern allows us to sort of have multiple inheritance or "mixin" 
type patterns, but it is done by accessing the beads directly not by proxying 
code to the TLC so "inheritance" isn't an accurate word.  TLCs are more for 
convenience, to avoid repeating a lot of tags in MXML or calling addBead a lot, 
but we should try to make our code even more flexible by not requiring folks to 
work with TLCs.

So, in theory, you should try to package the implementation of 
IClassSelectorListSupport into a bead and see if you run into 

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Mark Kessler]

Well that would work in addition too, but not replace what I'm talking
about.  I'm talking about the SDK having a built in version.  A
version bead would be more building an app using the SDK and the app
having it's own version.


-Mark K

On Tue, Apr 30, 2019 at 2:39 PM Piotr Zarzycki
 wrote:
>
> +1 to Josh's idea that we provide bead with logic which serves version.
>
> Thanks,
> Piotr

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Piotr Zarzycki]

+1 to Josh's idea that we provide bead with logic which serves version.

Thanks,
Piotr

On Tue, Apr 30, 2019, 8:18 PM Kessler CTR Mark J
 wrote:

> As an example, here is how to access the version number in other
> languages.  Some easier to use than others.  Looks like the easiest ones
> are just static const strings.
>
> Flex[1]:  mx.core.FlexVersion.CURRENT_VERSION
> Dotnet[2]: System.Environment.Version
> Java[3]:System.getProperty("java.version");
> React[4]: React.version
> Angular[5]: import { VERSION } from '@angular/core';  VERSION.full
> Groovy[6]: GroovySystem.getVersion();
> Ruby[7]: RUBY_VERSION
> Python[8]: sys.version
> Node.Js[9]: process.version
> PHP[10]: phpversion()
>
>
> So I would like the SDK to provide something similar.  It looks like we
> still have a mechanism setup in the build.xml we are just missing the files
> it's looking for (Version.as files).  Let's add the following file and see
> if it with a little tweak in pathing would turn it into a self-managing
> version file when building the SDK for release.  This looks like a smallest
> simplest mechanism to implement this.  Especially since it's regex pattern
> matching the old version format, it doesn't matter how we layout the file.
>
> File: Version.as
>
> package org.apache.royale.core
> {
> public class Version
> {
> public static const CURRENT_VERSION:String = "0.9.6.0";
> }
> }
>
>
> SDK Usage for developer:
> Import org.apache.core.Version;
> trace(Version.CURRENT_VERSION);
>
>
> [1] https://flex.apache.org/asdoc/mx/core/FlexVersion.html
> [2]
> https://docs.microsoft.com/en-us/dotnet/api/system.environment.version?view=netframework-4.8
> [3]
> https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
> [4]
> https://stackoverflow.com/questions/36994564/how-can-one-tell-the-version-of-react-running-at-runtime-in-the-browser
> [5]
> https://stackoverflow.com/questions/36456843/how-to-check-angular2-version-with-typescript
> [6]
> http://docs.groovy-lang.org/latest/html/api/groovy/lang/GroovySystem.html
> [7]
> https://stackoverflow.com/questions/1589751/determine-ruby-version-from-within-rails
> [8] https://docs.python.org/3/library/sys.html
> [9] https://nodejs.org/api/process.html#process_process_version
> [10] https://www.php.net/manual/en/function.phpversion.php
>
>
> -Mark K
>
>
> -Original Message-----
> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> Sent: Tuesday, April 30, 2019 10:37 AM
> To: dev@royale.apache.org
> Subject: Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale
> version to 1.0)
>
> Hi Mark,
>
> sorry but all you state can be solved with the solution I exposed to you.
> There's no need to add an identifier to an SDK since you can add it
> yourself from the SDK you downloaded or get by the multiple ways available.
> In any of the cases the numbers are not baked into code, but are available
> in different parts and you can use defines to bake it into your code and
> use it in the same way you use to do in Flex. At least I don't see from
> your response that your points will not be covered in that way
>

RE: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Kessler CTR Mark J]

As an example, here is how to access the version number in other languages.  
Some easier to use than others.  Looks like the easiest ones are just static 
const strings.

Flex[1]:  mx.core.FlexVersion.CURRENT_VERSION
Dotnet[2]: System.Environment.Version
Java[3]:System.getProperty("java.version");
React[4]: React.version
Angular[5]: import { VERSION } from '@angular/core';  VERSION.full
Groovy[6]: GroovySystem.getVersion();
Ruby[7]: RUBY_VERSION
Python[8]: sys.version
Node.Js[9]: process.version
PHP[10]: phpversion()


So I would like the SDK to provide something similar.  It looks like we still 
have a mechanism setup in the build.xml we are just missing the files it's 
looking for (Version.as files).  Let's add the following file and see if it 
with a little tweak in pathing would turn it into a self-managing version file 
when building the SDK for release.  This looks like a smallest simplest 
mechanism to implement this.  Especially since it's regex pattern matching the 
old version format, it doesn't matter how we layout the file.

File: Version.as

package org.apache.royale.core
{
public class Version
{
public static const CURRENT_VERSION:String = "0.9.6.0";
}
}


SDK Usage for developer: 
Import org.apache.core.Version;
trace(Version.CURRENT_VERSION);


[1] https://flex.apache.org/asdoc/mx/core/FlexVersion.html
[2] 
https://docs.microsoft.com/en-us/dotnet/api/system.environment.version?view=netframework-4.8
[3] https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
[4] 
https://stackoverflow.com/questions/36994564/how-can-one-tell-the-version-of-react-running-at-runtime-in-the-browser
[5] 
https://stackoverflow.com/questions/36456843/how-to-check-angular2-version-with-typescript
[6] http://docs.groovy-lang.org/latest/html/api/groovy/lang/GroovySystem.html
[7] 
https://stackoverflow.com/questions/1589751/determine-ruby-version-from-within-rails
[8] https://docs.python.org/3/library/sys.html
[9] https://nodejs.org/api/process.html#process_process_version
[10] https://www.php.net/manual/en/function.phpversion.php


-Mark K


-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: Tuesday, April 30, 2019 10:37 AM
To: dev@royale.apache.org
Subject: Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale 
version to 1.0)

Hi Mark,

sorry but all you state can be solved with the solution I exposed to you.
There's no need to add an identifier to an SDK since you can add it
yourself from the SDK you downloaded or get by the multiple ways available.
In any of the cases the numbers are not baked into code, but are available
in different parts and you can use defines to bake it into your code and
use it in the same way you use to do in Flex. At least I don't see from
your response that your points will not be covered in that way

Re: RE: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Josh Tynjala]

What if Royale had some kind of VersionBead that you could add to the main 
application? It could be optional with Basic, but maybe baked in by default 
with Express and other component sets that are less focused on small output 
size.

- Josh

On 2019/04/30 10:46:27, Kessler CTR Mark J  
wrote: 
> Lol, I can't seem to explain it properly.  Take maven/ant/config files out of 
> the equation it doesn't matter for this example.  This has to do with getting 
> some identifying information into the official SDK releases.  We don't want 
> to pass variables as an SDK user.  We want the official SDK to already come 
> packaged with a version number or a build number or a build date...
> 
> 
> Here's the scenario that I would love to see happen:
> 
> 1.  SDK user downloads official Royale SDK release and never modifies it.
> 
> 2.  SDK User compiles their app using official SDK and references an official 
> SDK property that contains the SDK identifier already built in it.  Meaning I 
> should be able to code complete off of the SDK and find something that 
> already exists and could return me an official identifier.
> 
> 
> -Mark K
> 
> -Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org] 
> Sent: Monday, April 29, 2019 1:14 PM
> To: dev@royale.apache.org
> Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale 
> version to 1.0)
> 
> ok,
> 
> we do the following in maven for other needs so this will be valid for you
> too:
> 
> in your maven properties.
> 
> 0.9.6-OR-WHATEVER
> 
> 
> org.apache.royale.compiler
> royale-maven-plugin
> true
> 
> ...
> 
> 
> BUILD::royaleVersion
> '"${royale.framework.version}"'
> 
> ...
> 
> ...
> 
> 
> defines can be done in ANT, asconfigc, config.xml
> 
> Then in AS3 or MXML
> 
> /**
> * ROYALE VERSION NUMBER
> */
> private static var _royaleVersion :String = BUILD::royaleVersion;
> 
> So now you can use in any place you want
> 
> HTH
> 
> Carlos
> 
> 

Re: extending IUIBase with interfaces (was: Re: Version property (was: Let's bump Royale version to 1.0))

[Carlos Rovira]

Hi Yishay,

El mar., 30 abr. 2019 a las 13:27, Yishay Weiss ()
escribió:

> It seems to me this is more an AS3 issue than a Royale issue. It would be
> cool to enhance AS to include features such as Mixins, but as long as we
> have a simple single inheritance model the solution you implemented is
> probably optimal.
>
>
If you and others think is the best we can get, maybe we can left as is.
Maybe we can just optimize as Andrew said making that a class to be
implemented by the rest of classes, in that way all share that and changing
just one class will change the 3 implementors at once...


> Also, in my opinion you should always check to see if a said object
> implements an interface, rather than extends a class. If you stick to that
> your solution works fine.
>
>
the problem with this is what I stated before. I expect users to use
UIBase/StyledUIBase classes instead or interface in this class of context.
And the problem in this case is that we can't generalize a code since not
all components will be "StyledUIBase". For me this is the most serious
problem

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

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Carlos Rovira]

Hi Mark,

sorry but all you state can be solved with the solution I exposed to you.
There's no need to add an identifier to an SDK since you can add it
yourself from the SDK you downloaded or get by the multiple ways available.
In any of the cases the numbers are not baked into code, but are available
in different parts and you can use defines to bake it into your code and
use it in the same way you use to do in Flex. At least I don't see from
your response that your points will not be covered in that way




El mar., 30 abr. 2019 a las 12:46, Kessler CTR Mark J
() escribió:

> Lol, I can't seem to explain it properly.  Take maven/ant/config files out
> of the equation it doesn't matter for this example.  This has to do with
> getting some identifying information into the official SDK releases.  We
> don't want to pass variables as an SDK user.  We want the official SDK to
> already come packaged with a version number or a build number or a build
> date...
>
>
> Here's the scenario that I would love to see happen:
>
> 1.  SDK user downloads official Royale SDK release and never modifies it.
>
> 2.  SDK User compiles their app using official SDK and references an
> official SDK property that contains the SDK identifier already built in
> it.  Meaning I should be able to code complete off of the SDK and find
> something that already exists and could return me an official identifier.
>
>
> -Mark K
>
> -Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> Sent: Monday, April 29, 2019 1:14 PM
> To: dev@royale.apache.org
> Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale
> version to 1.0)
>
> ok,
>
> we do the following in maven for other needs so this will be valid for you
> too:
>
> in your maven properties.
>
> 0.9.6-OR-WHATEVER
>
> 
> org.apache.royale.compiler
> royale-maven-plugin
> true
> 
> ...
> 
> 
> BUILD::royaleVersion
> '"${royale.framework.version}"'
> 
> ...
> 
> ...
>
>
> defines can be done in ANT, asconfigc, config.xml
>
> Then in AS3 or MXML
>
> /**
> * ROYALE VERSION NUMBER
> */
> private static var _royaleVersion :String = BUILD::royaleVersion;
>
> So now you can use in any place you want
>
> HTH
>
> Carlos
>
>

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

RE: extending IUIBase with interfaces (was: Re: Version property (was: Let's bump Royale version to 1.0))

[Yishay Weiss]

It seems to me this is more an AS3 issue than a Royale issue. It would be cool 
to enhance AS to include features such as Mixins, but as long as we have a 
simple single inheritance model the solution you implemented is probably 
optimal.



I personally wouldn’t worry too much about code duplication of one liners in 
framework code. The average user isn’t going to care.



Also, in my opinion you should always check to see if a said object implements 
an interface, rather than extends a class. If you stick to that your solution 
works fine.




From: Carlos Rovira 
Sent: Tuesday, April 30, 2019 12:29:10 PM
To: dev@royale.apache.org
Subject: Re: extending IUIBase with interfaces (was: Re: Version property (was: 
Let's bump Royale version to 1.0))

Hi Andrew,

thanks for your thoughts. One of the main problems here that I didn't put
on my email is that you loose the opportunity to ask if the components is a
"StyledUIBase", since we are "bifurcating" the code when implement in Group
and DataContainerBase and others the interface IClassSelectorLitsSupport.
You can ask for "IClassSelectorLitsSupport", but you probably would want
just ask for StyledUIBase.

El mar., 30 abr. 2019 a las 8:14, Frost, Andrew ()
escribió:

> Hi Carlos
>
> Isn't this similar to the challenge that Adobe had with EventDispatcher?
> which I think is why there are two possibilities:
> a) derive from EventDispatcher
> b) implement IEventDispatcher
>
> In the second case, you have to create an instance of EventDispatcher
> within your class, and then you have to implement the IEventDispatcher
> functions with calls to the EventDispatcher object. So it's not
> zero-effort, but it's not too bad (and probably the best option you can get
> without multiple inheritance..). Yes there's repeated code, but it's
> limited to one line per function so is relatively easy to copy/paste.
>

This solution could save code duplication if method bodies are long. In
this case method bodies are similar, so I'm afraid will not apply here to
make a significant difference


>
> Not 100% sure if the same approach can be applied in the scenario you're
> talking about, but that might help perhaps..? So the functionality you want
> to repeat would go into a class ("ClassSelectorListSupportImpl"?) and you
> create one of these in each of the classes that derive from
> UIBase/Group/etc and implement IClassSelectorLitsSupport.
>

Yes, this could be similar to before and more elegant, but the problem is
the same I put before.


>
> Some alternatives perhaps:
> - I'm also wondering whether you could create a helper function that
> actually adjusted the class prototype and programmatically added the
> necessary functions to your classes... ?
> - the repeated functionality could be put into other .as files and just
> 'included' in the classes? I know, this is a major hack, but I've seen it
> done :-(
>
>
hehe, prefer not to go that way ;-)

What I want to expose here is that beads are a good composition way and
love it. But we still has a problem in cases like this.

Thinking on this and seeing how the overall picture is now, I think the
actual solution is not helping PAYG at all. Maybe we should see if we can
add IClassSelectorLitsSupport to UIBase and remove
IClassSelectorLitsSupport implementations (StyledUIBase and the rest).
We'll be saving code, and Basic components will have access to that API
that is tiny and seems finaly make sense to be in UIBase.

At least I see other frameworks out there have it's own "addClass",
"removeClass", etc... as part of it's core, since nowadays the use of CSS
selectors is crucial and people will needed always (and that's the key for
PAYG).

Thoughts?



>
> Hope it helps..
>
> thanks
>
>Andrew
>
>
>
> -Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> Sent: 29 April 2019 18:04
> To: dev@royale.apache.org
> Subject: [EXTERNAL] extending IUIBase with interfaces (was: Re: Version
> property (was: Let's bump Royale version to 1.0))
>
> Hi Alex,
>
> initial problem is: I want to add to all jewel components (that use to
> have UIBase as common class) a new interface and implement the methods. In
> concrete interface is: IClassSelectorListSupport
>
> So the expected result should be to make all Jewel components implement
> IClassSelectorListSupport, but to avoid repeat code in all classes we need
> a root for all the components.
>
> Perfect point would be UIBase, but we can't add at that point for PAYG
> reasons.
>
> Current solution in Jewel is to create StyledUIBase that is
>
> public class StyledUIBase extends UIBase implements
> IClassSelectorListSupport
>
> but this makes other classes like jewel Group that exte

RE: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Kessler CTR Mark J]

Lol, I can't seem to explain it properly.  Take maven/ant/config files out of 
the equation it doesn't matter for this example.  This has to do with getting 
some identifying information into the official SDK releases.  We don't want to 
pass variables as an SDK user.  We want the official SDK to already come 
packaged with a version number or a build number or a build date...


Here's the scenario that I would love to see happen:

1.  SDK user downloads official Royale SDK release and never modifies it.

2.  SDK User compiles their app using official SDK and references an official 
SDK property that contains the SDK identifier already built in it.  Meaning I 
should be able to code complete off of the SDK and find something that already 
exists and could return me an official identifier.


-Mark K

-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: Monday, April 29, 2019 1:14 PM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale version 
to 1.0)

ok,

we do the following in maven for other needs so this will be valid for you
too:

in your maven properties.

0.9.6-OR-WHATEVER


org.apache.royale.compiler
royale-maven-plugin
true

...


BUILD::royaleVersion
'"${royale.framework.version}"'

...

...


defines can be done in ANT, asconfigc, config.xml

Then in AS3 or MXML

/**
* ROYALE VERSION NUMBER
*/
private static var _royaleVersion :String = BUILD::royaleVersion;

So now you can use in any place you want

HTH

Carlos

Re: Let's bump Royale version to 1.0 -- submit your bid for assistance to the group by Friday May 3

[Carlos Rovira]

Hi Dany,

El mar., 30 abr. 2019 a las 5:55, Dany Dhondt ()
escribió:

> Hi Justin,
>
> As much as I would like to write an article on Royale vs. competitors, I
> can’t do so at this moment because I don’t have enough Royale knowledge
> yet. But there are things I could point at so that the Royale team can
> formulate answers.
> Here are some questions and ideas I have which could be addressed:
>
> 1. Royale blog
> On our site, there is a section called ‘blog’. Shouldn’t we rename that?
> To me, a blog is something of the past. ‘Examples’ or ‘Code snippets’ or
> something similar would be better.
>

I'm ok with this, but we must get the right word. Currently we use "blog"
for:

* announcements and notify releases
* articles
* examples (ala Peter Dehaan's flex blog examples style)

So "Examples" is not right to me since we are posting announcements, while
articles could be a more elaborated writing about some concept that could
have examples.

I'm ok to change it if others want if we found a label more generic and
modern



>
> 2. Faq
> We definitely need a faq. Common answers to basic questions can go there.
> Also, when our StackOverflow database gets rolling, we can put links to our
> faq there.
>

Yeah! I thought on this too. This could be a good point to work on. There's
already a page (link on footer), with some points a put when created the
page.
Making a good FAQ page would be great. And there's many things and sections
we can add to it. This maybe could be a good point for you to start if you
want


>
> 3. (Re)rendering
> One of the core principles of React is that it uses a virtual dom. You
> never write to the dom directly. React does that for you. That’s why JQuery
> doesn’t match at all with React. The main advantage of this, is that only
> those DOM nodes get updated which actually change, making React really
> fast. How does Royale tackle this? Can someone explain this in an easy to
> understand way?
>

I think Harbs explained this, but maybe we should have a more compressive
data about this. Maybe if Harbs is very busy right now Alex could give us a
paragraph or something about this.
For what I understand Royale is more fast than React, but don't have the
proper words or concepts ready to explain this in a more technical way.


> 4. Managing (global) state
> Updating a component in React is done by calling setState() and passing an
> object to that method. That’s all very well and simple in small projects.
> Passing state from parents to children is straightforward. You just pass
> in state as props to underlying components. The other way around though is
> hard, very hard. Handling global state is done by implementing 3rd party
> technologies like Redux, MobX or recently by implementing React hooks.
> I believe that Royale binding mechanisms could be superior to this. So the
> question here: how does Royale handles global sta
>

I think you refer here how to deal with global models in apps in opposite
to models of single components.
In flex we had frameworks like Swiz, Parsley and more.
In Royale PureMVC is already working, although for example I'm not using it
in out real app yet. But I think this is what you have right now to use as
today.

We plan to make a new library based on metadata to mimic the most important
functionality that we had in Swiz, I refer to [Dispatcher],
[EventDispatcher] and [Inject]
This is a requisite for our next real app iteration, but still can say when
will start to wok on that, only can say that hopefully will be soon and
will be donated to Apache Royale


>
> 5. Justin, at some point in your message, you talk about ‘command line
> nonsense’. I believe you’re right and wrong at the same time.
> Right because indeed, learning React is far more than learning one
> technology. You have to dig through npm, node, JSX, typescript (if you want
> strong typing), webpack/rollup, babel, … and in the end, most of us use
> create-react-app just to hide all those configurations. BUT
> Wrong because there is a massive open source community where you can find
> almost anything you might need in your project. Building a modern web app
> is all about combining existing code to create your application.
> That brings me to this question: is it possible to embed existing pure
> javascript components into Royale?
>

yes! I think I need to make soon a blog example about this. For example in
Tour de Jewel, the code coloring is done by another JS script calling its
methods. Other way is wrapping in Royale classes like we did with Material
Design Lite (MDL UI set). I think there's more with typedefs, but I need to
learn more from this. I'll ask Alex/Harbs to explain more about this.


> An example: one of the most crucial components in any admin application is
> a calendar. In my Flex days, I had to spend hundreds of dollars to get a
> decent calendar component. In React, I use fullcalendar which is a great
> calendar/sheduling javascript component. Creating a calendar component from
> 

Re: extending IUIBase with interfaces (was: Re: Version property (was: Let's bump Royale version to 1.0))

[Carlos Rovira]

Hi Andrew,

thanks for your thoughts. One of the main problems here that I didn't put
on my email is that you loose the opportunity to ask if the components is a
"StyledUIBase", since we are "bifurcating" the code when implement in Group
and DataContainerBase and others the interface IClassSelectorLitsSupport.
You can ask for "IClassSelectorLitsSupport", but you probably would want
just ask for StyledUIBase.

El mar., 30 abr. 2019 a las 8:14, Frost, Andrew ()
escribió:

> Hi Carlos
>
> Isn't this similar to the challenge that Adobe had with EventDispatcher?
> which I think is why there are two possibilities:
> a) derive from EventDispatcher
> b) implement IEventDispatcher
>
> In the second case, you have to create an instance of EventDispatcher
> within your class, and then you have to implement the IEventDispatcher
> functions with calls to the EventDispatcher object. So it's not
> zero-effort, but it's not too bad (and probably the best option you can get
> without multiple inheritance..). Yes there's repeated code, but it's
> limited to one line per function so is relatively easy to copy/paste.
>

This solution could save code duplication if method bodies are long. In
this case method bodies are similar, so I'm afraid will not apply here to
make a significant difference


>
> Not 100% sure if the same approach can be applied in the scenario you're
> talking about, but that might help perhaps..? So the functionality you want
> to repeat would go into a class ("ClassSelectorListSupportImpl"?) and you
> create one of these in each of the classes that derive from
> UIBase/Group/etc and implement IClassSelectorLitsSupport.
>

Yes, this could be similar to before and more elegant, but the problem is
the same I put before.


>
> Some alternatives perhaps:
> - I'm also wondering whether you could create a helper function that
> actually adjusted the class prototype and programmatically added the
> necessary functions to your classes... ?
> - the repeated functionality could be put into other .as files and just
> 'included' in the classes? I know, this is a major hack, but I've seen it
> done :-(
>
>
hehe, prefer not to go that way ;-)

What I want to expose here is that beads are a good composition way and
love it. But we still has a problem in cases like this.

Thinking on this and seeing how the overall picture is now, I think the
actual solution is not helping PAYG at all. Maybe we should see if we can
add IClassSelectorLitsSupport to UIBase and remove
IClassSelectorLitsSupport implementations (StyledUIBase and the rest).
We'll be saving code, and Basic components will have access to that API
that is tiny and seems finaly make sense to be in UIBase.

At least I see other frameworks out there have it's own "addClass",
"removeClass", etc... as part of it's core, since nowadays the use of CSS
selectors is crucial and people will needed always (and that's the key for
PAYG).

Thoughts?



>
> Hope it helps..
>
> thanks
>
>Andrew
>
>
>
> -Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> Sent: 29 April 2019 18:04
> To: dev@royale.apache.org
> Subject: [EXTERNAL] extending IUIBase with interfaces (was: Re: Version
> property (was: Let's bump Royale version to 1.0))
>
> Hi Alex,
>
> initial problem is: I want to add to all jewel components (that use to
> have UIBase as common class) a new interface and implement the methods. In
> concrete interface is: IClassSelectorListSupport
>
> So the expected result should be to make all Jewel components implement
> IClassSelectorListSupport, but to avoid repeat code in all classes we need
> a root for all the components.
>
> Perfect point would be UIBase, but we can't add at that point for PAYG
> reasons.
>
> Current solution in Jewel is to create StyledUIBase that is
>
> public class StyledUIBase extends UIBase implements
> IClassSelectorListSupport
>
> but this makes other classes like jewel Group that extend html Group have
> UIBase in the hierarchical chain instead StyledUIBase, so we need to make
> Group as this:
>
> public class Group extends org.apache.royale.html.Group implements
> IClassSelectorListSupport
>
> same for
>
> public class DataContainerBase extends
> org.apache.royale.core.DataContainerBase implements
> IClassSelectorListSupport
>
> This make we have 3 classes that are duplicating the same exact code
> implementing in the same maner addClass, removeClass, etc..
>
> what can we do for this cases?
>
> Hope is more clear now,
>
> thanks
>
>
>
> El lun., 29 abr. 2019 a las 17:41, Alex Harui ()
> escribió:
>
> >
> > @Carlos, I couldn't understand your scenario.  Feel free to start

Let's bump Royale version to 1.0

[Piotr Zarzycki]

Hi Guys,

Thank you so far for a great discussion. I see that there is an obvious
needs to improve documentation the most.

I would like to express my personal feelings regarding releasing anything
what is not 1.0 after 0.9.6. Based on my experience with this project I
don't believe that releasing 0.9.7, 0.9.8 till 1.0 etc. will take less than
6-8 months form now on. Even if we will have automatic release process I
cannot believe that is going to happen in a less time than I mention.

Why I'm thinking like that:
- Justin just provided to the contributors generous offer - it's been
couple of days and there is absolutely no response.
- I've seen as part of the responses some concrete issues towards code in
SDK. I don't believe that there will be anyone who fix them UNLESS someone
need that stuff in his application which has been under development in his
daily job. Which leads me to conclusion that we will wait months before
anything from that list will be fixed.

How Royale is going on right now?
In my original email I expressed that it is enough good to bump it to 1.0 -
which gets us more credibility and push us to a better light. I got clear
responses from community that the only thing which is in the way of to 1.0
is documentation.

W have one production app in Royale, another one has been created by
Carlos. I'm working on the third one. Justin mention fourth one which I'm
reviewing right now because it is written in Flex - it looks there won't be
problem with porting to Royale. To me it is enough proof that Royale is as
good as is to expose itself for more wider audience. Because this is
exactly what will happen when we bump to that magic 1.0.
People on this project are talking about community, my proposition to bump
Royale to 1.0 is towards community with hope that it helps grow thanks to
that step. With hope that finally I will see on the list more people, with
hope that I will see someone who doesn't have background in ActionScript,
but was curious about the project.

In this thread I don't see rejection to my idea, so I'm going to work to
improve some areas and start release with bumped version to 1.0, whether it
will be after 0.9.7, 0.9.8 it doesn't matter - What's really matter is that
we are not facing in current version any walls during development, so this
is enough to me giving that framework 1.0.

Thanks,
Piotr

pon., 29 kwi 2019 o 19:44 Carlos Rovira 
napisał(a):

> Hi Justin,
>
> great initiative, but some thoughts:
>
> 1.- As Olaf said, Alex or I are just two more devs, so we can say what
> should we do. That's the apache way! :), only work towards the goal and
> giving advice to make things happen. We decisions are community managed
>
> 2.- I think is very generous offer so people can contribute and earn some
> money and a great plan,
>
> Some things you should take into account for the rewarding plan:
>
> * We just get results of the poll about releasing published few minutes
> ago. Seems people wants to focus docs first and release second (from 61
> votes).
> * In the other hand, I see Alex is still fighting with the release process.
> He stated that probably this week he will have the process ready to be
> tested by someone.
> If he get to that point that will be awesome, and hope others could be the
> first one in try to "push the button". If that works ok, we'll have a 0.9.6
> release (I think the one by Alex), and then a 0.9.7 (by that new release
> manager). At that point, I figure we can plan 0.9.8, 0.9.9 and Finlay 1.0.
> For me release should happen at least from month to month. have sense?
>
> Just my my thoughts, but hope other want to share here what they can do and
> work to earn some money too! :)
>
>
>
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
> >
> >
> >
>


-- 

Piotr Zarzycki

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

RE: extending IUIBase with interfaces (was: Re: Version property (was: Let's bump Royale version to 1.0))

[Frost, Andrew]

Hi Carlos

Isn't this similar to the challenge that Adobe had with EventDispatcher? which 
I think is why there are two possibilities:
a) derive from EventDispatcher
b) implement IEventDispatcher

In the second case, you have to create an instance of EventDispatcher within 
your class, and then you have to implement the IEventDispatcher functions with 
calls to the EventDispatcher object. So it's not zero-effort, but it's not too 
bad (and probably the best option you can get without multiple inheritance..). 
Yes there's repeated code, but it's limited to one line per function so is 
relatively easy to copy/paste.

Not 100% sure if the same approach can be applied in the scenario you're 
talking about, but that might help perhaps..? So the functionality you want to 
repeat would go into a class ("ClassSelectorListSupportImpl"?) and you create 
one of these in each of the classes that derive from UIBase/Group/etc and 
implement IClassSelectorLitsSupport.

Some alternatives perhaps:
- I'm also wondering whether you could create a helper function that actually 
adjusted the class prototype and programmatically added the necessary functions 
to your classes... ?
- the repeated functionality could be put into other .as files and just 
'included' in the classes? I know, this is a major hack, but I've seen it done 
:-(


Hope it helps..

thanks

   Andrew



-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: 29 April 2019 18:04
To: dev@royale.apache.org
Subject: [EXTERNAL] extending IUIBase with interfaces (was: Re: Version 
property (was: Let's bump Royale version to 1.0))

Hi Alex,

initial problem is: I want to add to all jewel components (that use to have 
UIBase as common class) a new interface and implement the methods. In concrete 
interface is: IClassSelectorListSupport

So the expected result should be to make all Jewel components implement 
IClassSelectorListSupport, but to avoid repeat code in all classes we need a 
root for all the components.

Perfect point would be UIBase, but we can't add at that point for PAYG reasons.

Current solution in Jewel is to create StyledUIBase that is

public class StyledUIBase extends UIBase implements IClassSelectorListSupport

but this makes other classes like jewel Group that extend html Group have 
UIBase in the hierarchical chain instead StyledUIBase, so we need to make Group 
as this:

public class Group extends org.apache.royale.html.Group implements 
IClassSelectorListSupport

same for

public class DataContainerBase extends
org.apache.royale.core.DataContainerBase implements IClassSelectorListSupport

This make we have 3 classes that are duplicating the same exact code 
implementing in the same maner addClass, removeClass, etc..

what can we do for this cases?

Hope is more clear now,

thanks



El lun., 29 abr. 2019 a las 17:41, Alex Harui ()
escribió:

>
> @Carlos, I couldn't understand your scenario.  Feel free to start a 
> separate thread on it.  The key aspect, as a guess, is trying to avoid 
> code that assumes that an instance is a subclass of a particular base 
> class instead of an implementation of an interface.
>
> HTH,
> -Alex
>
> On 4/29/19, 7:29 AM, "Carlos Rovira"  wrote:
>
> @Mark, if you use Maven, then artifacts in the poms are all what 
> you need,
> so maven takes care of pulling all right dependencies you need.
>
> @Alex, about extending IUIBase, my own experience is that beads 
> are a very
> good way to extend/compose more code you need, but extending core
> interfaces like the one you said is not the case. Let me put you an
> example: For Jewel I use "StyledUIBase" that extends "UIBase" to add
> IClassSelectorListSupport, the css CRUD API (addClass, 
> removeClass,
> etc..):
>
> public class StyledUIBase extends UIBase implements
> IClassSelectorListSupport
>
> This makes that some components are easy to extend but others need 
> to be
> recreate. There are lots of cases in Jewel where I need to
>
> If you search in Jewel for implements IClassSelectorListSupport
>  you'll find Jewel Group, Jewel DataContainerBase and Jewel Table, are
> implementing that class while, so they are not StyledUIBase in 
> it's core
> are standard UIBase and at its level we implement the interface and add
> again all methods repeating the code. So we are duplicating that 
> code all
> that times.
>
> I think this is one of the few things I don't like in Jewel, If 
> you know
> some way to do this in a better way, I can change it
>
> thanks
>
> --
Carlos Rovira
https://clicktime.symantec.com/37RX7Zfo3fgsrnBKZDX18bM7Vc?u=http%3A%2F%2Fabout.me%2Fcarlosrovira

Re: Let's bump Royale version to 1.0 -- submit your bid for assistance to the group by Friday May 3

[Dany Dhondt]

los specifically need to be convinced to push 
> to 1.0 release
> 
> THEN
> 
> Please submit to this public group your commitment and cost.
> 
> We will then do this democratically:  
> deadline for bid submissions is 7 days from now -- Friday May 3.
> Carlos (or someone who knows Twitter enough to create another poll) will then 
> do another Twitter vote poll for 3 days to decide who gets the bids
> 
> 
> 
> Ideally multiple people will commit to doing something "small" for $500 each 
> and we can award 5 people the projects.
> 
> The $2,500 USD total will be paid via PayPal.  No exceptions.
> 
> 
> IF within 30 days Apache Royale 1.0 is released to the public then the 
> Moonshine IDE team will again donate $2,500 for the month of June in an 
> identical voting scenario (assuming this one works well) to bring home a 1.1 
> release.
> 
> 
> By 60 days from now, a new user who has never seen Royale before or 
> programmed in ActionScript should be able to:
> 1) Arrive at the Apache Royale web page
> 
> 2) Understand from the home page why they should care about the project if 
> they come from React, Vue, Angular, Flex, or ActionScript worlds
> 
> 3) Be able to within 5 mouse clicks (download button, install button, launch 
> button, build button, run button) go from having nothing on their machine to 
> having an IDE (we of course volunteer Moonshine but Visual Studio Code should 
> be a goal for this, too) on their machine with a successful build of their 
> first "hello world".  No command line nonsense.  No learning NPM, Git, 
> downloading 20 required packages.   See Royale website.  Want to try it.  5 
> clicks later build your Hello World.
> 
> If the above 3 goals are met, then the Moonshine IDE team will run a 3rd 
> donation round of $2,500 for the month of July in a manner to the description 
> above to bring home a 1.2 release, to be published no later than the end of 
> July 2019 for the awards to be paid.
> 
> 
> Hopefully this helps motivate the team.
> 
> Thank you,
> 
> Justin Hill
> 
> 
> 
> 
> dev-digest-help---04/26/2019 11:04:17 PM---dev Digest 27 Apr 2019 04:04:13 
> - Issue 1966 Topics (messages 9894 through 9902)
> 
> From: dev-digest-h...@royale.apache.org
> To:   dev@royale.apache.org
> Date: 04/26/2019 11:04 PM
> Subject:  [External] dev Digest 27 Apr 2019 04:04:13 - Issue 1966 - 
> Dany replies about React, Vue, Angular
> 
> 
> 
> 
> dev Digest 27 Apr 2019 04:04:13 - Issue 1966
> 
> Topics (messages 9894 through 9902)
> 
> Re: Let's bump Royale version to 1.0
> 9894 by: Dany Dhondt
> 9896 by: Carlos Rovira
> 
> Re: Version property (was: Let's bump Royale version to 1.0)
> 9895 by: Alex Harui
> 
> Release Step 001 Succeeded
> 9897 by: Apache Royale CI Server
> 
> Release Step 001a Succeeded
> 9898 by: Apache Royale CI Server
> 
> Release Step 002 Succeeded
> 9899 by: Apache Royale CI Server
> 
> Release Step 002a Succeeded
> 9900 by: Apache Royale CI Server
> 
> Release Step 003 Succeeded
> 9901 by: Apache Royale CI Server
> 
> Build failed in Jenkins: royale-asjs_MXTests #722
> 9902 by: Apache Royale CI Server
> 
> Administrivia:
> 
> ---------
> To post to the list, e-mail: dev@royale.apache.org
> To unsubscribe, e-mail: dev-digest-unsubscr...@royale.apache.org
> For additional commands, e-mail: dev-digest-h...@royale.apache.org
> 
> --
> 
> 
> - Message from Dany Dhondt  on Fri, 26 Apr 
> 2019 16:06:59 +0200 -
> To:
> dev@royale.apache.org
> Subject:
> Re: Let's bump Royale version to 1.0
> I’m all for buikding a knowledge base in Stack Overflow! The mailing list 
> should only be used for developing Royale. Questions about using Royale 
> should go to SO
> 
> The competitors of Royale are React, Vue, Angular, ...
> Lots of developers are now used to those workflows. 
> In case of React, create-react-app sets you up with a brand new, ready to go 
> project in less than 30 seconds. That should be a benchmark for Royale imo. 
> 
> Dany
> 
> 
> Verstuurd vanaf mijn iPhone
> 
> > Op 26 apr. 2019 om 12:42 heeft Frost, Andrew  het 
> > volgende geschreven:
> > 
> > One other thought ... currently the way people ask for support is via these 
> > mailing lists. Which are okay but I'm always conscious that I'm potentially 
> > spamming people, plus the volume of mails is such that I have a rule to 
> > push all these into a folder that I then review every day or two..
> > 
> > But if I w

Re: Let's bump Royale version to 1.0 -- submit your bid for assistance to the group by Friday May 3

[Justin M. Hill]

To clarify -- anyone on the Moonshine IDE team will recuse ourselves from
voting on which bids to proceed with.

Again, the intent is for this to be a group decision to try to add some
extra work hours to bring home a 1.0 release ASAP so people can start using
this great technology in production, have tutorials, and documentation that
helps them understand Royale and why it should matter to them.

Thank you,

Justin Hill

Re: Let's bump Royale version to 1.0 -- submit your bid for assistance to the group by Friday May 3

[Justin M. Hill]

Hi Carlos and Olaf,

To clarify: the offer extends to everyone:  Alex, Carlos, everyone here.

Everyone can submit bids.   The group will vote on who to pay.  I have no
idea if this will work to inspire / motivate / organize, but it is worth a
shot.

Everyone's time is valuable, and balancing unpaid work on open source
projects with client driven (paid) work is naturally a challenge.   The
idea is to allow financially for more focus to be on getting Royale 1.0
completed within a month.

People can submit bids from $1.00 to $2,500.00.  As a group we can choose
multiple bids or a single bid.   We will do whatever the group votes on
with the budget I presented.


The Moonshine-IDE.com team would do more if we could.   From a code
contribution perspective, we are working diligently on releases every 2
weeks or so.

I understand the Apache way is similar to a potluck dinner, and everyone
brings what they can.  We are bringing an IDE focused on fast on-boarding
for new users for Royale.

The next release will hopefully include Carlos' suggestion to have a
non-sandbox Mac version, in addition to the one available in the Mac App
Store / iTunes.  This will help power users who want to make use of
existing software they have downloaded instead of using our "get your
environment setup in one click" helper app.  There will be other features
too, especially related to GitHub and making it easy to bring example
Royale projects into the IDE which are posted to GitHub.



I understand more documentation was the vote from the Twitter pole.  We
agree and have been working on the tutorial aspect.   Specifically:  two
weeks ago Piotr recruited a video tutorial specialist.  He is going to be
working on some of the goals with Piotr.  However, he does not know Royale,
so he will be learning it.  This is actually great, because it will help
Piotr to explain it to someone, who in turn can explain it in a video to
everyone.


Also, we have given to Piotr a portion of one of our production Flex
applications which includes a login sequence and a basic contact details
management (edit your e-mail and phone number type app) to be used in a
tutorial potentially.

We can never have enough tutorials, though!  I'd love to see a lot more
people working on tutorials.


ASDocs and finalizing the API of key things like the Jewel Data Grid, along
with the build process automation, are all critical items.   I fully agree.


My hope, now that the group has reached consensus on what 1.0 will take, is
that we can get very specific milestones defined in GitHub:
https://github.com/apache/royale-asjs/milestones


For example, exactly what do we need to have fixed with the build process
automation?

Which specific sections of the documentation need to be improved?

Having specific issues for these items will make it crystal clear what the
group must complete before 1.0 is considered done.


If the group decides we need a build specialist from outside the Royale
community group, then we can try to get help on UpWork.  We would rather
keep the funding in the direct community since so many of you have worked
so hard unpaid on this project for so long.   Still, whatever the group
decides is needed, lets figure out how to get it pipe lined into existence
in the next 30 days.

Thank you,

Justin Hill



- Message from Olaf Krueger  on Sun, 28 Apr 2019
23:20:03 -0700 (MST) -
   
  To: dev@royale.apache.org
   
 Subject: Re: Let's bump Royale version to 1.0 -- submit your bid for 
assistance to
  the group by Friday May 3
   

Hi Justin,
thanks for your amazing offer!

> ...what Alex and Carlos want to see happen...

Before others will do this I would just like to mention that no individuals
make decisions here at Apache. It's always the community! ;-)

However, I am curious about the feedback!

Thanks,
Olaf


- Message from Carlos Rovira  on Mon, 29 Apr
2019 19:44:32 +0200 -
   
  To: dev@royale.apache.org
   
 Subject: Re: Let's bump Royale version to 1.0 -- submit your bid for 
assistance to
  the group by Friday May 3
   

Hi Justin,

great initiative, but some thoughts:

1.- As Olaf said, Alex or I are just two more devs, so we can say what
should we do. That's the apache way! :), only work towards the goal and
giving advice to make things happen. We decisions are community managed

2.- I think is very generous offer so people can contribute and ea

Re: Let's bump Royale version to 1.0 -- submit your bid for assistance to the group by Friday May 3

[Carlos Rovira]

Hi Justin,

great initiative, but some thoughts:

1.- As Olaf said, Alex or I are just two more devs, so we can say what
should we do. That's the apache way! :), only work towards the goal and
giving advice to make things happen. We decisions are community managed

2.- I think is very generous offer so people can contribute and earn some
money and a great plan,

Some things you should take into account for the rewarding plan:

* We just get results of the poll about releasing published few minutes
ago. Seems people wants to focus docs first and release second (from 61
votes).
* In the other hand, I see Alex is still fighting with the release process.
He stated that probably this week he will have the process ready to be
tested by someone.
If he get to that point that will be awesome, and hope others could be the
first one in try to "push the button". If that works ok, we'll have a 0.9.6
release (I think the one by Alex), and then a 0.9.7 (by that new release
manager). At that point, I figure we can plan 0.9.8, 0.9.9 and Finlay 1.0.
For me release should happen at least from month to month. have sense?

Just my my thoughts, but hope other want to share here what they can do and
work to earn some money too! :)



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

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

>> -Alex
> >>>>>>>>
> >>>>>>>> On 4/29/19, 7:32 AM, "Carlos Rovira" 
> >>> wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> about StackOverFlow, we already discussed to start creating
> >>> questions
> >>>>>>> in
> >>>>>>>> SOF, but finally nobody does. I think I should not create one and
> >>>>>>> respond
> >>>>>>>> myself right? it will be very sad to do in that way. So if someone
> >>>>>>> start to
> >>>>>>>> post questions in SOF, I promise to respond, at least if it's
> >>>>>>> something I
> >>>>>>>> can know how to respond. It could be things you already know, but
> >> we
> >>>>>>> must
> >>>>>>>> start in some way.
> >>>>>>>>
> >>>>>>>> SOF is crucial for us, I talked with customers that pointed me
> >> that
> >>>>>>> Apache
> >>>>>>>> Royale is not on SOF, so his devs can easily search problems
> >> there.
> >>>>>>> And
> >>>>>>>> this is the google for developers. If we are not there, Royale
> >> will
> >>>>>>> never
> >>>>>>>> succeed, So if you want Royale to succeed we all should put some
> >>>>>>> work, what
> >>>>>>>> we can, in SOF. @dany, if you want to start this effort we can
> >>> follow
> >>>>>>> you.
> >>>>>>>> Just let's know in a mail here so we can go to that link and
> >>> respond.
> >>>>>>> If
> >>>>>>>> you start that your work will be follow :)
> >>>>>>>>
> >>>>>>>> @Andrew, "Flex In a Week" is a very good idea too. I think we can
> >>>>>>> work on
> >>>>>>>> that, but again, we need some kind of plan. A team to work on
> >> that.
> >>>>>>> Things
> >>>>>>>> like that can't be create by only one man's work. Volunteers?
> >>>>>>>>
> >>>>>>>> @Om, I not use NPM but will try Royale CLI since we need something
> >>>>>>> really
> >>>>>>>> fast to compete with React or others, or people will never jump to
> >>>>> out
> >>>>>>>> wagon.
> >>>>>>>>
> >>>>>>>> thanks for all the thoughts! :)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> El lun., 29 abr. 2019 a las 9:17, OmPrakash Muppirala (<
> >>>>>>> bigosma...@gmail.com>)
> >>>>>>>> escribió:
> >>>>>>>>
> >>>>>>>>> On Fri, Apr 26, 2019 at 7:37 PM Dany Dhondt
> >>>>>  >>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I’m all for buikding a knowledge base in Stack Overflow! The
> >>> mailing
> >>>>>>> list
> >>>>>>>>>> should only be used for developing Royale. Questions about using
> >>>>> Royale
> >>>>>>>>>> should go to SO
> >>>>>>>>>>
> >>>>>>>>>> The competitors of Royale are React, Vue, Angular, ...
> >>>>>>>>>> Lots of developers are now used to those workflows.
> >>>>>>>>>> In case of React, create-react-app sets you up with a brand new,
> >>>>> ready
> >>>>>>> to
> >>>>>>>>>> go project in less than 30 seconds. That should be a benchmark
> >> for
> >>>>>>> Royale
> >>>>>>>>>> imo.
> >>>>>>>>>>
> >>>>>>>>>> Dany
> >>>>>>>>>>
> >>>>>>>>

Re: Version property (was: Let's bump Royale version to 1.0)

[Carlos Rovira]

ok,

we do the following in maven for other needs so this will be valid for you
too:

in your maven properties.

0.9.6-OR-WHATEVER


org.apache.royale.compiler
royale-maven-plugin
true

...


BUILD::royaleVersion
'"${royale.framework.version}"'

...

...


defines can be done in ANT, asconfigc, config.xml

Then in AS3 or MXML

/**
* ROYALE VERSION NUMBER
*/
private static var _royaleVersion :String = BUILD::royaleVersion;

So now you can use in any place you want

HTH

Carlos


El lun., 29 abr. 2019 a las 18:42, Kessler CTR Mark J
() escribió:

> Let me clarify.
>
> @Carlos,
>  It's not a dependency issue, it's a matter of finding out what the
> SDK version or build number of the SDK or any form of uniquely identifying
> information about the SDK in code.  So the apps we build using Flex we can
> just get the Flex version by referencing mx.core.FlexVersion in code.  Then
> in our application logs when an app starts up we can see the message
> "Compiled with SDK v4.16.0.".  So it allows us to more easily troubleshoot
> issues later.
>
> @Alex,
> Yes that would be great to have any important versions in there.  How
> about we just keep it  like a compile time constant / compiler "define"
> statement that has the version built it?
>
>
>
> -Mark K
>


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

extending IUIBase with interfaces (was: Re: Version property (was: Let's bump Royale version to 1.0))

[Carlos Rovira]

Hi Alex,

initial problem is: I want to add to all jewel components (that use to have
UIBase as common class) a new interface and implement the methods. In
concrete interface is: IClassSelectorListSupport

So the expected result should be to make all Jewel components implement
IClassSelectorListSupport, but to avoid repeat code in all classes we need
a root for all the components.

Perfect point would be UIBase, but we can't add at that point for PAYG
reasons.

Current solution in Jewel is to create StyledUIBase that is

public class StyledUIBase extends UIBase
implements IClassSelectorListSupport

but this makes other classes like jewel Group that extend html Group have
UIBase in the hierarchical chain instead StyledUIBase, so we need to make
Group as this:

public class Group extends org.apache.royale.html.Group implements
IClassSelectorListSupport

same for

public class DataContainerBase extends
org.apache.royale.core.DataContainerBase implements
IClassSelectorListSupport

This make we have 3 classes that are duplicating the same exact code
implementing in the same maner addClass, removeClass, etc..

what can we do for this cases?

Hope is more clear now,

thanks



El lun., 29 abr. 2019 a las 17:41, Alex Harui ()
escribió:

>
> @Carlos, I couldn't understand your scenario.  Feel free to start a
> separate thread on it.  The key aspect, as a guess, is trying to avoid code
> that assumes that an instance is a subclass of a particular base class
> instead of an implementation of an interface.
>
> HTH,
> -Alex
>
> On 4/29/19, 7:29 AM, "Carlos Rovira"  wrote:
>
> @Mark, if you use Maven, then artifacts in the poms are all what you
> need,
> so maven takes care of pulling all right dependencies you need.
>
> @Alex, about extending IUIBase, my own experience is that beads are a
> very
> good way to extend/compose more code you need, but extending core
> interfaces like the one you said is not the case. Let me put you an
> example: For Jewel I use "StyledUIBase" that extends "UIBase" to add
> IClassSelectorListSupport, the css CRUD API (addClass, removeClass,
> etc..):
>
> public class StyledUIBase extends UIBase implements
> IClassSelectorListSupport
>
> This makes that some components are easy to extend but others need to
> be
> recreate. There are lots of cases in Jewel where I need to
>
> If you search in Jewel for implements IClassSelectorListSupport
>  you'll find Jewel Group, Jewel DataContainerBase and Jewel Table, are
> implementing that class while, so they are not StyledUIBase in it's
> core
> are standard UIBase and at its level we implement the interface and add
> again all methods repeating the code. So we are duplicating that code
> all
> that times.
>
> I think this is one of the few things I don't like in Jewel, If you
> know
> some way to do this in a better way, I can change it
>
> thanks
>
> --
Carlos Rovira
http://about.me/carlosrovira

Re: Let's bump Royale version to 1.0

[Dany Dhondt]

>>>>>>>> post questions in SOF, I promise to respond, at least if it's
>>>>>>> something I
>>>>>>>> can know how to respond. It could be things you already know, but
>> we
>>>>>>> must
>>>>>>>> start in some way.
>>>>>>>> 
>>>>>>>> SOF is crucial for us, I talked with customers that pointed me
>> that
>>>>>>> Apache
>>>>>>>> Royale is not on SOF, so his devs can easily search problems
>> there.
>>>>>>> And
>>>>>>>> this is the google for developers. If we are not there, Royale
>> will
>>>>>>> never
>>>>>>>> succeed, So if you want Royale to succeed we all should put some
>>>>>>> work, what
>>>>>>>> we can, in SOF. @dany, if you want to start this effort we can
>>> follow
>>>>>>> you.
>>>>>>>> Just let's know in a mail here so we can go to that link and
>>> respond.
>>>>>>> If
>>>>>>>> you start that your work will be follow :)
>>>>>>>> 
>>>>>>>> @Andrew, "Flex In a Week" is a very good idea too. I think we can
>>>>>>> work on
>>>>>>>> that, but again, we need some kind of plan. A team to work on
>> that.
>>>>>>> Things
>>>>>>>> like that can't be create by only one man's work. Volunteers?
>>>>>>>> 
>>>>>>>> @Om, I not use NPM but will try Royale CLI since we need something
>>>>>>> really
>>>>>>>> fast to compete with React or others, or people will never jump to
>>>>> out
>>>>>>>> wagon.
>>>>>>>> 
>>>>>>>> thanks for all the thoughts! :)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> El lun., 29 abr. 2019 a las 9:17, OmPrakash Muppirala (<
>>>>>>> bigosma...@gmail.com>)
>>>>>>>> escribió:
>>>>>>>> 
>>>>>>>>> On Fri, Apr 26, 2019 at 7:37 PM Dany Dhondt
>>>>> >>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I’m all for buikding a knowledge base in Stack Overflow! The
>>> mailing
>>>>>>> list
>>>>>>>>>> should only be used for developing Royale. Questions about using
>>>>> Royale
>>>>>>>>>> should go to SO
>>>>>>>>>> 
>>>>>>>>>> The competitors of Royale are React, Vue, Angular, ...
>>>>>>>>>> Lots of developers are now used to those workflows.
>>>>>>>>>> In case of React, create-react-app sets you up with a brand new,
>>>>> ready
>>>>>>> to
>>>>>>>>>> go project in less than 30 seconds. That should be a benchmark
>> for
>>>>>>> Royale
>>>>>>>>>> imo.
>>>>>>>>>> 
>>>>>>>>>> Dany
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> The Royale CLI is modeled closely after the create-react-app.  The
>>>>> docs
>>>>>>> for
>>>>>>>>> the alpha version is available here:
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fnpm%2Fclidata=02%7C01%7Caharui%40adobe.com%7C950f12a2b0f24cad192508d6ccaf8241%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921451512477017sdata=4VN8JejglMeW08ZcNV6fCJ%2BdYJjOHcvfGDL099jives%3Dreserved=0
>>>>>>>>> If I get more feedback, I am keep improving this tool.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Om
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Verstuurd vanaf mijn iPhone
>>>>>>>&g

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

>>  we can, in SOF. @dany, if you want to start this effort we can
> > follow
> > >>>> you.
> > >>>>>  Just let's know in a mail here so we can go to that link and
> > respond.
> > >>>> If
> > >>>>>  you start that your work will be follow :)
> > >>>>>
> > >>>>>  @Andrew, "Flex In a Week" is a very good idea too. I think we can
> > >>>> work on
> > >>>>>  that, but again, we need some kind of plan. A team to work on
> that.
> > >>>> Things
> > >>>>>  like that can't be create by only one man's work. Volunteers?
> > >>>>>
> > >>>>>  @Om, I not use NPM but will try Royale CLI since we need something
> > >>>> really
> > >>>>>  fast to compete with React or others, or people will never jump to
> > >> out
> > >>>>>  wagon.
> > >>>>>
> > >>>>>  thanks for all the thoughts! :)
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>  El lun., 29 abr. 2019 a las 9:17, OmPrakash Muppirala (<
> > >>>> bigosma...@gmail.com>)
> > >>>>>  escribió:
> > >>>>>
> > >>>>>> On Fri, Apr 26, 2019 at 7:37 PM Dany Dhondt
> > >>  > >>>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> I’m all for buikding a knowledge base in Stack Overflow! The
> > mailing
> > >>>> list
> > >>>>>>> should only be used for developing Royale. Questions about using
> > >> Royale
> > >>>>>>> should go to SO
> > >>>>>>>
> > >>>>>>> The competitors of Royale are React, Vue, Angular, ...
> > >>>>>>> Lots of developers are now used to those workflows.
> > >>>>>>> In case of React, create-react-app sets you up with a brand new,
> > >> ready
> > >>>> to
> > >>>>>>> go project in less than 30 seconds. That should be a benchmark
> for
> > >>>> Royale
> > >>>>>>> imo.
> > >>>>>>>
> > >>>>>>> Dany
> > >>>>>>>
> > >>>>>>>
> > >>>>>> The Royale CLI is modeled closely after the create-react-app.  The
> > >> docs
> > >>>> for
> > >>>>>> the alpha version is available here:
> > >>>>>>
> > >>>>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fnpm%2Fclidata=02%7C01%7Caharui%40adobe.com%7C950f12a2b0f24cad192508d6ccaf8241%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921451512477017sdata=4VN8JejglMeW08ZcNV6fCJ%2BdYJjOHcvfGDL099jives%3Dreserved=0
> > >>>>>> If I get more feedback, I am keep improving this tool.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Om
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>> Verstuurd vanaf mijn iPhone
> > >>>>>>>
> > >>>>>>>> Op 26 apr. 2019 om 12:42 heeft Frost, Andrew <
> > >> andrew.fr...@harman.com
> > >>>>>
> > >>>>>>> het volgende geschreven:
> > >>>>>>>>
> > >>>>>>>> One other thought ... currently the way people ask for support
> is
> > >> via
> > >>>>>>> these mailing lists. Which are okay but I'm always conscious that
> > I'm
> > >>>>>>> potentially spamming people, plus the volume of mails is such
> that
> > I
> > >>>>>> have a
> > >>>>>>> rule to push all these into a folder that I then review every day
> > or
> > >>>>>> two..
> > >>>>>>>>
> > >>>>>>>> But if I want to find something out, I tend not to go search the
> > >>>>>> mailing
> > >>>>>>> list, I tend to search online. Looking t

Re: Version property (was: Let's bump Royale version to 1.0)

[Kessler CTR Mark J]

Let me clarify.

@Carlos,
 It's not a dependency issue, it's a matter of finding out what the SDK 
version or build number of the SDK or any form of uniquely identifying 
information about the SDK in code.  So the apps we build using Flex we can just 
get the Flex version by referencing mx.core.FlexVersion in code.  Then in our 
application logs when an app starts up we can see the message "Compiled with 
SDK v4.16.0.".  So it allows us to more easily troubleshoot issues later.

@Alex,
Yes that would be great to have any important versions in there.  How about 
we just keep it  like a compile time constant / compiler "define" statement 
that has the version built it?



-Mark K

Re: Let's bump Royale version to 1.0

[Piotr Zarzycki]

 jump to
> >> out
> >>>>>  wagon.
> >>>>>
> >>>>>  thanks for all the thoughts! :)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>  El lun., 29 abr. 2019 a las 9:17, OmPrakash Muppirala (<
> >>>> bigosma...@gmail.com>)
> >>>>>  escribió:
> >>>>>
> >>>>>> On Fri, Apr 26, 2019 at 7:37 PM Dany Dhondt
> >>  >>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I’m all for buikding a knowledge base in Stack Overflow! The
> mailing
> >>>> list
> >>>>>>> should only be used for developing Royale. Questions about using
> >> Royale
> >>>>>>> should go to SO
> >>>>>>>
> >>>>>>> The competitors of Royale are React, Vue, Angular, ...
> >>>>>>> Lots of developers are now used to those workflows.
> >>>>>>> In case of React, create-react-app sets you up with a brand new,
> >> ready
> >>>> to
> >>>>>>> go project in less than 30 seconds. That should be a benchmark for
> >>>> Royale
> >>>>>>> imo.
> >>>>>>>
> >>>>>>> Dany
> >>>>>>>
> >>>>>>>
> >>>>>> The Royale CLI is modeled closely after the create-react-app.  The
> >> docs
> >>>> for
> >>>>>> the alpha version is available here:
> >>>>>>
> >>>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fnpm%2Fclidata=02%7C01%7Caharui%40adobe.com%7C950f12a2b0f24cad192508d6ccaf8241%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921451512477017sdata=4VN8JejglMeW08ZcNV6fCJ%2BdYJjOHcvfGDL099jives%3Dreserved=0
> >>>>>> If I get more feedback, I am keep improving this tool.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Om
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Verstuurd vanaf mijn iPhone
> >>>>>>>
> >>>>>>>> Op 26 apr. 2019 om 12:42 heeft Frost, Andrew <
> >> andrew.fr...@harman.com
> >>>>>
> >>>>>>> het volgende geschreven:
> >>>>>>>>
> >>>>>>>> One other thought ... currently the way people ask for support is
> >> via
> >>>>>>> these mailing lists. Which are okay but I'm always conscious that
> I'm
> >>>>>>> potentially spamming people, plus the volume of mails is such that
> I
> >>>>>> have a
> >>>>>>> rule to push all these into a folder that I then review every day
> or
> >>>>>> two..
> >>>>>>>>
> >>>>>>>> But if I want to find something out, I tend not to go search the
> >>>>>> mailing
> >>>>>>> list, I tend to search online. Looking through mailing list threads
> >>>> isn't
> >>>>>>> the easiest (and search engines don't necessarily pick things up
> from
> >>>>>> them
> >>>>>>> very well) but a major source of support is Stack Overflow... I use
> >>>> this
> >>>>>> a
> >>>>>>> lot with my other work and there's a lot of information there.
> >>>>>>>>
> >>>>>>>> Apache Royale doesn't appear to have a tag; when I search for
> >> "royale"
> >>>>>>> all I got was stuff about "Clash Royale"; there are however 8
> >> questions
> >>>>>>> with "flexjs" tags.
> >>>>>>>>
> >>>>>>>> But wouldn't it be good for people to add questions and to
> >> contribute
> >>>>>>> answers there, both from the user perspective and perhaps also the
> >> dev
> >>>>>>> perspective? Would be interested in people's thoughts... (and
> perhaps
> >>>>>> I'll
> >>>>>>> have to dig out my SO credentials to start contributing there)
> >>>>>>>>
>

Re: Let's bump Royale version to 1.0

[Dany Dhondt]

ale
>>>>>>> should go to SO
>>>>>>> 
>>>>>>> The competitors of Royale are React, Vue, Angular, ...
>>>>>>> Lots of developers are now used to those workflows.
>>>>>>> In case of React, create-react-app sets you up with a brand new,
>> ready
>>>> to
>>>>>>> go project in less than 30 seconds. That should be a benchmark for
>>>> Royale
>>>>>>> imo.
>>>>>>> 
>>>>>>> Dany
>>>>>>> 
>>>>>>> 
>>>>>> The Royale CLI is modeled closely after the create-react-app.  The
>> docs
>>>> for
>>>>>> the alpha version is available here:
>>>>>> 
>>>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fnpm%2Fclidata=02%7C01%7Caharui%40adobe.com%7C950f12a2b0f24cad192508d6ccaf8241%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921451512477017sdata=4VN8JejglMeW08ZcNV6fCJ%2BdYJjOHcvfGDL099jives%3Dreserved=0
>>>>>> If I get more feedback, I am keep improving this tool.
>>>>>> 
>>>>>> Thanks,
>>>>>> Om
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Verstuurd vanaf mijn iPhone
>>>>>>> 
>>>>>>>> Op 26 apr. 2019 om 12:42 heeft Frost, Andrew <
>> andrew.fr...@harman.com
>>>>> 
>>>>>>> het volgende geschreven:
>>>>>>>> 
>>>>>>>> One other thought ... currently the way people ask for support is
>> via
>>>>>>> these mailing lists. Which are okay but I'm always conscious that I'm
>>>>>>> potentially spamming people, plus the volume of mails is such that I
>>>>>> have a
>>>>>>> rule to push all these into a folder that I then review every day or
>>>>>> two..
>>>>>>>> 
>>>>>>>> But if I want to find something out, I tend not to go search the
>>>>>> mailing
>>>>>>> list, I tend to search online. Looking through mailing list threads
>>>> isn't
>>>>>>> the easiest (and search engines don't necessarily pick things up from
>>>>>> them
>>>>>>> very well) but a major source of support is Stack Overflow... I use
>>>> this
>>>>>> a
>>>>>>> lot with my other work and there's a lot of information there.
>>>>>>>> 
>>>>>>>> Apache Royale doesn't appear to have a tag; when I search for
>> "royale"
>>>>>>> all I got was stuff about "Clash Royale"; there are however 8
>> questions
>>>>>>> with "flexjs" tags.
>>>>>>>> 
>>>>>>>> But wouldn't it be good for people to add questions and to
>> contribute
>>>>>>> answers there, both from the user perspective and perhaps also the
>> dev
>>>>>>> perspective? Would be interested in people's thoughts... (and perhaps
>>>>>> I'll
>>>>>>> have to dig out my SO credentials to start contributing there)
>>>>>>>> 
>>>>>>>> thanks
>>>>>>>> 
>>>>>>>> Andrew
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -Original Message-
>>>>>>>> From: Carlos Rovira [mailto:carlosrov...@apache.org]
>>>>>>>> Sent: 26 April 2019 10:39
>>>>>>>> To: dev@royale.apache.org
>>>>>>>> Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0
>>>>>>>> 
>>>>>>>> Hi Angelo, that's great! :)
>>>>>>>> 
>>>>>>>> any help here is very appreciated.
>>>>>>>> 
>>>>>>>> Share in a new mail a concrete contribution before starting to work
>> on
>>>>>>> it, so we can know about it and help you on the task so your work fit
>>>>>>> perfectly in the overall picture.
>>>>>>>> 
>>>>>>>> I'd like to create videos too, and people asked about it in facebook
>>>>>> and
>>>>>>> twitter. Do you have skills

Re: Let's bump Royale version to 1.0

[Piotr Zarzycki]

safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fnpm%2Fclidata=02%7C01%7Caharui%40adobe.com%7C950f12a2b0f24cad192508d6ccaf8241%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921451512477017sdata=4VN8JejglMeW08ZcNV6fCJ%2BdYJjOHcvfGDL099jives%3Dreserved=0
> >>>> If I get more feedback, I am keep improving this tool.
> >>>>
> >>>> Thanks,
> >>>> Om
> >>>>
> >>>>
> >>>>
> >>>>> Verstuurd vanaf mijn iPhone
> >>>>>
> >>>>>> Op 26 apr. 2019 om 12:42 heeft Frost, Andrew <
> andrew.fr...@harman.com
> >>>
> >>>>> het volgende geschreven:
> >>>>>>
> >>>>>> One other thought ... currently the way people ask for support is
> via
> >>>>> these mailing lists. Which are okay but I'm always conscious that I'm
> >>>>> potentially spamming people, plus the volume of mails is such that I
> >>>> have a
> >>>>> rule to push all these into a folder that I then review every day or
> >>>> two..
> >>>>>>
> >>>>>> But if I want to find something out, I tend not to go search the
> >>>> mailing
> >>>>> list, I tend to search online. Looking through mailing list threads
> >> isn't
> >>>>> the easiest (and search engines don't necessarily pick things up from
> >>>> them
> >>>>> very well) but a major source of support is Stack Overflow... I use
> >> this
> >>>> a
> >>>>> lot with my other work and there's a lot of information there.
> >>>>>>
> >>>>>> Apache Royale doesn't appear to have a tag; when I search for
> "royale"
> >>>>> all I got was stuff about "Clash Royale"; there are however 8
> questions
> >>>>> with "flexjs" tags.
> >>>>>>
> >>>>>> But wouldn't it be good for people to add questions and to
> contribute
> >>>>> answers there, both from the user perspective and perhaps also the
> dev
> >>>>> perspective? Would be interested in people's thoughts... (and perhaps
> >>>> I'll
> >>>>> have to dig out my SO credentials to start contributing there)
> >>>>>>
> >>>>>> thanks
> >>>>>>
> >>>>>> Andrew
> >>>>>>
> >>>>>>
> >>>>>> -Original Message-
> >>>>>> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> >>>>>> Sent: 26 April 2019 10:39
> >>>>>> To: dev@royale.apache.org
> >>>>>> Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0
> >>>>>>
> >>>>>> Hi Angelo, that's great! :)
> >>>>>>
> >>>>>> any help here is very appreciated.
> >>>>>>
> >>>>>> Share in a new mail a concrete contribution before starting to work
> on
> >>>>> it, so we can know about it and help you on the task so your work fit
> >>>>> perfectly in the overall picture.
> >>>>>>
> >>>>>> I'd like to create videos too, and people asked about it in facebook
> >>>> and
> >>>>> twitter. Do you have skills in creating videos?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari (<
> >>>>> lazzari.ang...@gmail.com>)
> >>>>>> escribió:
> >>>>>>
> >>>>>>> Yes, i can give some slots to help with documentation or example
> >>>>>>> project or so... I think tutorial videos could be help to
> understand
> >>>>>>> rapidly the platform and could help new user to get ready in a few
> >>>>>>> hours to start build their project.
> >>>>>>>
> >>>>>>> Angelo
> >>>>>>>
> >>>>>>> On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira
> >>>>>>> 
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Agree with latest comments.
> >>>>>>>>
> >>>

Re: Let's bump Royale version to 1.0

[Dany Dhondt]

Alex,

By commenting on questions, and when somebody upvotes your comment, you’ll earn 
points and at some point, you’ll get a badge permitting you to answer questions

Dany

> Op 29 apr. 2019, om 17:56 heeft Dany Dhondt  het 
> volgende geschreven:
> 
>> I agree we want to develop a presence on Stack Overflow.  I still can't 
>> figure out how to earn enough points be able to answer any questions so I 
>> won't be of much help until that happens.

Re: Version property (was: Let's bump Royale version to 1.0)

[Mark Thomas]

I have no idea why this has been sent to me personally. I assume some
form of addressing error.

Mark


On 29/04/2019 16:41, Alex Harui wrote:
> @Mark, I'm assuming you want something in the output that identifies the 
> actual versions used.  In Royale, you may also need to identify the version 
> of the transpiler as well, and maybe the version of Google Closure.  If you 
> want to propose (or better yet, implement) a PAYG way to do that in Royale, 
> please do so.  If other folks think this will be useful, please speak up so 
> we get a sense of how important it is.  A simple hack may be to embed the 
> pom.xml file in your output as a string if you are using Maven.  If you use 
> Ant, you could grab the SDK version from build.properties or embed the 
> flex-sdk-description.xml file.
> 
> @Carlos, I couldn't understand your scenario.  Feel free to start a separate 
> thread on it.  The key aspect, as a guess, is trying to avoid code that 
> assumes that an instance is a subclass of a particular base class instead of 
> an implementation of an interface.
> 
> HTH,
> -Alex
> 
> On 4/29/19, 7:29 AM, "Carlos Rovira"  wrote:
> 
> @Mark, if you use Maven, then artifacts in the poms are all what you need,
> so maven takes care of pulling all right dependencies you need.
> 
> @Alex, about extending IUIBase, my own experience is that beads are a very
> good way to extend/compose more code you need, but extending core
> interfaces like the one you said is not the case. Let me put you an
> example: For Jewel I use "StyledUIBase" that extends "UIBase" to add
> IClassSelectorListSupport, the css CRUD API (addClass, removeClass, 
> etc..):
> 
> public class StyledUIBase extends UIBase implements
> IClassSelectorListSupport
> 
> This makes that some components are easy to extend but others need to be
> recreate. There are lots of cases in Jewel where I need to
> 
> If you search in Jewel for implements IClassSelectorListSupport
>  you'll find Jewel Group, Jewel DataContainerBase and Jewel Table, are
> implementing that class while, so they are not StyledUIBase in it's core
> are standard UIBase and at its level we implement the interface and add
> again all methods repeating the code. So we are duplicating that code all
> that times.
> 
> I think this is one of the few things I don't like in Jewel, If you know
> some way to do this in a better way, I can change it
> 
> thanks
> 
> 
> 
> 
> 
> El lun., 29 abr. 2019 a las 12:36, Kessler CTR Mark J
> () escribió:
> 
> >  Yeah just concerned with an official build number, or date, or
> > something with numbers we can use to identify a production app back to 
> what
> > SDK was used to compile it.  Imagine having an app released on 
> production
> > and a user reports a problem. We would need to reproduce the problem in 
> a
> > test environment.  This would include using the same SDK to compile the
> > app.  Currently in Flex, we can just access its version directly which
> > makes things faster.
> >
> > If the SDK doesn't have anything like this at the moment and we did
> > add that functionality in there, I would say let's just use a date field
> > since it could be automated.  Something like MMDD type format.
> >
> >
> > -Mark K
> >
> >
> > -Original Message-
> > From: Alex Harui [mailto:aha...@adobe.com.INVALID]
> > Sent: Friday, April 26, 2019 12:02 PM
> > To: dev@royale.apache.org
> > Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale
> > version to 1.0)
> >
> >
> >
> > On 4/26/19, 4:29 AM, "Kessler CTR Mark J" 
> 
> > wrote:
> >
> > > So far, we have not had the release scripts properly generate the
> > right version number for the NPM artifacts.
> >
> >
> > This spurred a question for me.  Is there a way to find out what
> > version number the SDK binaries are in code for Royale?  Sort of like 
> the
> > Flex SDK mx.core.FlexVersion or at least a build date?
> >
> > Not at this time.  IMO, runtime versioning wasn't worth the cost of all 
> of
> > those strings and code in the production app.  Also, Royale was designed
> > from the beginning to try to be "version-agnostic".  By using
> > loose-coupling via Beads/PAYG/ValuesManager and lots of interfaces 
>

Re: Let's bump Royale version to 1.0

[Dany Dhondt]

ple ask for support is via
>>>>> these mailing lists. Which are okay but I'm always conscious that I'm
>>>>> potentially spamming people, plus the volume of mails is such that I
>>>> have a
>>>>> rule to push all these into a folder that I then review every day or
>>>> two..
>>>>>> 
>>>>>> But if I want to find something out, I tend not to go search the
>>>> mailing
>>>>> list, I tend to search online. Looking through mailing list threads
>> isn't
>>>>> the easiest (and search engines don't necessarily pick things up from
>>>> them
>>>>> very well) but a major source of support is Stack Overflow... I use
>> this
>>>> a
>>>>> lot with my other work and there's a lot of information there.
>>>>>> 
>>>>>> Apache Royale doesn't appear to have a tag; when I search for "royale"
>>>>> all I got was stuff about "Clash Royale"; there are however 8 questions
>>>>> with "flexjs" tags.
>>>>>> 
>>>>>> But wouldn't it be good for people to add questions and to contribute
>>>>> answers there, both from the user perspective and perhaps also the dev
>>>>> perspective? Would be interested in people's thoughts... (and perhaps
>>>> I'll
>>>>> have to dig out my SO credentials to start contributing there)
>>>>>> 
>>>>>> thanks
>>>>>> 
>>>>>> Andrew
>>>>>> 
>>>>>> 
>>>>>> -Original Message-
>>>>>> From: Carlos Rovira [mailto:carlosrov...@apache.org]
>>>>>> Sent: 26 April 2019 10:39
>>>>>> To: dev@royale.apache.org
>>>>>> Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0
>>>>>> 
>>>>>> Hi Angelo, that's great! :)
>>>>>> 
>>>>>> any help here is very appreciated.
>>>>>> 
>>>>>> Share in a new mail a concrete contribution before starting to work on
>>>>> it, so we can know about it and help you on the task so your work fit
>>>>> perfectly in the overall picture.
>>>>>> 
>>>>>> I'd like to create videos too, and people asked about it in facebook
>>>> and
>>>>> twitter. Do you have skills in creating videos?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari (<
>>>>> lazzari.ang...@gmail.com>)
>>>>>> escribió:
>>>>>> 
>>>>>>> Yes, i can give some slots to help with documentation or example
>>>>>>> project or so... I think tutorial videos could be help to understand
>>>>>>> rapidly the platform and could help new user to get ready in a few
>>>>>>> hours to start build their project.
>>>>>>> 
>>>>>>> Angelo
>>>>>>> 
>>>>>>> On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira
>>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Agree with latest comments.
>>>>>>>> 
>>>>>>>> I think we should work in docs and ease the start of new users to
>>>>>>>> target
>>>>>>>> 1.0
>>>>>>>> And in the process fix some few things (i.e: don't want to reach 1.0
>>>>>>>> with Jewel Table in its current state and API)
>>>>>>>> 
>>>>>>>> What do you think?
>>>>>>>> 
>>>>>>>> If you all agree could you think on how to contribute to that
>>>>>>>> effort? Can we have as a near goal to bring 1.0 planing ourselves to
>>>>>>>> donate some
>>>>>>> hours
>>>>>>>> to Apache Royale to make this happen? If some of us help in the
>>>>>>>> current state I think we can get to it sooner.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> 
>>>>>>>> 
>>>>>>>> El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
>>>>>>>> lazzari.ang...@gmail.com>)
>>>>>&

Re: Let's bump Royale version to 1.0

[Piotr Zarzycki]

h engines don't necessarily pick things up from
> >> them
> >>> very well) but a major source of support is Stack Overflow... I use
> this
> >> a
> >>> lot with my other work and there's a lot of information there.
> >>>>
> >>>> Apache Royale doesn't appear to have a tag; when I search for "royale"
> >>> all I got was stuff about "Clash Royale"; there are however 8 questions
> >>> with "flexjs" tags.
> >>>>
> >>>> But wouldn't it be good for people to add questions and to contribute
> >>> answers there, both from the user perspective and perhaps also the dev
> >>> perspective? Would be interested in people's thoughts... (and perhaps
> >> I'll
> >>> have to dig out my SO credentials to start contributing there)
> >>>>
> >>>> thanks
> >>>>
> >>>> Andrew
> >>>>
> >>>>
> >>>> -Original Message-
> >>>> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> >>>> Sent: 26 April 2019 10:39
> >>>> To: dev@royale.apache.org
> >>>> Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0
> >>>>
> >>>> Hi Angelo, that's great! :)
> >>>>
> >>>> any help here is very appreciated.
> >>>>
> >>>> Share in a new mail a concrete contribution before starting to work on
> >>> it, so we can know about it and help you on the task so your work fit
> >>> perfectly in the overall picture.
> >>>>
> >>>> I'd like to create videos too, and people asked about it in facebook
> >> and
> >>> twitter. Do you have skills in creating videos?
> >>>>
> >>>>
> >>>>
> >>>> El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari (<
> >>> lazzari.ang...@gmail.com>)
> >>>> escribió:
> >>>>
> >>>>> Yes, i can give some slots to help with documentation or example
> >>>>> project or so... I think tutorial videos could be help to understand
> >>>>> rapidly the platform and could help new user to get ready in a few
> >>>>> hours to start build their project.
> >>>>>
> >>>>> Angelo
> >>>>>
> >>>>> On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira
> >>>>> 
> >>>>> wrote:
> >>>>>
> >>>>>> Agree with latest comments.
> >>>>>>
> >>>>>> I think we should work in docs and ease the start of new users to
> >>>>>> target
> >>>>>> 1.0
> >>>>>> And in the process fix some few things (i.e: don't want to reach 1.0
> >>>>>> with Jewel Table in its current state and API)
> >>>>>>
> >>>>>> What do you think?
> >>>>>>
> >>>>>> If you all agree could you think on how to contribute to that
> >>>>>> effort? Can we have as a near goal to bring 1.0 planing ourselves to
> >>>>>> donate some
> >>>>> hours
> >>>>>> to Apache Royale to make this happen? If some of us help in the
> >>>>>> current state I think we can get to it sooner.
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>>
> >>>>>> El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
> >>>>>> lazzari.ang...@gmail.com>)
> >>>>>> escribió:
> >>>>>>
> >>>>>>> I am completely agree with Olaf: start using a new platform where
> >>>>>>> the documentation is not complete, clean and updated it is a
> >>>>>>> really bad thing...and it would be a potential reason to increase
> >>>>>>> the difficulty
> >>>>> to
> >>>>>>> adopt the platform...
> >>>>>>>
> >>>>>>> Angelo
> >>>>>>>
> >>>>>>> El vie., 26 abr. 2019 8:54, Olaf Krueger 
> >>>>>> escribió:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Basically, I think it's important to provide a great develo

Re: Let's bump Royale version to 1.0

[Dany Dhondt]

Can somebody create some royale tags please? I don’t have enough rep. points at 
this moment.
Also, shouldn’t we agree on some basic royale tags?
When the tags are made, I’ll start posting some questions.

Dany

> Op 29 apr. 2019, om 17:27 heeft Alex Harui  het 
> volgende geschreven:
> 
> I agree we want to develop a presence on Stack Overflow.  I still can't 
> figure out how to earn enough points be able to answer any questions so I 
> won't be of much help until that happens.
> 
> -Alex
> 
> On 4/29/19, 7:32 AM, "Carlos Rovira"  wrote:
> 
>Hi,
> 
>about StackOverFlow, we already discussed to start creating questions in
>SOF, but finally nobody does. I think I should not create one and respond
>myself right? it will be very sad to do in that way. So if someone start to
>post questions in SOF, I promise to respond, at least if it's something I
>can know how to respond. It could be things you already know, but we must
>start in some way.
> 
>SOF is crucial for us, I talked with customers that pointed me that Apache
>Royale is not on SOF, so his devs can easily search problems there. And
>this is the google for developers. If we are not there, Royale will never
>succeed, So if you want Royale to succeed we all should put some work, what
>we can, in SOF. @dany, if you want to start this effort we can follow you.
>Just let's know in a mail here so we can go to that link and respond. If
>you start that your work will be follow :)
> 
>@Andrew, "Flex In a Week" is a very good idea too. I think we can work on
>that, but again, we need some kind of plan. A team to work on that. Things
>like that can't be create by only one man's work. Volunteers?
> 
>@Om, I not use NPM but will try Royale CLI since we need something really
>fast to compete with React or others, or people will never jump to out
>wagon.
> 
>thanks for all the thoughts! :)
> 
> 
> 
> 
> 
>El lun., 29 abr. 2019 a las 9:17, OmPrakash Muppirala 
> ()
>escribió:
> 
>> On Fri, Apr 26, 2019 at 7:37 PM Dany Dhondt 
>> wrote:
>> 
>>> I’m all for buikding a knowledge base in Stack Overflow! The mailing list
>>> should only be used for developing Royale. Questions about using Royale
>>> should go to SO
>>> 
>>> The competitors of Royale are React, Vue, Angular, ...
>>> Lots of developers are now used to those workflows.
>>> In case of React, create-react-app sets you up with a brand new, ready to
>>> go project in less than 30 seconds. That should be a benchmark for Royale
>>> imo.
>>> 
>>> Dany
>>> 
>>> 
>> The Royale CLI is modeled closely after the create-react-app.  The docs for
>> the alpha version is available here:
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fnpm%2Fclidata=02%7C01%7Caharui%40adobe.com%7C950f12a2b0f24cad192508d6ccaf8241%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921451512477017sdata=4VN8JejglMeW08ZcNV6fCJ%2BdYJjOHcvfGDL099jives%3Dreserved=0
>> If I get more feedback, I am keep improving this tool.
>> 
>> Thanks,
>> Om
>> 
>> 
>> 
>>> Verstuurd vanaf mijn iPhone
>>> 
>>>> Op 26 apr. 2019 om 12:42 heeft Frost, Andrew 
>>> het volgende geschreven:
>>>> 
>>>> One other thought ... currently the way people ask for support is via
>>> these mailing lists. Which are okay but I'm always conscious that I'm
>>> potentially spamming people, plus the volume of mails is such that I
>> have a
>>> rule to push all these into a folder that I then review every day or
>> two..
>>>> 
>>>> But if I want to find something out, I tend not to go search the
>> mailing
>>> list, I tend to search online. Looking through mailing list threads isn't
>>> the easiest (and search engines don't necessarily pick things up from
>> them
>>> very well) but a major source of support is Stack Overflow... I use this
>> a
>>> lot with my other work and there's a lot of information there.
>>>> 
>>>> Apache Royale doesn't appear to have a tag; when I search for "royale"
>>> all I got was stuff about "Clash Royale"; there are however 8 questions
>>> with "flexjs" tags.
>>>> 
>>>> But wouldn't it be good for people to add questions and to contribute
>>> answers there, both from the user perspective and perhaps also the dev
>>> perspective? Would be interested in peopl

Re: Version property (was: Let's bump Royale version to 1.0)

[Alex Harui]

@Mark, I'm assuming you want something in the output that identifies the actual 
versions used.  In Royale, you may also need to identify the version of the 
transpiler as well, and maybe the version of Google Closure.  If you want to 
propose (or better yet, implement) a PAYG way to do that in Royale, please do 
so.  If other folks think this will be useful, please speak up so we get a 
sense of how important it is.  A simple hack may be to embed the pom.xml file 
in your output as a string if you are using Maven.  If you use Ant, you could 
grab the SDK version from build.properties or embed the 
flex-sdk-description.xml file.

@Carlos, I couldn't understand your scenario.  Feel free to start a separate 
thread on it.  The key aspect, as a guess, is trying to avoid code that assumes 
that an instance is a subclass of a particular base class instead of an 
implementation of an interface.

HTH,
-Alex

On 4/29/19, 7:29 AM, "Carlos Rovira"  wrote:

@Mark, if you use Maven, then artifacts in the poms are all what you need,
so maven takes care of pulling all right dependencies you need.

@Alex, about extending IUIBase, my own experience is that beads are a very
good way to extend/compose more code you need, but extending core
interfaces like the one you said is not the case. Let me put you an
example: For Jewel I use "StyledUIBase" that extends "UIBase" to add
IClassSelectorListSupport, the css CRUD API (addClass, removeClass, etc..):

public class StyledUIBase extends UIBase implements
IClassSelectorListSupport

This makes that some components are easy to extend but others need to be
recreate. There are lots of cases in Jewel where I need to

If you search in Jewel for implements IClassSelectorListSupport
 you'll find Jewel Group, Jewel DataContainerBase and Jewel Table, are
implementing that class while, so they are not StyledUIBase in it's core
are standard UIBase and at its level we implement the interface and add
again all methods repeating the code. So we are duplicating that code all
that times.

I think this is one of the few things I don't like in Jewel, If you know
some way to do this in a better way, I can change it

thanks





El lun., 29 abr. 2019 a las 12:36, Kessler CTR Mark J
() escribió:

>  Yeah just concerned with an official build number, or date, or
> something with numbers we can use to identify a production app back to 
what
> SDK was used to compile it.  Imagine having an app released on production
> and a user reports a problem. We would need to reproduce the problem in a
> test environment.  This would include using the same SDK to compile the
> app.  Currently in Flex, we can just access its version directly which
> makes things faster.
>
> If the SDK doesn't have anything like this at the moment and we did
> add that functionality in there, I would say let's just use a date field
> since it could be automated.  Something like MMDD type format.
>
>
> -Mark K
>
>
> -Original Message-
> From: Alex Harui [mailto:aha...@adobe.com.INVALID]
> Sent: Friday, April 26, 2019 12:02 PM
> To: dev@royale.apache.org
> Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale
> version to 1.0)
>
>
>
> On 4/26/19, 4:29 AM, "Kessler CTR Mark J" 

> wrote:
>
> > So far, we have not had the release scripts properly generate the
> right version number for the NPM artifacts.
>
>
> This spurred a question for me.  Is there a way to find out what
> version number the SDK binaries are in code for Royale?  Sort of like the
> Flex SDK mx.core.FlexVersion or at least a build date?
>
> Not at this time.  IMO, runtime versioning wasn't worth the cost of all of
> those strings and code in the production app.  Also, Royale was designed
> from the beginning to try to be "version-agnostic".  By using
> loose-coupling via Beads/PAYG/ValuesManager and lots of interfaces instead
> of direct class references, there shouldn't be a need to deal with version
> incompatibilities at runtime like Flex did with the Marshall Plan and
> FlexVersion and more.
>
> Flex had to care about version incompatibilities because the fundamental
> base classes were not loosely-coupled.  Flex HelloWorld was 128K not just
> because UIComponent was huge, but because UIComponent pulled in other
> classes as init-time strongly-coupled dependencies.  A good thing to think
> about as you write Royale framework code is, "can every dependency be
> easily replaced"

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Hi,

about StackOverFlow, we already discussed to start creating questions in
SOF, but finally nobody does. I think I should not create one and respond
myself right? it will be very sad to do in that way. So if someone start to
post questions in SOF, I promise to respond, at least if it's something I
can know how to respond. It could be things you already know, but we must
start in some way.

SOF is crucial for us, I talked with customers that pointed me that Apache
Royale is not on SOF, so his devs can easily search problems there. And
this is the google for developers. If we are not there, Royale will never
succeed, So if you want Royale to succeed we all should put some work, what
we can, in SOF. @dany, if you want to start this effort we can follow you.
Just let's know in a mail here so we can go to that link and respond. If
you start that your work will be follow :)

@Andrew, "Flex In a Week" is a very good idea too. I think we can work on
that, but again, we need some kind of plan. A team to work on that. Things
like that can't be create by only one man's work. Volunteers?

@Om, I not use NPM but will try Royale CLI since we need something really
fast to compete with React or others, or people will never jump to out
wagon.

thanks for all the thoughts! :)





El lun., 29 abr. 2019 a las 9:17, OmPrakash Muppirala ()
escribió:

> On Fri, Apr 26, 2019 at 7:37 PM Dany Dhondt 
> wrote:
>
> > I’m all for buikding a knowledge base in Stack Overflow! The mailing list
> > should only be used for developing Royale. Questions about using Royale
> > should go to SO
> >
> > The competitors of Royale are React, Vue, Angular, ...
> > Lots of developers are now used to those workflows.
> > In case of React, create-react-app sets you up with a brand new, ready to
> > go project in less than 30 seconds. That should be a benchmark for Royale
> > imo.
> >
> > Dany
> >
> >
> The Royale CLI is modeled closely after the create-react-app.  The docs for
> the alpha version is available here:
> https://github.com/apache/royale-asjs/tree/develop/npm/cli
> If I get more feedback, I am keep improving this tool.
>
> Thanks,
> Om
>
>
>
> > Verstuurd vanaf mijn iPhone
> >
> > > Op 26 apr. 2019 om 12:42 heeft Frost, Andrew 
> > het volgende geschreven:
> > >
> > > One other thought ... currently the way people ask for support is via
> > these mailing lists. Which are okay but I'm always conscious that I'm
> > potentially spamming people, plus the volume of mails is such that I
> have a
> > rule to push all these into a folder that I then review every day or
> two..
> > >
> > > But if I want to find something out, I tend not to go search the
> mailing
> > list, I tend to search online. Looking through mailing list threads isn't
> > the easiest (and search engines don't necessarily pick things up from
> them
> > very well) but a major source of support is Stack Overflow... I use this
> a
> > lot with my other work and there's a lot of information there.
> > >
> > > Apache Royale doesn't appear to have a tag; when I search for "royale"
> > all I got was stuff about "Clash Royale"; there are however 8 questions
> > with "flexjs" tags.
> > >
> > > But wouldn't it be good for people to add questions and to contribute
> > answers there, both from the user perspective and perhaps also the dev
> > perspective? Would be interested in people's thoughts... (and perhaps
> I'll
> > have to dig out my SO credentials to start contributing there)
> > >
> > > thanks
> > >
> > >  Andrew
> > >
> > >
> > > -Original Message-
> > > From: Carlos Rovira [mailto:carlosrov...@apache.org]
> > > Sent: 26 April 2019 10:39
> > > To: dev@royale.apache.org
> > > Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0
> > >
> > > Hi Angelo, that's great! :)
> > >
> > > any help here is very appreciated.
> > >
> > > Share in a new mail a concrete contribution before starting to work on
> > it, so we can know about it and help you on the task so your work fit
> > perfectly in the overall picture.
> > >
> > > I'd like to create videos too, and people asked about it in facebook
> and
> > twitter. Do you have skills in creating videos?
> > >
> > >
> > >
> > > El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari (<
> > lazzari.ang...@gmail.com>)
> > > escribió:
> > >
> > >> Yes, i can give some slots to help with documentation or exampl

Re: Version property (was: Let's bump Royale version to 1.0)

[Carlos Rovira]

@Mark, if you use Maven, then artifacts in the poms are all what you need,
so maven takes care of pulling all right dependencies you need.

@Alex, about extending IUIBase, my own experience is that beads are a very
good way to extend/compose more code you need, but extending core
interfaces like the one you said is not the case. Let me put you an
example: For Jewel I use "StyledUIBase" that extends "UIBase" to add
IClassSelectorListSupport, the css CRUD API (addClass, removeClass, etc..):

public class StyledUIBase extends UIBase implements
IClassSelectorListSupport

This makes that some components are easy to extend but others need to be
recreate. There are lots of cases in Jewel where I need to

If you search in Jewel for implements IClassSelectorListSupport
 you'll find Jewel Group, Jewel DataContainerBase and Jewel Table, are
implementing that class while, so they are not StyledUIBase in it's core
are standard UIBase and at its level we implement the interface and add
again all methods repeating the code. So we are duplicating that code all
that times.

I think this is one of the few things I don't like in Jewel, If you know
some way to do this in a better way, I can change it

thanks





El lun., 29 abr. 2019 a las 12:36, Kessler CTR Mark J
() escribió:

>  Yeah just concerned with an official build number, or date, or
> something with numbers we can use to identify a production app back to what
> SDK was used to compile it.  Imagine having an app released on production
> and a user reports a problem. We would need to reproduce the problem in a
> test environment.  This would include using the same SDK to compile the
> app.  Currently in Flex, we can just access its version directly which
> makes things faster.
>
> If the SDK doesn't have anything like this at the moment and we did
> add that functionality in there, I would say let's just use a date field
> since it could be automated.  Something like MMDD type format.
>
>
> -Mark K
>
>
> -Original Message-
> From: Alex Harui [mailto:aha...@adobe.com.INVALID]
> Sent: Friday, April 26, 2019 12:02 PM
> To: dev@royale.apache.org
> Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale
> version to 1.0)
>
>
>
> On 4/26/19, 4:29 AM, "Kessler CTR Mark J" 
> wrote:
>
> > So far, we have not had the release scripts properly generate the
> right version number for the NPM artifacts.
>
>
> This spurred a question for me.  Is there a way to find out what
> version number the SDK binaries are in code for Royale?  Sort of like the
> Flex SDK mx.core.FlexVersion or at least a build date?
>
> Not at this time.  IMO, runtime versioning wasn't worth the cost of all of
> those strings and code in the production app.  Also, Royale was designed
> from the beginning to try to be "version-agnostic".  By using
> loose-coupling via Beads/PAYG/ValuesManager and lots of interfaces instead
> of direct class references, there shouldn't be a need to deal with version
> incompatibilities at runtime like Flex did with the Marshall Plan and
> FlexVersion and more.
>
> Flex had to care about version incompatibilities because the fundamental
> base classes were not loosely-coupled.  Flex HelloWorld was 128K not just
> because UIComponent was huge, but because UIComponent pulled in other
> classes as init-time strongly-coupled dependencies.  A good thing to think
> about as you write Royale framework code is, "can every dependency be
> easily replaced"?
>
> After we hit 1.0 (and hopefully find some volunteers to write regression
> tests), then new APIs to existing classes will need to be considered
> carefully and implemented in extensions.  So there will be some extension
> of IUIBase that has some new API instead of adding new APIs to IUIBase.  I
> have a personal preference to use long names instead of numbers, so the
> extension will hopefully be called IUIBaseWithWhatever instead of IUIBase2.
>
> If you are asking about build-time versioning, we haven't done anything
> there either.  As long as there is no impact on production apps I think it
> is fine for folks to contribute something if there is a need.
>
> My 2 cents,
> -Alex
>
>

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

RE: Version property (was: Let's bump Royale version to 1.0)

[Kessler CTR Mark J]

 Yeah just concerned with an official build number, or date, or something 
with numbers we can use to identify a production app back to what SDK was used 
to compile it.  Imagine having an app released on production and a user reports 
a problem. We would need to reproduce the problem in a test environment.  This 
would include using the same SDK to compile the app.  Currently in Flex, we can 
just access its version directly which makes things faster.

If the SDK doesn't have anything like this at the moment and we did add 
that functionality in there, I would say let's just use a date field since it 
could be automated.  Something like MMDD type format.


-Mark K


-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID]
Sent: Friday, April 26, 2019 12:02 PM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale version 
to 1.0)



On 4/26/19, 4:29 AM, "Kessler CTR Mark J"  
wrote:

> So far, we have not had the release scripts properly generate the right 
version number for the NPM artifacts.


This spurred a question for me.  Is there a way to find out what version 
number the SDK binaries are in code for Royale?  Sort of like the Flex SDK 
mx.core.FlexVersion or at least a build date?

Not at this time.  IMO, runtime versioning wasn't worth the cost of all of 
those strings and code in the production app.  Also, Royale was designed from 
the beginning to try to be "version-agnostic".  By using loose-coupling via 
Beads/PAYG/ValuesManager and lots of interfaces instead of direct class 
references, there shouldn't be a need to deal with version incompatibilities at 
runtime like Flex did with the Marshall Plan and FlexVersion and more.

Flex had to care about version incompatibilities because the fundamental base 
classes were not loosely-coupled.  Flex HelloWorld was 128K not just because 
UIComponent was huge, but because UIComponent pulled in other classes as 
init-time strongly-coupled dependencies.  A good thing to think about as you 
write Royale framework code is, "can every dependency be easily replaced"?

After we hit 1.0 (and hopefully find some volunteers to write regression 
tests), then new APIs to existing classes will need to be considered carefully 
and implemented in extensions.  So there will be some extension of IUIBase that 
has some new API instead of adding new APIs to IUIBase.  I have a personal 
preference to use long names instead of numbers, so the extension will 
hopefully be called IUIBaseWithWhatever instead of IUIBase2.

If you are asking about build-time versioning, we haven't done anything there 
either.  As long as there is no impact on production apps I think it is fine 
for folks to contribute something if there is a need.

My 2 cents,
-Alex

Re: Let's bump Royale version to 1.0

[OmPrakash Muppirala]

On Fri, Apr 26, 2019 at 7:37 PM Dany Dhondt 
wrote:

> I’m all for buikding a knowledge base in Stack Overflow! The mailing list
> should only be used for developing Royale. Questions about using Royale
> should go to SO
>
> The competitors of Royale are React, Vue, Angular, ...
> Lots of developers are now used to those workflows.
> In case of React, create-react-app sets you up with a brand new, ready to
> go project in less than 30 seconds. That should be a benchmark for Royale
> imo.
>
> Dany
>
>
The Royale CLI is modeled closely after the create-react-app.  The docs for
the alpha version is available here:
https://github.com/apache/royale-asjs/tree/develop/npm/cli
If I get more feedback, I am keep improving this tool.

Thanks,
Om



> Verstuurd vanaf mijn iPhone
>
> > Op 26 apr. 2019 om 12:42 heeft Frost, Andrew 
> het volgende geschreven:
> >
> > One other thought ... currently the way people ask for support is via
> these mailing lists. Which are okay but I'm always conscious that I'm
> potentially spamming people, plus the volume of mails is such that I have a
> rule to push all these into a folder that I then review every day or two..
> >
> > But if I want to find something out, I tend not to go search the mailing
> list, I tend to search online. Looking through mailing list threads isn't
> the easiest (and search engines don't necessarily pick things up from them
> very well) but a major source of support is Stack Overflow... I use this a
> lot with my other work and there's a lot of information there.
> >
> > Apache Royale doesn't appear to have a tag; when I search for "royale"
> all I got was stuff about "Clash Royale"; there are however 8 questions
> with "flexjs" tags.
> >
> > But wouldn't it be good for people to add questions and to contribute
> answers there, both from the user perspective and perhaps also the dev
> perspective? Would be interested in people's thoughts... (and perhaps I'll
> have to dig out my SO credentials to start contributing there)
> >
> > thanks
> >
> >  Andrew
> >
> >
> > -Original Message-
> > From: Carlos Rovira [mailto:carlosrov...@apache.org]
> > Sent: 26 April 2019 10:39
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0
> >
> > Hi Angelo, that's great! :)
> >
> > any help here is very appreciated.
> >
> > Share in a new mail a concrete contribution before starting to work on
> it, so we can know about it and help you on the task so your work fit
> perfectly in the overall picture.
> >
> > I'd like to create videos too, and people asked about it in facebook and
> twitter. Do you have skills in creating videos?
> >
> >
> >
> > El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari (<
> lazzari.ang...@gmail.com>)
> > escribió:
> >
> >> Yes, i can give some slots to help with documentation or example
> >> project or so... I think tutorial videos could be help to understand
> >> rapidly the platform and could help new user to get ready in a few
> >> hours to start build their project.
> >>
> >> Angelo
> >>
> >> On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira
> >> 
> >> wrote:
> >>
> >>> Agree with latest comments.
> >>>
> >>> I think we should work in docs and ease the start of new users to
> >>> target
> >>> 1.0
> >>> And in the process fix some few things (i.e: don't want to reach 1.0
> >>> with Jewel Table in its current state and API)
> >>>
> >>> What do you think?
> >>>
> >>> If you all agree could you think on how to contribute to that
> >>> effort? Can we have as a near goal to bring 1.0 planing ourselves to
> >>> donate some
> >> hours
> >>> to Apache Royale to make this happen? If some of us help in the
> >>> current state I think we can get to it sooner.
> >>>
> >>> Thanks
> >>>
> >>>
> >>> El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
> >>> lazzari.ang...@gmail.com>)
> >>> escribió:
> >>>
> >>>> I am completely agree with Olaf: start using a new platform where
> >>>> the documentation is not complete, clean and updated it is a
> >>>> really bad thing...and it would be a potential reason to increase
> >>>> the difficulty
> >> to
> >>>> adopt the platform...
> >>>>
> >>>> A

Re: Let's bump Royale version to 1.0 -- submit your bid for assistance to the group by Friday May 3

[Olaf Krueger]

Hi Justin,
thanks for your amazing offer!

> ...what Alex and Carlos want to see happen...

Before others will do this I would just like to mention that no individuals
make decisions here at Apache. It's always the community! ;-)

However, I am curious about the feedback!

Thanks,
Olaf





 







--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

That's great Angelo! :)

El vie., 26 abr. 2019 a las 13:06, Angelo Lazzari ()
escribió:

> yes, I always send video to my client, it is a really good way to explain
> new process and teach things...
>
> I will write a new email about the video course...
>
> Angelo
>
> On Fri, Apr 26, 2019 at 11:39 AM Carlos Rovira 
> wrote:
>
> > Hi Angelo, that's great! :)
> >
> > any help here is very appreciated.
> >
> > Share in a new mail a concrete contribution before starting to work on
> it,
> > so we can know about it and help you on the task so your work fit
> perfectly
> > in the overall picture.
> >
> > I'd like to create videos too, and people asked about it in facebook and
> > twitter. Do you have skills in creating videos?
> >
> >
> >
> > El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari (<
> > lazzari.ang...@gmail.com>)
> > escribió:
> >
> > > Yes, i can give some slots to help with documentation or example
> project
> > or
> > > so... I think tutorial videos could be help to understand rapidly the
> > > platform and could help new user to get ready in a few hours to start
> > build
> > > their project.
> > >
> > > Angelo
> > >
> > > On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira <
> carlosrov...@apache.org>
> > > wrote:
> > >
> > > > Agree with latest comments.
> > > >
> > > > I think we should work in docs and ease the start of new users to
> > target
> > > > 1.0
> > > > And in the process fix some few things (i.e: don't want to reach 1.0
> > with
> > > > Jewel Table in its current state and API)
> > > >
> > > > What do you think?
> > > >
> > > > If you all agree could you think on how to contribute to that effort?
> > Can
> > > > we have as a near goal to bring 1.0 planing ourselves to donate some
> > > hours
> > > > to Apache Royale to make this happen? If some of us help in the
> current
> > > > state I think we can get to it sooner.
> > > >
> > > > Thanks
> > > >
> > > >
> > > > El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
> > > > lazzari.ang...@gmail.com>)
> > > > escribió:
> > > >
> > > > > I am completely agree with Olaf: start using a new platform where
> the
> > > > > documentation is not complete, clean and updated it is a really bad
> > > > > thing...and it would be a potential reason to increase the
> difficulty
> > > to
> > > > > adopt the platform...
> > > > >
> > > > > Angelo
> > > > >
> > > > > El vie., 26 abr. 2019 8:54, Olaf Krueger 
> > > > escribió:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Basically, I think it's important to provide a great developer
> > > > > experience.
> > > > > > IMO, that's more important than trying to implement missing
> > features.
> > > > > >
> > > > > > One thing to achieve this is documentation of course.
> > > > > > Thanks to all of you there already exist a lot of docs, but it
> > feels
> > > a
> > > > > bit
> > > > > > messy because they are hosted at different places, e.g.:
> > > > > >
> > > > > > - royale-docs repo
> > > > > > - royale-asjs wiki
> > > > > > - royale-asjs Readme
> > > > > > - https://royale.apache.org
> > > > > > - ...?
> > > > > >
> > > > > > As a user, it's hard to get an overview of what is available...
> and
> > > > > where.
> > > > > > Maybe it's a good idea to consolidate the docs before releasing
> > 1.0.
> > > > > >
> > > > > > Just my 2 cents,
> > > > > > Olaf
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sent from: http://apache-royale-development.20373.n8.nabble.com/
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > >
> > >
> > > --
> > > Angelo Lazzari
> > > mobile: +34 683 137 087
> > > mail: lazzari.ang...@gmail.com
> > >
> > >
> > >
> > >
> >
> 
> > > Verify the correspondence of the addressee; otherwise, notify that to
> the
> > > sender and, conscious of the responsibility for the undue use, destroy
> > the
> > > message and its copies.
> > >
> > >
> >
> 
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
> Angelo Lazzari
> mobile: +34 683 137 087
> mail: lazzari.ang...@gmail.com
>
>
>
> 
> Verify the correspondence of the addressee; otherwise, notify that to the
> sender and, conscious of the responsibility for the undue use, destroy the
> message and its copies.
>
> 
>


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

Re: Version property (was: Let's bump Royale version to 1.0)

[Alex Harui]

On 4/26/19, 4:29 AM, "Kessler CTR Mark J"  
wrote:

> So far, we have not had the release scripts properly generate the right 
version number for the NPM artifacts.


This spurred a question for me.  Is there a way to find out what version 
number the SDK binaries are in code for Royale?  Sort of like the Flex SDK 
mx.core.FlexVersion or at least a build date?

Not at this time.  IMO, runtime versioning wasn't worth the cost of all of 
those strings and code in the production app.  Also, Royale was designed from 
the beginning to try to be "version-agnostic".  By using loose-coupling via 
Beads/PAYG/ValuesManager and lots of interfaces instead of direct class 
references, there shouldn't be a need to deal with version incompatibilities at 
runtime like Flex did with the Marshall Plan and FlexVersion and more.

Flex had to care about version incompatibilities because the fundamental base 
classes were not loosely-coupled.  Flex HelloWorld was 128K not just because 
UIComponent was huge, but because UIComponent pulled in other classes as 
init-time strongly-coupled dependencies.  A good thing to think about as you 
write Royale framework code is, "can every dependency be easily replaced"?

After we hit 1.0 (and hopefully find some volunteers to write regression 
tests), then new APIs to existing classes will need to be considered carefully 
and implemented in extensions.  So there will be some extension of IUIBase that 
has some new API instead of adding new APIs to IUIBase.  I have a personal 
preference to use long names instead of numbers, so the extension will 
hopefully be called IUIBaseWithWhatever instead of IUIBase2.

If you are asking about build-time versioning, we haven't done anything there 
either.  As long as there is no impact on production apps I think it is fine 
for folks to contribute something if there is a need.

My 2 cents,
-Alex


-Mark K

-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID]
Sent: Friday, April 26, 2019 2:44 AM
To: dev@royale.apache.org
    Subject: [Non-DoD Source] Re: Let's bump Royale version to 1.0

I do not have an opinion on what technical/marketing criteria we use to 
decide which release to call 1.0.  I'm not working directly with 
users/customers.

I do not currently have time/energy/budget to work on any of the things 
folks think need to be done to get to 1.0 and barely have enough time to work 
on getting the next release out.  So someone else will have to supply the 
time/energy/budget to get these tasks done.

I do have an opinion based on a practical aspect.  So far, we have not had 
the release scripts properly generate the right version number for the NPM 
artifacts.  That's why we've jumped from 0.9.4 to 0.9.6 and skipped 0.9.5.  So 
I would say we should not call this next release 1.0 and wait until the release 
automation can correctly version all artifacts with the right version number 
before we pick one to call 1.0.  With any luck I'll get the automation running 
next week and will ask for someone to volunteer to test drive it.

-Alex

Re: Let's bump Royale version to 1.0

[Dany Dhondt]

I’m all for buikding a knowledge base in Stack Overflow! The mailing list 
should only be used for developing Royale. Questions about using Royale should 
go to SO

The competitors of Royale are React, Vue, Angular, ...
Lots of developers are now used to those workflows. 
In case of React, create-react-app sets you up with a brand new, ready to go 
project in less than 30 seconds. That should be a benchmark for Royale imo. 

Dany


Verstuurd vanaf mijn iPhone

> Op 26 apr. 2019 om 12:42 heeft Frost, Andrew  het 
> volgende geschreven:
> 
> One other thought ... currently the way people ask for support is via these 
> mailing lists. Which are okay but I'm always conscious that I'm potentially 
> spamming people, plus the volume of mails is such that I have a rule to push 
> all these into a folder that I then review every day or two..
> 
> But if I want to find something out, I tend not to go search the mailing 
> list, I tend to search online. Looking through mailing list threads isn't the 
> easiest (and search engines don't necessarily pick things up from them very 
> well) but a major source of support is Stack Overflow... I use this a lot 
> with my other work and there's a lot of information there.
> 
> Apache Royale doesn't appear to have a tag; when I search for "royale" all I 
> got was stuff about "Clash Royale"; there are however 8 questions with 
> "flexjs" tags.
> 
> But wouldn't it be good for people to add questions and to contribute answers 
> there, both from the user perspective and perhaps also the dev perspective? 
> Would be interested in people's thoughts... (and perhaps I'll have to dig out 
> my SO credentials to start contributing there)
> 
> thanks
> 
>  Andrew
> 
> 
> -Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org] 
> Sent: 26 April 2019 10:39
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0
> 
> Hi Angelo, that's great! :)
> 
> any help here is very appreciated.
> 
> Share in a new mail a concrete contribution before starting to work on it, so 
> we can know about it and help you on the task so your work fit perfectly in 
> the overall picture.
> 
> I'd like to create videos too, and people asked about it in facebook and 
> twitter. Do you have skills in creating videos?
> 
> 
> 
> El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari ()
> escribió:
> 
>> Yes, i can give some slots to help with documentation or example 
>> project or so... I think tutorial videos could be help to understand 
>> rapidly the platform and could help new user to get ready in a few 
>> hours to start build their project.
>> 
>> Angelo
>> 
>> On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira 
>> 
>> wrote:
>> 
>>> Agree with latest comments.
>>> 
>>> I think we should work in docs and ease the start of new users to 
>>> target
>>> 1.0
>>> And in the process fix some few things (i.e: don't want to reach 1.0 
>>> with Jewel Table in its current state and API)
>>> 
>>> What do you think?
>>> 
>>> If you all agree could you think on how to contribute to that 
>>> effort? Can we have as a near goal to bring 1.0 planing ourselves to 
>>> donate some
>> hours
>>> to Apache Royale to make this happen? If some of us help in the 
>>> current state I think we can get to it sooner.
>>> 
>>> Thanks
>>> 
>>> 
>>> El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
>>> lazzari.ang...@gmail.com>)
>>> escribió:
>>> 
>>>> I am completely agree with Olaf: start using a new platform where 
>>>> the documentation is not complete, clean and updated it is a 
>>>> really bad thing...and it would be a potential reason to increase 
>>>> the difficulty
>> to
>>>> adopt the platform...
>>>> 
>>>> Angelo
>>>> 
>>>> El vie., 26 abr. 2019 8:54, Olaf Krueger 
>>> escribió:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Basically, I think it's important to provide a great developer
>>>> experience.
>>>>> IMO, that's more important than trying to implement missing features.
>>>>> 
>>>>> One thing to achieve this is documentation of course.
>>>>> Thanks to all of you there already exist a lot of docs, but it 
>>>>> feels
>> a
>>>> bit
>>>>> messy because they are hosted at different places, e.g.:
>>>>> 
>

RE: [Non-DoD Source] Re: Let's bump Royale version to 1.0

[Kessler CTR Mark J]

Well imagine a new user blindly walking into the site.They go to the 
root of the site [1] and see that nice orange "getting started" button.  
Clicking on that takes you to the getting started page [2].   It has a link to 
the download page and it has IDE links which is good.  It would be nice if we 
added a few more links to things like examples and the ASDOC references.  Then 
I would feel like it has  a good start.   

 Now the first thing that happens is we are sending people away from the 
main Royale site and onto GitHub to look up the IDE information.  Are we using 
that as our main information sources now?  I feel like we should keep 
everything on one place for information.  Whether that is on apache or github 
doesn't matter as long as it's consistent.



[1] https://royale.apache.org/
[2] https://royale.apache.org/getting-started/


-Mark K

-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: Friday, April 26, 2019 4:52 AM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Let's bump Royale version to 1.0

Hi Mark,

most of the points in your list should already done in the website, like
download SDK, minimum requerimiento, IDE's available, examples of using
components (this is blog examples and need more, but I'm the only one
pushing this examples, this could be easy to solve if others want to commit
blog post in the same way I did for new examples. The template is already
done, or I can help in publishing it if people donates content.

Other need more work: Starting a new App, ASDoc needs to be completed with
new APIs, since right now is just a sub set and in this form is not useful
for others.

Latest point is complicated to have this days, since it implies people
using Royale and sharing different techniques of integration.

Re: Let's bump Royale version to 1.0

[Andrew Wetmore]

Way back when, I learned a lot from the "Flex in a Week" online
introduction [1]. Would it be useful to create something like this to go
along with Tour de Jewel?

a

[1] https://www.adobe.com/devnet/flex/videotraining.html

On Fri, Apr 26, 2019 at 7:42 AM Frost, Andrew 
wrote:

> One other thought ... currently the way people ask for support is via
> these mailing lists. Which are okay but I'm always conscious that I'm
> potentially spamming people, plus the volume of mails is such that I have a
> rule to push all these into a folder that I then review every day or two..
>
> But if I want to find something out, I tend not to go search the mailing
> list, I tend to search online. Looking through mailing list threads isn't
> the easiest (and search engines don't necessarily pick things up from them
> very well) but a major source of support is Stack Overflow... I use this a
> lot with my other work and there's a lot of information there.
>
> Apache Royale doesn't appear to have a tag; when I search for "royale" all
> I got was stuff about "Clash Royale"; there are however 8 questions with
> "flexjs" tags.
>
> But wouldn't it be good for people to add questions and to contribute
> answers there, both from the user perspective and perhaps also the dev
> perspective? Would be interested in people's thoughts... (and perhaps I'll
> have to dig out my SO credentials to start contributing there)
>
> thanks
>
>   Andrew
>
>
> -Original Message-
> From: Carlos Rovira [mailto:carlosrov...@apache.org]
> Sent: 26 April 2019 10:39
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0
>
> Hi Angelo, that's great! :)
>
> any help here is very appreciated.
>
> Share in a new mail a concrete contribution before starting to work on it,
> so we can know about it and help you on the task so your work fit perfectly
> in the overall picture.
>
> I'd like to create videos too, and people asked about it in facebook and
> twitter. Do you have skills in creating videos?
>
>
>
> El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari (<
> lazzari.ang...@gmail.com>)
> escribió:
>
> > Yes, i can give some slots to help with documentation or example
> > project or so... I think tutorial videos could be help to understand
> > rapidly the platform and could help new user to get ready in a few
> > hours to start build their project.
> >
> > Angelo
> >
> > On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira
> > 
> > wrote:
> >
> > > Agree with latest comments.
> > >
> > > I think we should work in docs and ease the start of new users to
> > > target
> > > 1.0
> > > And in the process fix some few things (i.e: don't want to reach 1.0
> > > with Jewel Table in its current state and API)
> > >
> > > What do you think?
> > >
> > > If you all agree could you think on how to contribute to that
> > > effort? Can we have as a near goal to bring 1.0 planing ourselves to
> > > donate some
> > hours
> > > to Apache Royale to make this happen? If some of us help in the
> > > current state I think we can get to it sooner.
> > >
> > > Thanks
> > >
> > >
> > > El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
> > > lazzari.ang...@gmail.com>)
> > > escribió:
> > >
> > > > I am completely agree with Olaf: start using a new platform where
> > > > the documentation is not complete, clean and updated it is a
> > > > really bad thing...and it would be a potential reason to increase
> > > > the difficulty
> > to
> > > > adopt the platform...
> > > >
> > > > Angelo
> > > >
> > > > El vie., 26 abr. 2019 8:54, Olaf Krueger 
> > > escribió:
> > > >
> > > > > Hi,
> > > > >
> > > > > Basically, I think it's important to provide a great developer
> > > > experience.
> > > > > IMO, that's more important than trying to implement missing
> features.
> > > > >
> > > > > One thing to achieve this is documentation of course.
> > > > > Thanks to all of you there already exist a lot of docs, but it
> > > > > feels
> > a
> > > > bit
> > > > > messy because they are hosted at different places, e.g.:
> > > > >
> > > > > - royale-docs repo
> > > > > - royale-asjs wiki
> > > > > - royale-asjs Readme
> > > > &

Re: Let's bump Royale version to 1.0

[Frost, Andrew]

One other thought ... currently the way people ask for support is via these 
mailing lists. Which are okay but I'm always conscious that I'm potentially 
spamming people, plus the volume of mails is such that I have a rule to push 
all these into a folder that I then review every day or two..

But if I want to find something out, I tend not to go search the mailing list, 
I tend to search online. Looking through mailing list threads isn't the easiest 
(and search engines don't necessarily pick things up from them very well) but a 
major source of support is Stack Overflow... I use this a lot with my other 
work and there's a lot of information there.

Apache Royale doesn't appear to have a tag; when I search for "royale" all I 
got was stuff about "Clash Royale"; there are however 8 questions with "flexjs" 
tags.

But wouldn't it be good for people to add questions and to contribute answers 
there, both from the user perspective and perhaps also the dev perspective? 
Would be interested in people's thoughts... (and perhaps I'll have to dig out 
my SO credentials to start contributing there)

thanks

  Andrew


-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: 26 April 2019 10:39
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0

Hi Angelo, that's great! :)

any help here is very appreciated.

Share in a new mail a concrete contribution before starting to work on it, so 
we can know about it and help you on the task so your work fit perfectly in the 
overall picture.

I'd like to create videos too, and people asked about it in facebook and 
twitter. Do you have skills in creating videos?



El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari ()
escribió:

> Yes, i can give some slots to help with documentation or example 
> project or so... I think tutorial videos could be help to understand 
> rapidly the platform and could help new user to get ready in a few 
> hours to start build their project.
>
> Angelo
>
> On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira 
> 
> wrote:
>
> > Agree with latest comments.
> >
> > I think we should work in docs and ease the start of new users to 
> > target
> > 1.0
> > And in the process fix some few things (i.e: don't want to reach 1.0 
> > with Jewel Table in its current state and API)
> >
> > What do you think?
> >
> > If you all agree could you think on how to contribute to that 
> > effort? Can we have as a near goal to bring 1.0 planing ourselves to 
> > donate some
> hours
> > to Apache Royale to make this happen? If some of us help in the 
> > current state I think we can get to it sooner.
> >
> > Thanks
> >
> >
> > El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
> > lazzari.ang...@gmail.com>)
> > escribió:
> >
> > > I am completely agree with Olaf: start using a new platform where 
> > > the documentation is not complete, clean and updated it is a 
> > > really bad thing...and it would be a potential reason to increase 
> > > the difficulty
> to
> > > adopt the platform...
> > >
> > > Angelo
> > >
> > > El vie., 26 abr. 2019 8:54, Olaf Krueger 
> > escribió:
> > >
> > > > Hi,
> > > >
> > > > Basically, I think it's important to provide a great developer
> > > experience.
> > > > IMO, that's more important than trying to implement missing features.
> > > >
> > > > One thing to achieve this is documentation of course.
> > > > Thanks to all of you there already exist a lot of docs, but it 
> > > > feels
> a
> > > bit
> > > > messy because they are hosted at different places, e.g.:
> > > >
> > > > - royale-docs repo
> > > > - royale-asjs wiki
> > > > - royale-asjs Readme
> > > > - 
> > > > https://clicktime.symantec.com/3SEvxFs2HbjNAgsLBEtNLr17Vc?u=http
> > > > s%3A%2F%2Froyale.apache.org
> > > > - ...?
> > > >
> > > > As a user, it's hard to get an overview of what is available... 
> > > > and
> > > where.
> > > > Maybe it's a good idea to consolidate the docs before releasing 1.0.
> > > >
> > > > Just my 2 cents,
> > > > Olaf
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sent from: 
> > > > https://clicktime.symantec.com/3LM5ngUtumonkv3VTyrZRJ77Vc?u=http
> > > > %3A%2F%2Fapache-royale-developmen

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Hi Angelo, that's great! :)

any help here is very appreciated.

Share in a new mail a concrete contribution before starting to work on it,
so we can know about it and help you on the task so your work fit perfectly
in the overall picture.

I'd like to create videos too, and people asked about it in facebook and
twitter. Do you have skills in creating videos?



El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari ()
escribió:

> Yes, i can give some slots to help with documentation or example project or
> so... I think tutorial videos could be help to understand rapidly the
> platform and could help new user to get ready in a few hours to start build
> their project.
>
> Angelo
>
> On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira 
> wrote:
>
> > Agree with latest comments.
> >
> > I think we should work in docs and ease the start of new users to target
> > 1.0
> > And in the process fix some few things (i.e: don't want to reach 1.0 with
> > Jewel Table in its current state and API)
> >
> > What do you think?
> >
> > If you all agree could you think on how to contribute to that effort? Can
> > we have as a near goal to bring 1.0 planing ourselves to donate some
> hours
> > to Apache Royale to make this happen? If some of us help in the current
> > state I think we can get to it sooner.
> >
> > Thanks
> >
> >
> > El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
> > lazzari.ang...@gmail.com>)
> > escribió:
> >
> > > I am completely agree with Olaf: start using a new platform where the
> > > documentation is not complete, clean and updated it is a really bad
> > > thing...and it would be a potential reason to increase the difficulty
> to
> > > adopt the platform...
> > >
> > > Angelo
> > >
> > > El vie., 26 abr. 2019 8:54, Olaf Krueger 
> > escribió:
> > >
> > > > Hi,
> > > >
> > > > Basically, I think it's important to provide a great developer
> > > experience.
> > > > IMO, that's more important than trying to implement missing features.
> > > >
> > > > One thing to achieve this is documentation of course.
> > > > Thanks to all of you there already exist a lot of docs, but it feels
> a
> > > bit
> > > > messy because they are hosted at different places, e.g.:
> > > >
> > > > - royale-docs repo
> > > > - royale-asjs wiki
> > > > - royale-asjs Readme
> > > > - https://royale.apache.org
> > > > - ...?
> > > >
> > > > As a user, it's hard to get an overview of what is available... and
> > > where.
> > > > Maybe it's a good idea to consolidate the docs before releasing 1.0.
> > > >
> > > > Just my 2 cents,
> > > > Olaf
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sent from: http://apache-royale-development.20373.n8.nabble.com/
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
> Angelo Lazzari
> mobile: +34 683 137 087
> mail: lazzari.ang...@gmail.com
>
>
>
> 
> Verify the correspondence of the addressee; otherwise, notify that to the
> sender and, conscious of the responsibility for the undue use, destroy the
> message and its copies.
>
> 
>


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

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Hi Alex,

I think that if you have the time to finish the automation is good enough.
This is one is maybe the most important point to get solved.
Once releasing is just push a button for any of us, things should be more
easy.
Hope others could go with rest of the task to do, that a side of fixing
some few things for a 1.0, should be focused on docs, and make accessible
Royale for newcomers.

I'm with you that is not real to get directly a 1.0 as next release, so
going to 0.9.6 and then in few weeks trying again for a 0.9.7 will be the
most easy way to reach 1.0
If in that process we find the release is still having some issues, we can
go to 0.9.8, and so on



El vie., 26 abr. 2019 a las 8:43, Alex Harui ()
escribió:

> I do not have an opinion on what technical/marketing criteria we use to
> decide which release to call 1.0.  I'm not working directly with
> users/customers.
>
> I do not currently have time/energy/budget to work on any of the things
> folks think need to be done to get to 1.0 and barely have enough time to
> work on getting the next release out.  So someone else will have to supply
> the time/energy/budget to get these tasks done.
>
> I do have an opinion based on a practical aspect.  So far, we have not had
> the release scripts properly generate the right version number for the NPM
> artifacts.  That's why we've jumped from 0.9.4 to 0.9.6 and skipped 0.9.5.
> So I would say we should not call this next release 1.0 and wait until the
> release automation can correctly version all artifacts with the right
> version number before we pick one to call 1.0.  With any luck I'll get the
> automation running next week and will ask for someone to volunteer to test
> drive it.
>
> -Alex
>
> On 4/25/19, 9:57 AM, "Kessler CTR Mark J" 
> wrote:
>
> To give a perspective on the references and examples part from our
> organization...
>
>  When we started trying to convert one of our small apps we choose
> the Jewel set of components.  This was because it had lots of visible
> content and examples [1] whereas the standard examples were more limited
> [2].  Carlos does a good job of advertising new features with pictures,
> short descriptions, and some examples.  It would be nice to consolidate
> that information back into  the Royale site.  The Tour de Jewel examples
> being hosted on the Royale site is a good idea.  This is why we used Jewel
> as our base to build our organizational library from.  There might be other
> component sets that are fully functional, but without good references and
> examples they are basically unknown or gray boxes.
>
> The hosted ASDOCs on the Royale site [3] are a bit harder to read
> and are missing different component sets like jewel.  We were not able to
> use it for finding most of the things we were looking for.  Instead we used
> the SDK source and searched for class names / content.  Then we could walk
> the class file source and their inheritance to find what we were looking
> for.  Like hunting for premade beads.
>
>
> So if I were to order what a person might need to start (I know we
> have parts of this already):
>
> -How to download SDK binaries and get minimum requirements done.
> -What IDE's are available and how to set them up.
> -Starting a new app and getting it to compile for the first time.
> -Good reference (ASDOCs) being more complete.
> -Examples of using the components and how to use them.
> -Whole example applications showing a purpose and integration of
> multiple techniques.
>
>
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Froyale.apache.org%2Ftourdejewel%2Fdata=02%7C01%7Caharui%40adobe.com%7Ce884bd0d1c2f49f6bebf08d6c99f2129%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636918082633163959sdata=H0JPIF3M9MEYOhNSKp7rNFdrXa61pR2fZveGS3Ccs1c%3Dreserved=0
> [2]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Froyale.apache.org%2Fcategory%2Froyale-examples%2Fdata=02%7C01%7Caharui%40adobe.com%7Ce884bd0d1c2f49f6bebf08d6c99f2129%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636918082633163959sdata=2AIJu8SJoERkzHjDW58kwzgeVNNqjLYAaCPx%2BBedcYU%3Dreserved=0
> [3]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Froyale.apache.org%2Fasdoc%2Fdata=02%7C01%7Caharui%40adobe.com%7Ce884bd0d1c2f49f6bebf08d6c99f2129%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636918082633163959sdata=L01ZNhEXKo001E25idVo9md2vqqhxKx%2FwCf%2BL%2BAzCuM%3Dreserved=0
>
> -Mark K
>
>
>
>

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

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Hi Mark,

most of the points in your list should already done in the website, like
download SDK, minimum requerimiento, IDE's available, examples of using
components (this is blog examples and need more, but I'm the only one
pushing this examples, this could be easy to solve if others want to commit
blog post in the same way I did for new examples. The template is already
done, or I can help in publishing it if people donates content.

Other need more work: Starting a new App, ASDoc needs to be completed with
new APIs, since right now is just a sub set and in this form is not useful
for others.

Latest point is complicated to have this days, since it implies people
using Royale and sharing different techniques of integration.


El jue., 25 abr. 2019 a las 18:57, Kessler CTR Mark J
() escribió:

> To give a perspective on the references and examples part from our
> organization...
>
>  When we started trying to convert one of our small apps we choose the
> Jewel set of components.  This was because it had lots of visible content
> and examples [1] whereas the standard examples were more limited [2].
> Carlos does a good job of advertising new features with pictures, short
> descriptions, and some examples.  It would be nice to consolidate that
> information back into  the Royale site.  The Tour de Jewel examples being
> hosted on the Royale site is a good idea.  This is why we used Jewel as our
> base to build our organizational library from.  There might be other
> component sets that are fully functional, but without good references and
> examples they are basically unknown or gray boxes.
>
> The hosted ASDOCs on the Royale site [3] are a bit harder to read and
> are missing different component sets like jewel.  We were not able to use
> it for finding most of the things we were looking for.  Instead we used the
> SDK source and searched for class names / content.  Then we could walk the
> class file source and their inheritance to find what we were looking for.
> Like hunting for premade beads.
>
>
> So if I were to order what a person might need to start (I know we have
> parts of this already):
>
> -How to download SDK binaries and get minimum requirements done.
> -What IDE's are available and how to set them up.
> -Starting a new app and getting it to compile for the first time.
> -Good reference (ASDOCs) being more complete.
> -Examples of using the components and how to use them.
> -Whole example applications showing a purpose and integration of multiple
> techniques.
>
>
>
> [1] https://royale.apache.org/tourdejewel/
> [2] https://royale.apache.org/category/royale-examples/
> [3] https://royale.apache.org/asdoc/
>
> -Mark K
>
>

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

Re: Let's bump Royale version to 1.0

[Angelo Lazzari]

Yes, i can give some slots to help with documentation or example project or
so... I think tutorial videos could be help to understand rapidly the
platform and could help new user to get ready in a few hours to start build
their project.

Angelo

On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira 
wrote:

> Agree with latest comments.
>
> I think we should work in docs and ease the start of new users to target
> 1.0
> And in the process fix some few things (i.e: don't want to reach 1.0 with
> Jewel Table in its current state and API)
>
> What do you think?
>
> If you all agree could you think on how to contribute to that effort? Can
> we have as a near goal to bring 1.0 planing ourselves to donate some hours
> to Apache Royale to make this happen? If some of us help in the current
> state I think we can get to it sooner.
>
> Thanks
>
>
> El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
> lazzari.ang...@gmail.com>)
> escribió:
>
> > I am completely agree with Olaf: start using a new platform where the
> > documentation is not complete, clean and updated it is a really bad
> > thing...and it would be a potential reason to increase the difficulty to
> > adopt the platform...
> >
> > Angelo
> >
> > El vie., 26 abr. 2019 8:54, Olaf Krueger 
> escribió:
> >
> > > Hi,
> > >
> > > Basically, I think it's important to provide a great developer
> > experience.
> > > IMO, that's more important than trying to implement missing features.
> > >
> > > One thing to achieve this is documentation of course.
> > > Thanks to all of you there already exist a lot of docs, but it feels a
> > bit
> > > messy because they are hosted at different places, e.g.:
> > >
> > > - royale-docs repo
> > > - royale-asjs wiki
> > > - royale-asjs Readme
> > > - https://royale.apache.org
> > > - ...?
> > >
> > > As a user, it's hard to get an overview of what is available... and
> > where.
> > > Maybe it's a good idea to consolidate the docs before releasing 1.0.
> > >
> > > Just my 2 cents,
> > > Olaf
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Sent from: http://apache-royale-development.20373.n8.nabble.com/
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 
Angelo Lazzari
mobile: +34 683 137 087
mail: lazzari.ang...@gmail.com



Verify the correspondence of the addressee; otherwise, notify that to the
sender and, conscious of the responsibility for the undue use, destroy the
message and its copies.

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Agree with latest comments.

I think we should work in docs and ease the start of new users to target 1.0
And in the process fix some few things (i.e: don't want to reach 1.0 with
Jewel Table in its current state and API)

What do you think?

If you all agree could you think on how to contribute to that effort? Can
we have as a near goal to bring 1.0 planing ourselves to donate some hours
to Apache Royale to make this happen? If some of us help in the current
state I think we can get to it sooner.

Thanks


El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari ()
escribió:

> I am completely agree with Olaf: start using a new platform where the
> documentation is not complete, clean and updated it is a really bad
> thing...and it would be a potential reason to increase the difficulty to
> adopt the platform...
>
> Angelo
>
> El vie., 26 abr. 2019 8:54, Olaf Krueger  escribió:
>
> > Hi,
> >
> > Basically, I think it's important to provide a great developer
> experience.
> > IMO, that's more important than trying to implement missing features.
> >
> > One thing to achieve this is documentation of course.
> > Thanks to all of you there already exist a lot of docs, but it feels a
> bit
> > messy because they are hosted at different places, e.g.:
> >
> > - royale-docs repo
> > - royale-asjs wiki
> > - royale-asjs Readme
> > - https://royale.apache.org
> > - ...?
> >
> > As a user, it's hard to get an overview of what is available... and
> where.
> > Maybe it's a good idea to consolidate the docs before releasing 1.0.
> >
> > Just my 2 cents,
> > Olaf
> >
> >
> >
> >
> >
> >
> >
> > --
> > Sent from: http://apache-royale-development.20373.n8.nabble.com/
> >
>


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

Re: Let's bump Royale version to 1.0

[Angelo Lazzari]

I am completely agree with Olaf: start using a new platform where the
documentation is not complete, clean and updated it is a really bad
thing...and it would be a potential reason to increase the difficulty to
adopt the platform...

Angelo

El vie., 26 abr. 2019 8:54, Olaf Krueger  escribió:

> Hi,
>
> Basically, I think it's important to provide a great developer experience.
> IMO, that's more important than trying to implement missing features.
>
> One thing to achieve this is documentation of course.
> Thanks to all of you there already exist a lot of docs, but it feels a bit
> messy because they are hosted at different places, e.g.:
>
> - royale-docs repo
> - royale-asjs wiki
> - royale-asjs Readme
> - https://royale.apache.org
> - ...?
>
> As a user, it's hard to get an overview of what is available... and where.
> Maybe it's a good idea to consolidate the docs before releasing 1.0.
>
> Just my 2 cents,
> Olaf
>
>
>
>
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>

Re: Let's bump Royale version to 1.0

[Olaf Krueger]

Hi,

Basically, I think it's important to provide a great developer experience.
IMO, that's more important than trying to implement missing features.

One thing to achieve this is documentation of course.
Thanks to all of you there already exist a lot of docs, but it feels a bit
messy because they are hosted at different places, e.g.:

- royale-docs repo
- royale-asjs wiki
- royale-asjs Readme
- https://royale.apache.org
- ...?

As a user, it's hard to get an overview of what is available... and where.
Maybe it's a good idea to consolidate the docs before releasing 1.0.

Just my 2 cents,
Olaf







--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Let's bump Royale version to 1.0

[Alex Harui]

I do not have an opinion on what technical/marketing criteria we use to decide 
which release to call 1.0.  I'm not working directly with users/customers.

I do not currently have time/energy/budget to work on any of the things folks 
think need to be done to get to 1.0 and barely have enough time to work on 
getting the next release out.  So someone else will have to supply the 
time/energy/budget to get these tasks done.

I do have an opinion based on a practical aspect.  So far, we have not had the 
release scripts properly generate the right version number for the NPM 
artifacts.  That's why we've jumped from 0.9.4 to 0.9.6 and skipped 0.9.5.  So 
I would say we should not call this next release 1.0 and wait until the release 
automation can correctly version all artifacts with the right version number 
before we pick one to call 1.0.  With any luck I'll get the automation running 
next week and will ask for someone to volunteer to test drive it.

-Alex

On 4/25/19, 9:57 AM, "Kessler CTR Mark J"  
wrote:

To give a perspective on the references and examples part from our 
organization...

 When we started trying to convert one of our small apps we choose the 
Jewel set of components.  This was because it had lots of visible content and 
examples [1] whereas the standard examples were more limited [2].  Carlos does 
a good job of advertising new features with pictures, short descriptions, and 
some examples.  It would be nice to consolidate that information back into  the 
Royale site.  The Tour de Jewel examples being hosted on the Royale site is a 
good idea.  This is why we used Jewel as our base to build our organizational 
library from.  There might be other component sets that are fully functional, 
but without good references and examples they are basically unknown or gray 
boxes.

The hosted ASDOCs on the Royale site [3] are a bit harder to read and 
are missing different component sets like jewel.  We were not able to use it 
for finding most of the things we were looking for.  Instead we used the SDK 
source and searched for class names / content.  Then we could walk the class 
file source and their inheritance to find what we were looking for.  Like 
hunting for premade beads.


So if I were to order what a person might need to start (I know we have 
parts of this already):

-How to download SDK binaries and get minimum requirements done.
-What IDE's are available and how to set them up.
-Starting a new app and getting it to compile for the first time.
-Good reference (ASDOCs) being more complete.
-Examples of using the components and how to use them.
-Whole example applications showing a purpose and integration of multiple 
techniques.



[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Froyale.apache.org%2Ftourdejewel%2Fdata=02%7C01%7Caharui%40adobe.com%7Ce884bd0d1c2f49f6bebf08d6c99f2129%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636918082633163959sdata=H0JPIF3M9MEYOhNSKp7rNFdrXa61pR2fZveGS3Ccs1c%3Dreserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Froyale.apache.org%2Fcategory%2Froyale-examples%2Fdata=02%7C01%7Caharui%40adobe.com%7Ce884bd0d1c2f49f6bebf08d6c99f2129%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636918082633163959sdata=2AIJu8SJoERkzHjDW58kwzgeVNNqjLYAaCPx%2BBedcYU%3Dreserved=0
[3] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Froyale.apache.org%2Fasdoc%2Fdata=02%7C01%7Caharui%40adobe.com%7Ce884bd0d1c2f49f6bebf08d6c99f2129%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636918082633163959sdata=L01ZNhEXKo001E25idVo9md2vqqhxKx%2FwCf%2BL%2BAzCuM%3Dreserved=0

-Mark K

Re: Let's bump Royale version to 1.0

[Kessler CTR Mark J]

To give a perspective on the references and examples part from our 
organization...

 When we started trying to convert one of our small apps we choose the 
Jewel set of components.  This was because it had lots of visible content and 
examples [1] whereas the standard examples were more limited [2].  Carlos does 
a good job of advertising new features with pictures, short descriptions, and 
some examples.  It would be nice to consolidate that information back into  the 
Royale site.  The Tour de Jewel examples being hosted on the Royale site is a 
good idea.  This is why we used Jewel as our base to build our organizational 
library from.  There might be other component sets that are fully functional, 
but without good references and examples they are basically unknown or gray 
boxes.

The hosted ASDOCs on the Royale site [3] are a bit harder to read and are 
missing different component sets like jewel.  We were not able to use it for 
finding most of the things we were looking for.  Instead we used the SDK source 
and searched for class names / content.  Then we could walk the class file 
source and their inheritance to find what we were looking for.  Like hunting 
for premade beads.


So if I were to order what a person might need to start (I know we have parts 
of this already):

-How to download SDK binaries and get minimum requirements done.
-What IDE's are available and how to set them up.
-Starting a new app and getting it to compile for the first time.
-Good reference (ASDOCs) being more complete.
-Examples of using the components and how to use them.
-Whole example applications showing a purpose and integration of multiple 
techniques.



[1] https://royale.apache.org/tourdejewel/
[2] https://royale.apache.org/category/royale-examples/
[3] https://royale.apache.org/asdoc/

-Mark K

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Hi Justin,

mostly agree with al of that. In my response I put pros and cons to help
now more about what things are under the hood. At least for Jewel that is
the part where I focus.
I think as well that is time to bring more tutorials and videos.
The main problem for people external to the project is how to get started,
this must be improved since the main problem about Royale is complexity in
how to get on rails to start producing.
Hope others could come to the discussion and bring their thoughts as well

El mié., 24 abr. 2019 a las 21:21, Justin M. Hill ()
escribió:

> I agree with Piotr.
>
> Perception matters.  1.0 does not need to be perfect, it just needs to be
> good enough.   And Royale is good enough to be called 1.0 in my opinion.
> It has 2 production applications -- ones from Harbs and Carlos are already
> running on it from what I understand.
>
>
> Royale needs to get traction in the market.
>
>
> Many people will not pay attention until the following items occur:
>
> 1) A version 1.0 is released
>
> 2) There are clear tutorials which can get people started quickly [the
> Moonshine team has agreed to fund a few videos to get this started]
>
> 3) It is very easy for new developers to get started with the technology
> [the Moonshine IDE accomplishes this with first class support for Royale,
> Flex, and ActionScript]
>
> 3) Documentation is improved, easy to read, friendly, and up-to-date
>
> 4) Marketing ensues explaining why people should look at Royale compared
> to React, ExtJS, Angular, etc.   If these articles can get written, the
> Moonshine IDE team is willing to help fund some Google and other campaigns
> to bring traction.
>
> 5) Multiple IDEs support Royale well -- not just Moonshine IDE and Visual
> Studio Code.   Eclipse, IntelliJ, FlashDevelop also all need to support
> Royale.
>
> 6) Testimonials from other companies who have ported Flex or created fresh
> Royale applications become commonplace and trust starts to build that the
> conversion is possible
>
> 7) A consulting ecosystem needs to exist where it is fast for newcomers /
> explorers to decide the technology is worth pursuing and want to engage
> with a consultant to help them along the journey.
>
>
> Of the above items, the first and easiest thing to control is whether we
> call the software 1.0 or not.   I last had this discussing 28 months ago
> with Alex in Seattle.   A huge amount of work has gone into Royale since
> then.
>
> As the saying goes:  the enemy of good enough is perfection.
>
> Please, consider pushing the release to 1.0.
>
> Thank you,
>
> Justin Hill
>
>
> [image: Inactive hide details for dev-digest-help---04/24/2019 08:33:01
> AM---dev Digest 24 Apr 2019 13:32:50 - Issue 1958 Topics 
> (m]dev-digest-help---04/24/2019
> 08:33:01 AM---dev Digest 24 Apr 2019 13:32:50 - Issue 1958 Topics
> (messages 9856 through 9859)
>
>
> - Message from Piotr Zarzycki  on Wed, 24
> Apr 2019 11:56:47 +0200 -
> *To:*
>
>dev@royale.apache.org
>
> *Subject:*
>
>Let's bump Royale version to 1.0
>
> Hi Team,
>
> Lately, I’m working with Royale framework more and more. Once you know the
> framework better from the inside your productivity skyrockets and it is
> similar to what we had in Flex. The question comes up - why do we actually
> cannot bump our version to 1.0? I’d like to see that happen with the
> upcoming release or at least the following one.
>
> What’s holding us back?
>
> Is it lack of features? What if I don’t have some feature in 1.0, but I
> will add it in 1.1? This is still fine in my opinion.
>
> Or is it bugs? Because guess how people are seeing us after 5 years of
> development and still with leading 0. They think “highly unstable”. And
> because this continues for so long they think the project might, in fact,
> be dead.
>
> I would like to ask you Team to consider making our upcoming version (or
> the following one) as 1.0.
>
> Let’s find the answer in this thread. Post your arguments: “Why not?”, “Why
> yes?”
>
> Thanks,
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
>

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

RE: Let's bump Royale version to 1.0

[Frost, Andrew]

Hi

I would agree with Justin here, my only addition would be that when we hit 1.0 
status, some of the APIs should become immutable – for example things like 
BinaryData and so on, should not then be changed later on. If you have an 
application which compiles against Royale 1.0, it should also compile (and 
work) against any later release (at least 1.x release perhaps; compatibility 
doesn’t necessarily have to go across major versions?).

The component libraries and new functionality can always be added, so 1.0 isn’t 
a “final” version, it just means that you can go ahead without having to make 
changes because someone has updated an API leaving you with code that no longer 
compiles.

I also agree that Royale isn’t the easiest thing to get started with .. so #2 
and #3 below are pretty key.

We can help with #7 if anyone needs support :-)

thanks

   Andrew


From: Justin M. Hill [mailto:jus...@prominic.net]
Sent: 24 April 2019 20:21
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Let's bump Royale version to 1.0


I agree with Piotr.

Perception matters.  1.0 does not need to be perfect, it just needs to be good 
enough.   And Royale is good enough to be called 1.0 in my opinion.   It has 2 
production applications -- ones from Harbs and Carlos are already running on it 
from what I understand.


Royale needs to get traction in the market.


Many people will not pay attention until the following items occur:

1) A version 1.0 is released

2) There are clear tutorials which can get people started quickly [the 
Moonshine team has agreed to fund a few videos to get this started]

3) It is very easy for new developers to get started with the technology [the 
Moonshine IDE accomplishes this with first class support for Royale, Flex, and 
ActionScript]

3) Documentation is improved, easy to read, friendly, and up-to-date

4) Marketing ensues explaining why people should look at Royale compared to 
React, ExtJS, Angular, etc.   If these articles can get written, the Moonshine 
IDE team is willing to help fund some Google and other campaigns to bring 
traction.

5) Multiple IDEs support Royale well -- not just Moonshine IDE and Visual 
Studio Code.   Eclipse, IntelliJ, FlashDevelop also all need to support Royale.

6) Testimonials from other companies who have ported Flex or created fresh 
Royale applications become commonplace and trust starts to build that the 
conversion is possible

7) A consulting ecosystem needs to exist where it is fast for newcomers / 
explorers to decide the technology is worth pursuing and want to engage with a 
consultant to help them along the journey.


Of the above items, the first and easiest thing to control is whether we call 
the software 1.0 or not.   I last had this discussing 28 months ago with Alex 
in Seattle.   A huge amount of work has gone into Royale since then.

As the saying goes:  the enemy of good enough is perfection.

Please, consider pushing the release to 1.0.

Thank you,

Justin Hill


[Inactive hide details for dev-digest-help---04/24/2019 08:33:01 AM---dev 
Digest 24 Apr 2019 13:32:50 - Issue 1958 Topics 
(m]dev-digest-help---04/24/2019 08:33:01 AM---dev Digest 24 Apr 2019 13:32:50 
- Issue 1958 Topics (messages 9856 through 9859)


- Message from Piotr Zarzycki 
mailto:piotrzarzyck...@gmail.com>> on Wed, 24 Apr 
2019 11:56:47 +0200 -
To:

dev@royale.apache.org<mailto:dev@royale.apache.org>

Subject:

Let's bump Royale version to 1.0


Hi Team,

Lately, I’m working with Royale framework more and more. Once you know the
framework better from the inside your productivity skyrockets and it is
similar to what we had in Flex. The question comes up - why do we actually
cannot bump our version to 1.0? I’d like to see that happen with the
upcoming release or at least the following one.

What’s holding us back?

Is it lack of features? What if I don’t have some feature in 1.0, but I
will add it in 1.1? This is still fine in my opinion.

Or is it bugs? Because guess how people are seeing us after 5 years of
development and still with leading 0. They think “highly unstable”. And
because this continues for so long they think the project might, in fact,
be dead.

I would like to ask you Team to consider making our upcoming version (or
the following one) as 1.0.

Let’s find the answer in this thread. Post your arguments: “Why not?”, “Why
yes?”

Thanks,
--

Piotr Zarzycki

Patreon: 
*https://www.patreon.com/piotrzarzycki<https://clicktime.symantec.com/3MX5snbQLPuKXoDCHV8C8sh7Vc?u=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki>
<https://www.patreon.com/piotrzarzycki<https://clicktime.symantec.com/3MX5snbQLPuKXoDCHV8C8sh7Vc?u=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki>>*

RE: Let's bump Royale version to 1.0

[Justin M. Hill]

I agree with Piotr.

Perception matters.  1.0 does not need to be perfect, it just needs to be
good enough.   And Royale is good enough to be called 1.0 in my opinion.
It has 2 production applications -- ones from Harbs and Carlos are already
running on it from what I understand.


Royale needs to get traction in the market.


Many people will not pay attention until the following items occur:

1) A version 1.0 is released

2) There are clear tutorials which can get people started quickly [the
Moonshine team has agreed to fund a few videos to get this started]

3) It is very easy for new developers to get started with the technology
[the Moonshine IDE accomplishes this with first class support for Royale,
Flex, and ActionScript]

3) Documentation is improved, easy to read, friendly, and up-to-date

4) Marketing ensues explaining why people should look at Royale compared to
React, ExtJS, Angular, etc.   If these articles can get written, the
Moonshine IDE team is willing to help fund some Google and other campaigns
to bring traction.

5) Multiple IDEs support Royale well -- not just Moonshine IDE and Visual
Studio Code.   Eclipse, IntelliJ, FlashDevelop also all need to support
Royale.

6) Testimonials from other companies who have ported Flex or created fresh
Royale applications become commonplace and trust starts to build that the
conversion is possible

7) A consulting ecosystem needs to exist where it is fast for newcomers /
explorers to decide the technology is worth pursuing and want to engage
with a consultant to help them along the journey.


Of the above items, the first and easiest thing to control is whether we
call the software 1.0 or not.   I last had this discussing 28 months ago
with Alex in Seattle.   A huge amount of work has gone into Royale since
then.

As the saying goes:  the enemy of good enough is perfection.

Please, consider pushing the release to 1.0.

Thank you,

Justin Hill





- Message from Piotr Zarzycki  on Wed, 24
Apr 2019 11:56:47 +0200 -

  To: dev@royale.apache.org 

 Subject: Let's bump Royale version 
  to 1.0


Hi Team,

Lately, I’m working with Royale framework more and more. Once you know the
framework better from the inside your productivity skyrockets and it is
similar to what we had in Flex. The question comes up - why do we actually
cannot bump our version to 1.0? I’d like to see that happen with the
upcoming release or at least the following one.

What’s holding us back?

Is it lack of features? What if I don’t have some feature in 1.0, but I
will add it in 1.1? This is still fine in my opinion.

Or is it bugs? Because guess how people are seeing us after 5 years of
development and still with leading 0. They think “highly unstable”. And
because this continues for so long they think the project might, in fact,
be dead.

I would like to ask you Team to consider making our upcoming version (or
the following one) as 1.0.

Let’s find the answer in this thread. Post your arguments: “Why not?”, “Why
yes?”

Thanks,
--

Piotr Zarzycki

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

Re: Let's bump Royale version to 1.0

[Carlos Rovira]

Hi Piotr,

great to bring this to the table. These are my thoughts;

As you, I'm feeling that Royale is ready for production, in fact we're
releasing tomorrow our first Royale App for a big client. So yes from that
point of view I see the technology is mature. But this is true at least for
Basic, Jewel UI Sets, and for AMF/RemoteObject, HTTPService, and other
parts.

In the other hand we have some parts on the way that will probably last for
more months, like MX/Spark emulation, Or components features still missing
in Jewel (DataGrid, Tree, Menu, Switch, finish themes,...), and others that
need to change (Jewel Table should not be in the current state for a 1.0
release).

There's a very cumbersome bug in application compilation that makes the
compiler a bad compilation. So when you run it, labels in buttons, drawers
and other places are empty. I think that bug should be find and solved
before a 1.0, since when it happens it gives a very bad sensation of
something not ok in the compiler. I think this could be some problems in
threadings. Normally when this happens (about 1 of 10 app compilations, you
can solve it by compiling again).

For example people is asking about video components, and other missing
parts, we could decide that could come in a later version.

Maybe we should make a list of things that should be in 1.0, and other list
of things that will not, but we can delay to 1.1, 1.2, 1.3, ...and more...

I think we should at least release a 0.9.6 soon, and if the Alex new
release system works, we could reach 1.0 in just 3 more release 1 per month.

Just my thoughts




El mié., 24 abr. 2019 a las 11:57, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Hi Team,
>
> Lately, I’m working with Royale framework more and more. Once you know the
> framework better from the inside your productivity skyrockets and it is
> similar to what we had in Flex. The question comes up - why do we actually
> cannot bump our version to 1.0? I’d like to see that happen with the
> upcoming release or at least the following one.
>
> What’s holding us back?
>
> Is it lack of features? What if I don’t have some feature in 1.0, but I
> will add it in 1.1? This is still fine in my opinion.
>
> Or is it bugs? Because guess how people are seeing us after 5 years of
> development and still with leading 0. They think “highly unstable”. And
> because this continues for so long they think the project might, in fact,
> be dead.
>
> I would like to ask you Team to consider making our upcoming version (or
> the following one) as 1.0.
>
> Let’s find the answer in this thread. Post your arguments: “Why not?”, “Why
> yes?”
>
> Thanks,
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>


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

Let's bump Royale version to 1.0

[Piotr Zarzycki]

Hi Team,

Lately, I’m working with Royale framework more and more. Once you know the
framework better from the inside your productivity skyrockets and it is
similar to what we had in Flex. The question comes up - why do we actually
cannot bump our version to 1.0? I’d like to see that happen with the
upcoming release or at least the following one.

What’s holding us back?

Is it lack of features? What if I don’t have some feature in 1.0, but I
will add it in 1.1? This is still fine in my opinion.

Or is it bugs? Because guess how people are seeing us after 5 years of
development and still with leading 0. They think “highly unstable”. And
because this continues for so long they think the project might, in fact,
be dead.

I would like to ask you Team to consider making our upcoming version (or
the following one) as 1.0.

Let’s find the answer in this thread. Post your arguments: “Why not?”, “Why
yes?”

Thanks,
-- 

Piotr Zarzycki

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