Re: Crux Branch

[Josh Tynjala]

Personally, I don't think it should be named Swiz, and I support a new
name. Crux seems fine to me.

- Josh

On Mon, Jul 15, 2019, 1:58 AM Carlos Rovira  wrote:

> Hi Alex,
>
> your concerns about Crux name applies to the others like Basic or Jewel
> (just to name a few). If I search for "Jewel js" in google I get various
> Jewel libraries (same for Basic js). What makes Jewel appropriate for us is
> that is an internal name (internal branding) we use to refer to that
> concrete part of the entire Royale framework, so in then end is not about
> "jewel" for folks here their brain knows that we are talking all the time
> about "Apache Royale Jewel". One more thing we add using this kind of names
> is: 1) Names that has some marketing, and we can create icons, or more (it
> will be hard for me create a icon for FlexJS or SwizRoyale), 2) short names
> with some meaning inside the ecosystem and relation with a set of words
> that shares some meaning root. And moreover, since we changed to Royale
> name we are doing all the things in the same line of action what makes the
> naming decisions in Royale follow a strategy. It would be not consistent to
> come back to older name strategy like FlexJS or SwizRoyale. We should
> follow what we started and continue in that line.
>
> I must say I never thought in MXRoyale and SparkRoyale naming, since it was
> a work in progress that started to grow in Royale progressively and I was
> focused in other parts. For that cases, we could bring other names or not.
> I must say that I didn't take much time to think about it conceptually. We
> could do or not depending on what you want to do in that part.
>
> For Jewel, we didn't thought about it so much. I remember I started with
> other codename, but very soon I renamed and shared to Jewel explaining the
> motivations, thoughts, and meaning of that name. But, we didn't some king
> of name process for it
>
> In the case of Crux. I think it could not be "Crux",I like for the
> shortness and meaning, but could be other better options. What I don't like
> is bring as "Swiz" or "SwizRoyale". The first because is not Swiz (as I
> explained Swiz is for Flex) and SwizRoyale is for me very long and does not
> have a meaning inside of what we are doing with the rest of Royale naming
> decision and marketing (making it very difficult to brand along with the
> rest of Royale parts for marketing and web).
>
> just my 2
>
> Carlos
>
>
>
> El lun., 15 jul. 2019 a las 6:30, Alex Harui ()
> escribió:
>
> > Regarding naming, giving something a longer more descriptive name can
> also
> > make it harder to use and then folks start using the short name and then
> > there can be confusion again.
> >
> > AIUI, trademark issues are about confusion.  Names like "Basic" and
> > "Jewel" don't appear to have uses that could be confusing.  "Crux"
> appears
> > to be some sort of language thing for Java being brought over to JS, so
> my
> > concern is that someone may someday want Royale to support a Crux library
> > that is based on the Java thing.
> >
> > We are using MXRoyale and SparkRoyale as names for the emulations of
> > Flex's MX and Spark components.  "SwizRoyale" would be consistent,
> > especially if the goal is to emulate Swiz and potentially get more of the
> > Swiz code officially contributed to Apache Royale.  Having renamed lots
> of
> > FlexJS to Royale, I can tell you that renaming still takes time.
> >
> > My 2 cents,
> > -Alex
> >
> > On 7/12/19, 3:41 AM, "Carlos Rovira"  wrote:
> >
> > Hi Greg!
> >
> > great progress with the latest touches.
> >
> > My latest days was in Crux branch so for me is ok to do the merge I
> > think
> > we cover all the things needed like licensing and avoid name
> conflicts.
> > Even we always can improve any of those things over time. So it's ok.
> >
> > About the name: You're right, Apache Royale Crux is like other
> "parts"
> > in
> > Apache Royale, i.e Apache Royale Basic, Apache Royale Jewel, 
> just
> > a
> > convenient name to refer a concrete part of the Apache Royale
> ecosystem
> > with a bit of meaning and other bit of marketing (I plan to create
> some
> > icon for the web in the future as I did with Jewel, and we can do
> some
> > graphics and more when we reach a good point with the actual
> > documentation
> > effort). One important thing for me with the name is to make it
> > different
> > to Swiz to avoid confusion on that part: Swiz is for Flex, while Crux
> > is
> > for Royale. So if people talks about Swiz it will be clear that is
> > about
> > the project for Apache Flex, while if talks about Crux is clear that
> > is for
> > Apache Royale. The same happens at major level with Apache Flex and
> > Apache
> > Royale project.
> >
> > So for me it's all ok.
> >
> > Thanks for the hard work in this regard Greg!
> >
> > Carlos
> >
> >
> >
> >
> >
> >
> > El vie., 12 jul. 2019 a las 9:31, Piotr Zarzycki (<

Re: Crux Branch

[Piotr Zarzycki]

Definitely I will get back to the discussion whether we are ready or not
for 1.0 once I release 0.9.6.

śr., 17 lip 2019 o 10:36 Carlos Rovira  napisał(a):

> Piotr,
>
> my guess around low adoption by old flex users and new users is that we are
> still behind 1.0 and docs are still on the works.
> When we get to pass that point we'll be able to be more aggressive in
> communication efforts. I mean try to be exposed in publications
> specialized webs, and more. But the key point to do so is when we have
> Royale SDK and NPM publications be super easy to use and most
> people coming does not need too much effort to be up and running with
> royale.
>
> it's like putting a rocket into orbit, everything depends on getting out of
> the stratosphere. I think we are very close to that point, but there are
> still a few months to reach 1.0 and be able to invest time that way. If we
> do it before, we can create the inverse effect on new users.
>
> On the other hand, cases like the one you expose are from people who are
> very outside Flex and do not even follow it. Therefore he does not know
> anything about FlexJS and Royale changes. For that type of people the
> important thing would be that when they search in google for things like
> "apache flex to html" Apache Royale appears directly to them, something
> that does not happen right now. In opposite, If you search "apache flex
> migration" we appear first place thanks to [1]. But maybe that page should
> be revisited to make it behave as a starting point for people reaching to
> Royale.
>
> just my 2
>
> [1]
>
> https://apache.github.io/royale-docs/create-an-application/migrate-an-existing-app/migrate-from-flex.html
>
>
>
> El mié., 17 jul. 2019 a las 9:42, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>)
> escribió:
>
> > The reality is showing that since this project exists I don't see any
> > single user who came from JS/.NET/Java world to our framework. Everyone
> who
> > are interested are from Flex/ActionScript world. At the beginning the
> > strategy with name changing was great, but it shows that is not working
> or
> > even worse some people are still lost and don't know that Royale exists -
> > even if they are from Flex world. [1]
> >
> > Crux is a great name, but if there is a word "marketing" attached to this
> > discussion - +1 for Swiz still, cause it takes an attention to us and
> this
> > is exactly what we need. More new fresh blood here which really help us
> > with new features.
> >
> > [1]
> >
> >
> http://apache-flex-development.247.n4.nabble.com/Update-for-FlexJS-Falcon-JX-td65654.html
> >
> > śr., 17 lip 2019 o 09:30 Carlos Rovira 
> > napisał(a):
> >
> > > Hi Yishay,
> > >
> > > El mié., 17 jul. 2019 a las 8:05, Yishay Weiss (<
> yishayj...@hotmail.com
> > >)
> > > escribió:
> > >
> > > >
> > > > It’s true we wanted a separated identity, but as I recall we always
> had
> > > In
> > > > mind to engage the Flex user base. I think it’s important to consider
> > > that
> > > > when deciding on a name.
> > > >
> > > >
> > > My point when I pushed the change to Royale name was to try to start
> from
> > > scratch. I thought at that time (and continue doing so) that we have a
> > > great technology that can be considered new by itself. It just comes
> from
> > > old concepts (Flex) but brings new "old" ones (HTML) to the stage to
> make
> > > something with its own identity. So doing a name change to Royale name
> > (and
> > > concept) and then making other parts still be in the old strategy seems
> > > strange to me and makes me think that the marketing purpose is not
> > > understood what could be a problem with my way of doing things,
> community
> > > does not understand it or does not care much or a mix of both.
> > >
> > > People coming from Flex, will start to dig into website, docs and other
> > > things and if they was intererested in Swiz, they will read that Crux
> is
> > > what they need. The same as people that comes from Flash now that now
> is
> > > Adobe Animate. But for people new or coming from HTML (or that ears
> > > something about Flash declining), they will see another piece in a
> > > ecosystem called Royale that is part of a whole, and can choose to use
> it
> > > or not...
> > >
> > > >
> > > >
> > > > I appreciate your efforts in that regard and am sure everyone else
> > does.
> > > I
> > > > don’t think having reservations about a name is a criticism of your
> > > efforts.
> > > >
> > >
> > > Thanks for your words Yishay, good to know. Is not about reservations
> > for a
> > > concrete name, but for a strategy of doing things. I expressed that it
> > > could not be "Crux", any other name with some features could fit right.
> > My
> > > observations are just to take the kind of name that disrupts the type
> of
> > > effort we are doing in terms of brand and we decided to change a long
> > time
> > > ago.
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
> >
> > --
> >
> > Piotr 

Re: Crux Branch

[Carlos Rovira]

Piotr,

my guess around low adoption by old flex users and new users is that we are
still behind 1.0 and docs are still on the works.
When we get to pass that point we'll be able to be more aggressive in
communication efforts. I mean try to be exposed in publications
specialized webs, and more. But the key point to do so is when we have
Royale SDK and NPM publications be super easy to use and most
people coming does not need too much effort to be up and running with
royale.

it's like putting a rocket into orbit, everything depends on getting out of
the stratosphere. I think we are very close to that point, but there are
still a few months to reach 1.0 and be able to invest time that way. If we
do it before, we can create the inverse effect on new users.

On the other hand, cases like the one you expose are from people who are
very outside Flex and do not even follow it. Therefore he does not know
anything about FlexJS and Royale changes. For that type of people the
important thing would be that when they search in google for things like
"apache flex to html" Apache Royale appears directly to them, something
that does not happen right now. In opposite, If you search "apache flex
migration" we appear first place thanks to [1]. But maybe that page should
be revisited to make it behave as a starting point for people reaching to
Royale.

just my 2

[1]
https://apache.github.io/royale-docs/create-an-application/migrate-an-existing-app/migrate-from-flex.html



El mié., 17 jul. 2019 a las 9:42, Piotr Zarzycki ()
escribió:

> The reality is showing that since this project exists I don't see any
> single user who came from JS/.NET/Java world to our framework. Everyone who
> are interested are from Flex/ActionScript world. At the beginning the
> strategy with name changing was great, but it shows that is not working or
> even worse some people are still lost and don't know that Royale exists -
> even if they are from Flex world. [1]
>
> Crux is a great name, but if there is a word "marketing" attached to this
> discussion - +1 for Swiz still, cause it takes an attention to us and this
> is exactly what we need. More new fresh blood here which really help us
> with new features.
>
> [1]
>
> http://apache-flex-development.247.n4.nabble.com/Update-for-FlexJS-Falcon-JX-td65654.html
>
> śr., 17 lip 2019 o 09:30 Carlos Rovira 
> napisał(a):
>
> > Hi Yishay,
> >
> > El mié., 17 jul. 2019 a las 8:05, Yishay Weiss ( >)
> > escribió:
> >
> > >
> > > It’s true we wanted a separated identity, but as I recall we always had
> > In
> > > mind to engage the Flex user base. I think it’s important to consider
> > that
> > > when deciding on a name.
> > >
> > >
> > My point when I pushed the change to Royale name was to try to start from
> > scratch. I thought at that time (and continue doing so) that we have a
> > great technology that can be considered new by itself. It just comes from
> > old concepts (Flex) but brings new "old" ones (HTML) to the stage to make
> > something with its own identity. So doing a name change to Royale name
> (and
> > concept) and then making other parts still be in the old strategy seems
> > strange to me and makes me think that the marketing purpose is not
> > understood what could be a problem with my way of doing things, community
> > does not understand it or does not care much or a mix of both.
> >
> > People coming from Flex, will start to dig into website, docs and other
> > things and if they was intererested in Swiz, they will read that Crux is
> > what they need. The same as people that comes from Flash now that now is
> > Adobe Animate. But for people new or coming from HTML (or that ears
> > something about Flash declining), they will see another piece in a
> > ecosystem called Royale that is part of a whole, and can choose to use it
> > or not...
> >
> > >
> > >
> > > I appreciate your efforts in that regard and am sure everyone else
> does.
> > I
> > > don’t think having reservations about a name is a criticism of your
> > efforts.
> > >
> >
> > Thanks for your words Yishay, good to know. Is not about reservations
> for a
> > concrete name, but for a strategy of doing things. I expressed that it
> > could not be "Crux", any other name with some features could fit right.
> My
> > observations are just to take the kind of name that disrupts the type of
> > effort we are doing in terms of brand and we decided to change a long
> time
> > ago.
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>


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

Re: Crux Branch

[Piotr Zarzycki]

The reality is showing that since this project exists I don't see any
single user who came from JS/.NET/Java world to our framework. Everyone who
are interested are from Flex/ActionScript world. At the beginning the
strategy with name changing was great, but it shows that is not working or
even worse some people are still lost and don't know that Royale exists -
even if they are from Flex world. [1]

Crux is a great name, but if there is a word "marketing" attached to this
discussion - +1 for Swiz still, cause it takes an attention to us and this
is exactly what we need. More new fresh blood here which really help us
with new features.

[1]
http://apache-flex-development.247.n4.nabble.com/Update-for-FlexJS-Falcon-JX-td65654.html

śr., 17 lip 2019 o 09:30 Carlos Rovira  napisał(a):

> Hi Yishay,
>
> El mié., 17 jul. 2019 a las 8:05, Yishay Weiss ()
> escribió:
>
> >
> > It’s true we wanted a separated identity, but as I recall we always had
> In
> > mind to engage the Flex user base. I think it’s important to consider
> that
> > when deciding on a name.
> >
> >
> My point when I pushed the change to Royale name was to try to start from
> scratch. I thought at that time (and continue doing so) that we have a
> great technology that can be considered new by itself. It just comes from
> old concepts (Flex) but brings new "old" ones (HTML) to the stage to make
> something with its own identity. So doing a name change to Royale name (and
> concept) and then making other parts still be in the old strategy seems
> strange to me and makes me think that the marketing purpose is not
> understood what could be a problem with my way of doing things, community
> does not understand it or does not care much or a mix of both.
>
> People coming from Flex, will start to dig into website, docs and other
> things and if they was intererested in Swiz, they will read that Crux is
> what they need. The same as people that comes from Flash now that now is
> Adobe Animate. But for people new or coming from HTML (or that ears
> something about Flash declining), they will see another piece in a
> ecosystem called Royale that is part of a whole, and can choose to use it
> or not...
>
> >
> >
> > I appreciate your efforts in that regard and am sure everyone else does.
> I
> > don’t think having reservations about a name is a criticism of your
> efforts.
> >
>
> Thanks for your words Yishay, good to know. Is not about reservations for a
> concrete name, but for a strategy of doing things. I expressed that it
> could not be "Crux", any other name with some features could fit right. My
> observations are just to take the kind of name that disrupts the type of
> effort we are doing in terms of brand and we decided to change a long time
> ago.
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 

Piotr Zarzycki

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

Re: Crux Branch

[Carlos Rovira]

Hi Yishay,

El mié., 17 jul. 2019 a las 8:05, Yishay Weiss ()
escribió:

>
> It’s true we wanted a separated identity, but as I recall we always had In
> mind to engage the Flex user base. I think it’s important to consider that
> when deciding on a name.
>
>
My point when I pushed the change to Royale name was to try to start from
scratch. I thought at that time (and continue doing so) that we have a
great technology that can be considered new by itself. It just comes from
old concepts (Flex) but brings new "old" ones (HTML) to the stage to make
something with its own identity. So doing a name change to Royale name (and
concept) and then making other parts still be in the old strategy seems
strange to me and makes me think that the marketing purpose is not
understood what could be a problem with my way of doing things, community
does not understand it or does not care much or a mix of both.

People coming from Flex, will start to dig into website, docs and other
things and if they was intererested in Swiz, they will read that Crux is
what they need. The same as people that comes from Flash now that now is
Adobe Animate. But for people new or coming from HTML (or that ears
something about Flash declining), they will see another piece in a
ecosystem called Royale that is part of a whole, and can choose to use it
or not...

>
>
> I appreciate your efforts in that regard and am sure everyone else does. I
> don’t think having reservations about a name is a criticism of your efforts.
>

Thanks for your words Yishay, good to know. Is not about reservations for a
concrete name, but for a strategy of doing things. I expressed that it
could not be "Crux", any other name with some features could fit right. My
observations are just to take the kind of name that disrupts the type of
effort we are doing in terms of brand and we decided to change a long time
ago.

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

RE: Crux Branch

[Yishay Weiss]

Hi Carlos,


>So for me is something to market with the rest of Royale (strand, beads,
>jewel,...) that we decided together to separate from the marketing of Flex.

It’s true we wanted a separated identity, but as I recall we always had In mind 
to engage the Flex user base. I think it’s important to consider that when 
deciding on a name.

>In the end I think is more important to me to know if we (and I in
>concrete) are doing right investing time trying to make website / docs /
>examples / jewel themes ... with a design based on marketing guidelines to
>get some feeling of uniqueness or is useless or not valuable. Maybe I'm
>blinded by what I see and only I see it and in that case it would not make
>any sense so many hours chasing that kind of goal since it'll does not fit
>any community need out there.

I appreciate your efforts in that regard and am sure everyone else does. I 
don’t think having reservations about a name is a criticism of your efforts.

Thanks,
Yishay


El mar., 16 jul. 2019 a las 8:45, Greg Dove ()
escribió:

> Alex,
>
> I think that java framework is unlikely to be important for the same
> reasons you give for 3rd party Basic or Jewel.
> Firstly I don't think it has been widely used.
> Although it is never a perfect assessment, I tend to look at things like
> that by first checking how active they are (commits, issues etc as a
> project) and also how popular they are (in the absence of more stringent
> criteria, this is my same 'rule of thumb' for choosing an npm library these
> days too)
> That project does not appear to be active for at least 3 years (whatever
> type of activity you look at), and has a low star-rating and fork count.
> Secondly, and perhaps more importantly, iiuc that project is more of an
> alternative to Royale than it is something that would be ported to Royale.
> It looks to be a way to write web apps in java with xml-based component
> definitions.
> So (assuming that is correct), I do consider the risk of any confusion here
> is extremely low based on how popular/active it is and also on (my
> understanding of) what it does.
>
> In terms of effort etc...
> I was only vaguely aware of Swiz before I worked with Carlos, I had only
> used PureMVC, Parsley and Robotlegs previously. So I can say outright that
> I approached this without any prior knowledge of Swiz.
> Firstly, for the 'porting' aspect, we are only talking about the volume of
> Swiz-based Flex apps that have not yet been migrated to some other
> platform. We have no way of knowing how many that is. It may not be that
> large, and I think Carlos is thinking more about the value of having 'Crux'
> marketing to support future applications being built with Royale, to help
> drive demand for Royale in general. Carlos will need to confirm that, but
> it was my impression.
> For people who are porting a legacy app, whether someone uses Crux in
> Royale or Swiz in Flex it is essentially the same effort, there is really
> no meaningful impact on the user for the name change, because the
> difference is the configuration at app level, which in Royale is by
> application bead. So I think the name change will have no meaningful impact
> on the porting of any Swiz based Flex apps. I know this in part because I
> already worked on the port of Carlos's original Swiz-based Flex app (it is
> not yet fully ported for Swiz->Crux, and was originally ported to Royale
> with workarounds for anything Swiz-like, but I have since tested services
> setup and login/logout UI flow with Crux using his Royale app to get some
> real-world testing done).
>
> Apart from that, I believe that Swiz originally took inspiration from the
> (java) Spring framework, so (although I never used Spring myself) I
> understand that the general concepts (e.g. 'Beans' which is a core
> concept) and principles for dependency injection and IoC are inspired by
> Spring in the first place.
> My understanding of the main rationale for the name change is for marketing
> purposes, which Carlos is willing to devote time and effort to. It is more
> a focus on the future, in the same way I think that FlexJS became Royale
> even though it is still based on the same thing. If Carlos is prepared to
> do build branding and help create demand for Royale (via 'Crux' in this
> case), then I think we should allow him to do so and trust his judgment on
> this, because of what he has done so far in other ways, and because I think
> he is willing to put more effort in on that aspect than most of us
> (although I can only speak with certainty for myself).
> If Royale is to be successful, it will not be enough to simply 'build it
> and they will come', so I say let him go for it. As long as there are no
> risks with the naming (which so far I think there are not), I don't see any
> downsides here.
> Outside of those points, I can only state that I personally don't mind what
> the name is, although the name 'Crux' has 'grown on me'.
>
> I was planning to merge 'crux' in 

Re: Crux Branch

[Greg Dove]

Ok thanks for clarifying Carlos, I will merge into develop as-is (with
required updates following Josh's changes) later today.


On Tue, Jul 16, 2019 at 8:05 PM Carlos Rovira 
wrote:

> Hi Greg,
>
> agree with all you say.
>
> As a user of Swiz on Flex, I know Swiz was a "sub-framework" and used by a
> "subset" of teams and developers in the world. So in the end is a piece of
> software needed, for using Royale in big projects, but for migration from
> Flex I expect few devs/teams, since that implies they was using Swiz
> instead of Cairngorm/Parsley/PureMVC/RobotLegs/Mate or the miriad of other
> arquitecturas like this.
>
> For me Crux like Jewel is needed to do modern Royale development for the
> old and new devices (and after doing a first app and having to do lots of
> workarounds to solve organizational/structural issues as we growed).
>
> So for me is something to market with the rest of Royale (strand, beads,
> jewel,...) that we decided together to separate from the marketing of Flex.
>
> As Greg said my main point with renaming is to create other things like an
> icon, examples, and continue effort on website, but if folks think this is
> not important, then we can go with Swiz or SwizRoyale and let all like
> that, but certainly that will not be very appealing to me to invest time on
> creating material for something that is off the overall marketing effort.
>
> In exchange, I prefer completely something fresh like "Crux", for all the
> reasons I already exposed, but as I said, although I don't want
> "Swiz/SwizRoyale", I think it shouldn't be "Crux" 100%. I can understand
> folks here could want to propose other naming options and just have in mind
> things like meaning, shortness and other marketing things with what we can
> work in create material around this new Royale piece.
>
> In the end I think is more important to me to know if we (and I in
> concrete) are doing right investing time trying to make website / docs /
> examples / jewel themes ... with a design based on marketing guidelines to
> get some feeling of uniqueness or is useless or not valuable. Maybe I'm
> blinded by what I see and only I see it and in that case it would not make
> any sense so many hours chasing that kind of goal since it'll does not fit
> any community need out there.
>
> About Merging: Greg, I think you should not wait for that, since any
> decision we make can be done in develop in a new commit easily, either we
> decide to left as is, try to choose a new name or change it to
> Swiz/SwizRoyale options.
>
> Thanks
>
>
>
> El mar., 16 jul. 2019 a las 8:45, Greg Dove ()
> escribió:
>
> > Alex,
> >
> > I think that java framework is unlikely to be important for the same
> > reasons you give for 3rd party Basic or Jewel.
> > Firstly I don't think it has been widely used.
> > Although it is never a perfect assessment, I tend to look at things like
> > that by first checking how active they are (commits, issues etc as a
> > project) and also how popular they are (in the absence of more stringent
> > criteria, this is my same 'rule of thumb' for choosing an npm library
> these
> > days too)
> > That project does not appear to be active for at least 3 years (whatever
> > type of activity you look at), and has a low star-rating and fork count.
> > Secondly, and perhaps more importantly, iiuc that project is more of an
> > alternative to Royale than it is something that would be ported to
> Royale.
> > It looks to be a way to write web apps in java with xml-based component
> > definitions.
> > So (assuming that is correct), I do consider the risk of any confusion
> here
> > is extremely low based on how popular/active it is and also on (my
> > understanding of) what it does.
> >
> > In terms of effort etc...
> > I was only vaguely aware of Swiz before I worked with Carlos, I had only
> > used PureMVC, Parsley and Robotlegs previously. So I can say outright
> that
> > I approached this without any prior knowledge of Swiz.
> > Firstly, for the 'porting' aspect, we are only talking about the volume
> of
> > Swiz-based Flex apps that have not yet been migrated to some other
> > platform. We have no way of knowing how many that is. It may not be that
> > large, and I think Carlos is thinking more about the value of having
> 'Crux'
> > marketing to support future applications being built with Royale, to help
> > drive demand for Royale in general. Carlos will need to confirm that, but
> > it was my impression.
> > For people who are porting a legacy app, whether someone uses Crux in
> > Royale or Swiz in Flex it is essentially the same effort, there is really
> > no meaningful impact on the user for the name change, because the
> > difference is the configuration at app level, which in Royale is by
> > application bead. So I think the name change will have no meaningful
> impact
> > on the porting of any Swiz based Flex apps. I know this in part because I
> > already worked on the port of Carlos's original Swiz-based Flex 

Re: Crux Branch

[Carlos Rovira]

Hi Greg,

agree with all you say.

As a user of Swiz on Flex, I know Swiz was a "sub-framework" and used by a
"subset" of teams and developers in the world. So in the end is a piece of
software needed, for using Royale in big projects, but for migration from
Flex I expect few devs/teams, since that implies they was using Swiz
instead of Cairngorm/Parsley/PureMVC/RobotLegs/Mate or the miriad of other
arquitecturas like this.

For me Crux like Jewel is needed to do modern Royale development for the
old and new devices (and after doing a first app and having to do lots of
workarounds to solve organizational/structural issues as we growed).

So for me is something to market with the rest of Royale (strand, beads,
jewel,...) that we decided together to separate from the marketing of Flex.

As Greg said my main point with renaming is to create other things like an
icon, examples, and continue effort on website, but if folks think this is
not important, then we can go with Swiz or SwizRoyale and let all like
that, but certainly that will not be very appealing to me to invest time on
creating material for something that is off the overall marketing effort.

In exchange, I prefer completely something fresh like "Crux", for all the
reasons I already exposed, but as I said, although I don't want
"Swiz/SwizRoyale", I think it shouldn't be "Crux" 100%. I can understand
folks here could want to propose other naming options and just have in mind
things like meaning, shortness and other marketing things with what we can
work in create material around this new Royale piece.

In the end I think is more important to me to know if we (and I in
concrete) are doing right investing time trying to make website / docs /
examples / jewel themes ... with a design based on marketing guidelines to
get some feeling of uniqueness or is useless or not valuable. Maybe I'm
blinded by what I see and only I see it and in that case it would not make
any sense so many hours chasing that kind of goal since it'll does not fit
any community need out there.

About Merging: Greg, I think you should not wait for that, since any
decision we make can be done in develop in a new commit easily, either we
decide to left as is, try to choose a new name or change it to
Swiz/SwizRoyale options.

Thanks



El mar., 16 jul. 2019 a las 8:45, Greg Dove ()
escribió:

> Alex,
>
> I think that java framework is unlikely to be important for the same
> reasons you give for 3rd party Basic or Jewel.
> Firstly I don't think it has been widely used.
> Although it is never a perfect assessment, I tend to look at things like
> that by first checking how active they are (commits, issues etc as a
> project) and also how popular they are (in the absence of more stringent
> criteria, this is my same 'rule of thumb' for choosing an npm library these
> days too)
> That project does not appear to be active for at least 3 years (whatever
> type of activity you look at), and has a low star-rating and fork count.
> Secondly, and perhaps more importantly, iiuc that project is more of an
> alternative to Royale than it is something that would be ported to Royale.
> It looks to be a way to write web apps in java with xml-based component
> definitions.
> So (assuming that is correct), I do consider the risk of any confusion here
> is extremely low based on how popular/active it is and also on (my
> understanding of) what it does.
>
> In terms of effort etc...
> I was only vaguely aware of Swiz before I worked with Carlos, I had only
> used PureMVC, Parsley and Robotlegs previously. So I can say outright that
> I approached this without any prior knowledge of Swiz.
> Firstly, for the 'porting' aspect, we are only talking about the volume of
> Swiz-based Flex apps that have not yet been migrated to some other
> platform. We have no way of knowing how many that is. It may not be that
> large, and I think Carlos is thinking more about the value of having 'Crux'
> marketing to support future applications being built with Royale, to help
> drive demand for Royale in general. Carlos will need to confirm that, but
> it was my impression.
> For people who are porting a legacy app, whether someone uses Crux in
> Royale or Swiz in Flex it is essentially the same effort, there is really
> no meaningful impact on the user for the name change, because the
> difference is the configuration at app level, which in Royale is by
> application bead. So I think the name change will have no meaningful impact
> on the porting of any Swiz based Flex apps. I know this in part because I
> already worked on the port of Carlos's original Swiz-based Flex app (it is
> not yet fully ported for Swiz->Crux, and was originally ported to Royale
> with workarounds for anything Swiz-like, but I have since tested services
> setup and login/logout UI flow with Crux using his Royale app to get some
> real-world testing done).
>
> Apart from that, I believe that Swiz originally took inspiration from the
> (java) Spring 

Re: Crux Branch

[Greg Dove]

Alex,

I think that java framework is unlikely to be important for the same
reasons you give for 3rd party Basic or Jewel.
Firstly I don't think it has been widely used.
Although it is never a perfect assessment, I tend to look at things like
that by first checking how active they are (commits, issues etc as a
project) and also how popular they are (in the absence of more stringent
criteria, this is my same 'rule of thumb' for choosing an npm library these
days too)
That project does not appear to be active for at least 3 years (whatever
type of activity you look at), and has a low star-rating and fork count.
Secondly, and perhaps more importantly, iiuc that project is more of an
alternative to Royale than it is something that would be ported to Royale.
It looks to be a way to write web apps in java with xml-based component
definitions.
So (assuming that is correct), I do consider the risk of any confusion here
is extremely low based on how popular/active it is and also on (my
understanding of) what it does.

In terms of effort etc...
I was only vaguely aware of Swiz before I worked with Carlos, I had only
used PureMVC, Parsley and Robotlegs previously. So I can say outright that
I approached this without any prior knowledge of Swiz.
Firstly, for the 'porting' aspect, we are only talking about the volume of
Swiz-based Flex apps that have not yet been migrated to some other
platform. We have no way of knowing how many that is. It may not be that
large, and I think Carlos is thinking more about the value of having 'Crux'
marketing to support future applications being built with Royale, to help
drive demand for Royale in general. Carlos will need to confirm that, but
it was my impression.
For people who are porting a legacy app, whether someone uses Crux in
Royale or Swiz in Flex it is essentially the same effort, there is really
no meaningful impact on the user for the name change, because the
difference is the configuration at app level, which in Royale is by
application bead. So I think the name change will have no meaningful impact
on the porting of any Swiz based Flex apps. I know this in part because I
already worked on the port of Carlos's original Swiz-based Flex app (it is
not yet fully ported for Swiz->Crux, and was originally ported to Royale
with workarounds for anything Swiz-like, but I have since tested services
setup and login/logout UI flow with Crux using his Royale app to get some
real-world testing done).

Apart from that, I believe that Swiz originally took inspiration from the
(java) Spring framework, so (although I never used Spring myself) I
understand that the general concepts (e.g. 'Beans' which is a core
concept) and principles for dependency injection and IoC are inspired by
Spring in the first place.
My understanding of the main rationale for the name change is for marketing
purposes, which Carlos is willing to devote time and effort to. It is more
a focus on the future, in the same way I think that FlexJS became Royale
even though it is still based on the same thing. If Carlos is prepared to
do build branding and help create demand for Royale (via 'Crux' in this
case), then I think we should allow him to do so and trust his judgment on
this, because of what he has done so far in other ways, and because I think
he is willing to put more effort in on that aspect than most of us
(although I can only speak with certainty for myself).
If Royale is to be successful, it will not be enough to simply 'build it
and they will come', so I say let him go for it. As long as there are no
risks with the naming (which so far I think there are not), I don't see any
downsides here.
Outside of those points, I can only state that I personally don't mind what
the name is, although the name 'Crux' has 'grown on me'.

I was planning to merge 'crux' in today, but I will hold off for now I
guess. Basically it is ready to merge as is (pending changes after Josh's
latest updates)



On Tue, Jul 16, 2019 at 4:14 PM Alex Harui  wrote:

> Hi Carlos,
>
> I don't think you understood my point.  Probably every good name has been
> used on GitHub or soon will be.  Even Royale was.  The question is whether
> anyone would want to see some other 3rd-party Jewel or Basic library
> implemented in Royale.  I suspect it is unlikely.
>
> "Crux" for Java appears to be some sort of web-app productivity framework.
> http://www.cruxframework.org/?locale=en_US#!view=home
> So there is a higher probability that if Royale becomes very popular that
> someone might want to see Crux for Java APIs ported to JS, similar to Java
> Commons vs AS3 Commons.
>
> Regarding the use of "Swiz" as the name, I haven't looked at the code Greg
> did, but if the APIs are the same and the general principles of dependency
> injection are the same, then I don't understand why we want to say that
> "Swiz" is for Flex and "XXX is for Royale".  As every day ticks off the
> calendar towards 2020, I think we want to do what we can to reduce the
> amount 

Re: Crux Branch

[Alex Harui]

Hi Carlos,

I don't think you understood my point.  Probably every good name has been used 
on GitHub or soon will be.  Even Royale was.  The question is whether anyone 
would want to see some other 3rd-party Jewel or Basic library implemented in 
Royale.  I suspect it is unlikely.

"Crux" for Java appears to be some sort of web-app productivity framework. 
http://www.cruxframework.org/?locale=en_US#!view=home
So there is a higher probability that if Royale becomes very popular that 
someone might want to see Crux for Java APIs ported to JS, similar to Java 
Commons vs AS3 Commons.

Regarding the use of "Swiz" as the name, I haven't looked at the code Greg did, 
but if the APIs are the same and the general principles of dependency injection 
are the same, then I don't understand why we want to say that "Swiz" is for 
Flex and "XXX is for Royale".  As every day ticks off the calendar towards 
2020, I think we want to do what we can to reduce the amount of time/effort to 
migrate a Flex app to Royale, and renaming something just adds to the effort 
instead of reducing it, IMO.

My 2 cents,
-Alex

On 7/15/19, 1:58 AM, "Carlos Rovira"  wrote:

Hi Alex,

your concerns about Crux name applies to the others like Basic or Jewel
(just to name a few). If I search for "Jewel js" in google I get various
Jewel libraries (same for Basic js). What makes Jewel appropriate for us is
that is an internal name (internal branding) we use to refer to that
concrete part of the entire Royale framework, so in then end is not about
"jewel" for folks here their brain knows that we are talking all the time
about "Apache Royale Jewel". One more thing we add using this kind of names
is: 1) Names that has some marketing, and we can create icons, or more (it
will be hard for me create a icon for FlexJS or SwizRoyale), 2) short names
with some meaning inside the ecosystem and relation with a set of words
that shares some meaning root. And moreover, since we changed to Royale
name we are doing all the things in the same line of action what makes the
naming decisions in Royale follow a strategy. It would be not consistent to
come back to older name strategy like FlexJS or SwizRoyale. We should
follow what we started and continue in that line.

I must say I never thought in MXRoyale and SparkRoyale naming, since it was
a work in progress that started to grow in Royale progressively and I was
focused in other parts. For that cases, we could bring other names or not.
I must say that I didn't take much time to think about it conceptually. We
could do or not depending on what you want to do in that part.

For Jewel, we didn't thought about it so much. I remember I started with
other codename, but very soon I renamed and shared to Jewel explaining the
motivations, thoughts, and meaning of that name. But, we didn't some king
of name process for it

In the case of Crux. I think it could not be "Crux",I like for the
shortness and meaning, but could be other better options. What I don't like
is bring as "Swiz" or "SwizRoyale". The first because is not Swiz (as I
explained Swiz is for Flex) and SwizRoyale is for me very long and does not
have a meaning inside of what we are doing with the rest of Royale naming
decision and marketing (making it very difficult to brand along with the
rest of Royale parts for marketing and web).

just my 2

Carlos



El lun., 15 jul. 2019 a las 6:30, Alex Harui ()
escribió:

> Regarding naming, giving something a longer more descriptive name can also
> make it harder to use and then folks start using the short name and then
> there can be confusion again.
>
> AIUI, trademark issues are about confusion.  Names like "Basic" and
> "Jewel" don't appear to have uses that could be confusing.  "Crux" appears
> to be some sort of language thing for Java being brought over to JS, so my
> concern is that someone may someday want Royale to support a Crux library
> that is based on the Java thing.
>
> We are using MXRoyale and SparkRoyale as names for the emulations of
> Flex's MX and Spark components.  "SwizRoyale" would be consistent,
> especially if the goal is to emulate Swiz and potentially get more of the
> Swiz code officially contributed to Apache Royale.  Having renamed lots of
> FlexJS to Royale, I can tell you that renaming still takes time.
>
> My 2 cents,
> -Alex
>
> On 7/12/19, 3:41 AM, "Carlos Rovira"  wrote:
>
> Hi Greg!
>
> great progress with the latest touches.
>
> My latest days was in Crux branch so for me is ok to do the merge I
> think
> we cover all the things needed like licensing and avoid name 
conflicts.
> Even we always can improve any of those things over time. So it's ok.
>
>

Re: Crux Branch

[Carlos Rovira]

Hi Alex,

your concerns about Crux name applies to the others like Basic or Jewel
(just to name a few). If I search for "Jewel js" in google I get various
Jewel libraries (same for Basic js). What makes Jewel appropriate for us is
that is an internal name (internal branding) we use to refer to that
concrete part of the entire Royale framework, so in then end is not about
"jewel" for folks here their brain knows that we are talking all the time
about "Apache Royale Jewel". One more thing we add using this kind of names
is: 1) Names that has some marketing, and we can create icons, or more (it
will be hard for me create a icon for FlexJS or SwizRoyale), 2) short names
with some meaning inside the ecosystem and relation with a set of words
that shares some meaning root. And moreover, since we changed to Royale
name we are doing all the things in the same line of action what makes the
naming decisions in Royale follow a strategy. It would be not consistent to
come back to older name strategy like FlexJS or SwizRoyale. We should
follow what we started and continue in that line.

I must say I never thought in MXRoyale and SparkRoyale naming, since it was
a work in progress that started to grow in Royale progressively and I was
focused in other parts. For that cases, we could bring other names or not.
I must say that I didn't take much time to think about it conceptually. We
could do or not depending on what you want to do in that part.

For Jewel, we didn't thought about it so much. I remember I started with
other codename, but very soon I renamed and shared to Jewel explaining the
motivations, thoughts, and meaning of that name. But, we didn't some king
of name process for it

In the case of Crux. I think it could not be "Crux",I like for the
shortness and meaning, but could be other better options. What I don't like
is bring as "Swiz" or "SwizRoyale". The first because is not Swiz (as I
explained Swiz is for Flex) and SwizRoyale is for me very long and does not
have a meaning inside of what we are doing with the rest of Royale naming
decision and marketing (making it very difficult to brand along with the
rest of Royale parts for marketing and web).

just my 2

Carlos



El lun., 15 jul. 2019 a las 6:30, Alex Harui ()
escribió:

> Regarding naming, giving something a longer more descriptive name can also
> make it harder to use and then folks start using the short name and then
> there can be confusion again.
>
> AIUI, trademark issues are about confusion.  Names like "Basic" and
> "Jewel" don't appear to have uses that could be confusing.  "Crux" appears
> to be some sort of language thing for Java being brought over to JS, so my
> concern is that someone may someday want Royale to support a Crux library
> that is based on the Java thing.
>
> We are using MXRoyale and SparkRoyale as names for the emulations of
> Flex's MX and Spark components.  "SwizRoyale" would be consistent,
> especially if the goal is to emulate Swiz and potentially get more of the
> Swiz code officially contributed to Apache Royale.  Having renamed lots of
> FlexJS to Royale, I can tell you that renaming still takes time.
>
> My 2 cents,
> -Alex
>
> On 7/12/19, 3:41 AM, "Carlos Rovira"  wrote:
>
> Hi Greg!
>
> great progress with the latest touches.
>
> My latest days was in Crux branch so for me is ok to do the merge I
> think
> we cover all the things needed like licensing and avoid name conflicts.
> Even we always can improve any of those things over time. So it's ok.
>
> About the name: You're right, Apache Royale Crux is like other "parts"
> in
> Apache Royale, i.e Apache Royale Basic, Apache Royale Jewel,  just
> a
> convenient name to refer a concrete part of the Apache Royale ecosystem
> with a bit of meaning and other bit of marketing (I plan to create some
> icon for the web in the future as I did with Jewel, and we can do some
> graphics and more when we reach a good point with the actual
> documentation
> effort). One important thing for me with the name is to make it
> different
> to Swiz to avoid confusion on that part: Swiz is for Flex, while Crux
> is
> for Royale. So if people talks about Swiz it will be clear that is
> about
> the project for Apache Flex, while if talks about Crux is clear that
> is for
> Apache Royale. The same happens at major level with Apache Flex and
> Apache
> Royale project.
>
> So for me it's all ok.
>
> Thanks for the hard work in this regard Greg!
>
> Carlos
>
>
>
>
>
>
> El vie., 12 jul. 2019 a las 9:31, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>)
> escribió:
>
> > Hi Greg,
> >
> > Thanks for update. I'm having again more important tasks and that is
> why I
> > didn't start release process yet. It looks like I will have for sure
> 2 full
> > working days to start process on upcoming Wednesday. If you make it
> till
> > that time it would be great, if not let's stay on the 

Re: Crux Branch

[Alex Harui]

Regarding naming, giving something a longer more descriptive name can also make 
it harder to use and then folks start using the short name and then there can 
be confusion again.

AIUI, trademark issues are about confusion.  Names like "Basic" and "Jewel" 
don't appear to have uses that could be confusing.  "Crux" appears to be some 
sort of language thing for Java being brought over to JS, so my concern is that 
someone may someday want Royale to support a Crux library that is based on the 
Java thing.

We are using MXRoyale and SparkRoyale as names for the emulations of Flex's MX 
and Spark components.  "SwizRoyale" would be consistent, especially if the goal 
is to emulate Swiz and potentially get more of the Swiz code officially 
contributed to Apache Royale.  Having renamed lots of FlexJS to Royale, I can 
tell you that renaming still takes time.

My 2 cents,
-Alex

On 7/12/19, 3:41 AM, "Carlos Rovira"  wrote:

Hi Greg!

great progress with the latest touches.

My latest days was in Crux branch so for me is ok to do the merge I think
we cover all the things needed like licensing and avoid name conflicts.
Even we always can improve any of those things over time. So it's ok.

About the name: You're right, Apache Royale Crux is like other "parts" in
Apache Royale, i.e Apache Royale Basic, Apache Royale Jewel,  just a
convenient name to refer a concrete part of the Apache Royale ecosystem
with a bit of meaning and other bit of marketing (I plan to create some
icon for the web in the future as I did with Jewel, and we can do some
graphics and more when we reach a good point with the actual documentation
effort). One important thing for me with the name is to make it different
to Swiz to avoid confusion on that part: Swiz is for Flex, while Crux is
for Royale. So if people talks about Swiz it will be clear that is about
the project for Apache Flex, while if talks about Crux is clear that is for
Apache Royale. The same happens at major level with Apache Flex and Apache
Royale project.

So for me it's all ok.

Thanks for the hard work in this regard Greg!

Carlos






El vie., 12 jul. 2019 a las 9:31, Piotr Zarzycki 
()
escribió:

> Hi Greg,
>
> Thanks for update. I'm having again more important tasks and that is why I
> didn't start release process yet. It looks like I will have for sure 2 
full
> working days to start process on upcoming Wednesday. If you make it till
> that time it would be great, if not let's stay on the branch.
>
> Thanks,
> Piotr
>
> pt., 12 lip 2019 o 07:26 Greg Dove  napisał(a):
>
> > Just a quick update...
> >
> > I just fixed the ant builds for the 3 simple crux examples in the 
branch,
> > which were not working yet.
> >
> > There will continue to be improvements and fixes over time, but I
> actually
> > think it's at a state where it could be merged into develop. Unless 
there
> > is a reason not to, I plan to do this by start of next week.
> > This should not impact anyone else because it is something new, there 
are
> > no changes to anything already present.
> >
> > In terms of the name as 'Crux', so far I had feedback from one person to
> > give the naming some more thought, mainly because of the possibility for
> > name conflicts with other libraries.
> > Carlos suggested to me that we should always use 'Apache Royale Crux' in
> > terms of a general reference or to introduce it for the first time, and
> > then (iirc) 'Crux' by itself only in a very clear Apache Royale context,
> > which avoids naming conflicts. As I understand it, this type of issue is
> > similar to some other things from the past.
> >
> > So far I don't see anything holding back a merge. But please let me know
> if
> > there is anything else.
> >
> > Thanks,
> > -Greg
> >
> >
> >
> > On Sat, Jul 6, 2019 at 3:35 AM Josh Tynjala 
> > wrote:
> >
> > > Interesting! I didn't know that the capture phase worked for
> non-bubbling
> > > events. Good to know. Thanks for looking into it and sharing your
> > findings,
> > > Greg.
> > >
> > > - Josh
> > >
> > >
> > > On Thu, Jul 4, 2019, 11:12 PM Greg Dove  wrote:
> > >
> > > > Hi Josh,
> > > >
> > > > For the addedToStage stuff:
> > > > You made me look! Swiz does not actually use the ADDED event, it
> > > definitely
> > > > does use ADDED_TO_STAGE by default, but you're absolutely right, 
this
> > > does
> > > > not bubble.
> > > >
> > > > I did not pay too much attention to the 'bubbling' side of things
> > > because I
> > > > could see it working in flash and just assumed that's what was
> > happening.
> > > > But it is actually being listened 

Re: Crux Branch

[Greg Dove]

Hi Josh, it's great that you're working on this. Unless I'm mistaken, there
is currently a 'manual' way to do this, which you may have already seen,
using 'exclude-defaults-css-files'

in royale-config, I believe this type of approach works:

 
MXRoyaleJS.swc:defaults.css


(I saw Carlos did this at one point in his own project, somewhat different
via maven additionalCompilerOption, and did the same in ant for the Crux
examples)


I presume it might also work with
'JewelJS.swc:defaults.css' in there, for example (I
have not specifically tested).

Just mentioning this in case it helps with the work you are doing



On Sat, Jul 13, 2019 at 5:00 AM Josh Tynjala 
wrote:

> I'm working on a fix for the CSS issue that Harbs started a thread about.
> I'm almost ready, but I have some edge cases to finish up. I feel like it's
> an important one to get into the release because it injects a lot of Jewel
> CSS into non-Jewel apps (and CSS from *several* other SWCs too). However,
> my changes may also be a little disruptive if I missed something, so it may
> take a few days to smooth out any last minute issues as people try it out
> with their existing apps.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Fri, Jul 12, 2019 at 12:31 AM Piotr Zarzycki  >
> wrote:
>
> > Hi Greg,
> >
> > Thanks for update. I'm having again more important tasks and that is why
> I
> > didn't start release process yet. It looks like I will have for sure 2
> full
> > working days to start process on upcoming Wednesday. If you make it till
> > that time it would be great, if not let's stay on the branch.
> >
> > Thanks,
> > Piotr
> >
> > pt., 12 lip 2019 o 07:26 Greg Dove  napisał(a):
> >
> > > Just a quick update...
> > >
> > > I just fixed the ant builds for the 3 simple crux examples in the
> branch,
> > > which were not working yet.
> > >
> > > There will continue to be improvements and fixes over time, but I
> > actually
> > > think it's at a state where it could be merged into develop. Unless
> there
> > > is a reason not to, I plan to do this by start of next week.
> > > This should not impact anyone else because it is something new, there
> are
> > > no changes to anything already present.
> > >
> > > In terms of the name as 'Crux', so far I had feedback from one person
> to
> > > give the naming some more thought, mainly because of the possibility
> for
> > > name conflicts with other libraries.
> > > Carlos suggested to me that we should always use 'Apache Royale Crux'
> in
> > > terms of a general reference or to introduce it for the first time, and
> > > then (iirc) 'Crux' by itself only in a very clear Apache Royale
> context,
> > > which avoids naming conflicts. As I understand it, this type of issue
> is
> > > similar to some other things from the past.
> > >
> > > So far I don't see anything holding back a merge. But please let me
> know
> > if
> > > there is anything else.
> > >
> > > Thanks,
> > > -Greg
> > >
> > >
> > >
> > > On Sat, Jul 6, 2019 at 3:35 AM Josh Tynjala  >
> > > wrote:
> > >
> > > > Interesting! I didn't know that the capture phase worked for
> > non-bubbling
> > > > events. Good to know. Thanks for looking into it and sharing your
> > > findings,
> > > > Greg.
> > > >
> > > > - Josh
> > > >
> > > >
> > > > On Thu, Jul 4, 2019, 11:12 PM Greg Dove  wrote:
> > > >
> > > > > Hi Josh,
> > > > >
> > > > > For the addedToStage stuff:
> > > > > You made me look! Swiz does not actually use the ADDED event, it
> > > > definitely
> > > > > does use ADDED_TO_STAGE by default, but you're absolutely right,
> this
> > > > does
> > > > > not bubble.
> > > > >
> > > > > I did not pay too much attention to the 'bubbling' side of things
> > > > because I
> > > > > could see it working in flash and just assumed that's what was
> > > happening.
> > > > > But it is actually being listened to as a capture phase event. And
> > that
> > > > > does give the same outward impression (without looking too closely)
> > as
> > > if
> > > > > it were bubbling in this case.
> > > > >
> > > > > I even resorted to a quick test in Adobe Animate to verify:
> > > > >
> > > > > import flash.display.Sprite;
> > > > > import flash.events.Event;
> > > > >
> > > > > var sprite:Sprite = new Sprite();
> > > > > sprite.name ='1';
> > > > > function onAdded(event:Event):void{
> > > > > trace('added' ,event.target.name)
> > > > > }
> > > > > function onRemoved(event:Event):void{
> > > > > trace('removed' ,event.target.name)
> > > > > }
> > > > >
> > > > > sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
> > > > > sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);
> > > > >
> > > > > var sprite2:Sprite = new Sprite();
> > > > > sprite2.name = '2'
> > > > >
> > > > > var sprite3:Sprite = new Sprite();
> > > > > sprite3.name = '3'
> > > > >
> > > > > addChild(sprite);
> > > > > sprite.addChild(sprite2)
> > > > >
> > > > >
> > > > > sprite2.addChild(sprite3);
> > > > >
> > > > > //remove 

Re: Crux Branch

[Josh Tynjala]

I'm working on a fix for the CSS issue that Harbs started a thread about.
I'm almost ready, but I have some edge cases to finish up. I feel like it's
an important one to get into the release because it injects a lot of Jewel
CSS into non-Jewel apps (and CSS from *several* other SWCs too). However,
my changes may also be a little disruptive if I missed something, so it may
take a few days to smooth out any last minute issues as people try it out
with their existing apps.

--
Josh Tynjala
Bowler Hat LLC 


On Fri, Jul 12, 2019 at 12:31 AM Piotr Zarzycki 
wrote:

> Hi Greg,
>
> Thanks for update. I'm having again more important tasks and that is why I
> didn't start release process yet. It looks like I will have for sure 2 full
> working days to start process on upcoming Wednesday. If you make it till
> that time it would be great, if not let's stay on the branch.
>
> Thanks,
> Piotr
>
> pt., 12 lip 2019 o 07:26 Greg Dove  napisał(a):
>
> > Just a quick update...
> >
> > I just fixed the ant builds for the 3 simple crux examples in the branch,
> > which were not working yet.
> >
> > There will continue to be improvements and fixes over time, but I
> actually
> > think it's at a state where it could be merged into develop. Unless there
> > is a reason not to, I plan to do this by start of next week.
> > This should not impact anyone else because it is something new, there are
> > no changes to anything already present.
> >
> > In terms of the name as 'Crux', so far I had feedback from one person to
> > give the naming some more thought, mainly because of the possibility for
> > name conflicts with other libraries.
> > Carlos suggested to me that we should always use 'Apache Royale Crux' in
> > terms of a general reference or to introduce it for the first time, and
> > then (iirc) 'Crux' by itself only in a very clear Apache Royale context,
> > which avoids naming conflicts. As I understand it, this type of issue is
> > similar to some other things from the past.
> >
> > So far I don't see anything holding back a merge. But please let me know
> if
> > there is anything else.
> >
> > Thanks,
> > -Greg
> >
> >
> >
> > On Sat, Jul 6, 2019 at 3:35 AM Josh Tynjala 
> > wrote:
> >
> > > Interesting! I didn't know that the capture phase worked for
> non-bubbling
> > > events. Good to know. Thanks for looking into it and sharing your
> > findings,
> > > Greg.
> > >
> > > - Josh
> > >
> > >
> > > On Thu, Jul 4, 2019, 11:12 PM Greg Dove  wrote:
> > >
> > > > Hi Josh,
> > > >
> > > > For the addedToStage stuff:
> > > > You made me look! Swiz does not actually use the ADDED event, it
> > > definitely
> > > > does use ADDED_TO_STAGE by default, but you're absolutely right, this
> > > does
> > > > not bubble.
> > > >
> > > > I did not pay too much attention to the 'bubbling' side of things
> > > because I
> > > > could see it working in flash and just assumed that's what was
> > happening.
> > > > But it is actually being listened to as a capture phase event. And
> that
> > > > does give the same outward impression (without looking too closely)
> as
> > if
> > > > it were bubbling in this case.
> > > >
> > > > I even resorted to a quick test in Adobe Animate to verify:
> > > >
> > > > import flash.display.Sprite;
> > > > import flash.events.Event;
> > > >
> > > > var sprite:Sprite = new Sprite();
> > > > sprite.name ='1';
> > > > function onAdded(event:Event):void{
> > > > trace('added' ,event.target.name)
> > > > }
> > > > function onRemoved(event:Event):void{
> > > > trace('removed' ,event.target.name)
> > > > }
> > > >
> > > > sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
> > > > sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);
> > > >
> > > > var sprite2:Sprite = new Sprite();
> > > > sprite2.name = '2'
> > > >
> > > > var sprite3:Sprite = new Sprite();
> > > > sprite3.name = '3'
> > > >
> > > > addChild(sprite);
> > > > sprite.addChild(sprite2)
> > > >
> > > >
> > > > sprite2.addChild(sprite3);
> > > >
> > > > //remove the child tree
> > > > sprite.removeChild(sprite2)
> > > >
> > > > /*
> > > > trace output:
> > > > added 2
> > > > added 3
> > > > removed 2
> > > > removed 3
> > > > */
> > > >
> > > > So I updated the stage events emulator to support this.
> > > 'removedFromStage'
> > > > now also works in capture phase on the strand that the bead is on for
> > > child
> > > > event targets that were removed.
> > > > In terms of the names of the events... that is quite easy to change.
> > But
> > > > whatever we decide on, I just need to add as a  COMPILE::JS variation
> > to
> > > > the 'default' setupEventType/teardownEventType in the Config class
> for
> > > Crux
> > > > to account for what would now be a difference between SWF and JS
> (which
> > > is
> > > > fine by me, I only started with the same names by trying to match how
> > > > things worked in swf as they were). So far it does work the same
> > between
> > > > swf and js builds, although there is 

Re: Crux Branch

[Piotr Zarzycki]

Hi Greg,

Thanks for update. I'm having again more important tasks and that is why I
didn't start release process yet. It looks like I will have for sure 2 full
working days to start process on upcoming Wednesday. If you make it till
that time it would be great, if not let's stay on the branch.

Thanks,
Piotr

pt., 12 lip 2019 o 07:26 Greg Dove  napisał(a):

> Just a quick update...
>
> I just fixed the ant builds for the 3 simple crux examples in the branch,
> which were not working yet.
>
> There will continue to be improvements and fixes over time, but I actually
> think it's at a state where it could be merged into develop. Unless there
> is a reason not to, I plan to do this by start of next week.
> This should not impact anyone else because it is something new, there are
> no changes to anything already present.
>
> In terms of the name as 'Crux', so far I had feedback from one person to
> give the naming some more thought, mainly because of the possibility for
> name conflicts with other libraries.
> Carlos suggested to me that we should always use 'Apache Royale Crux' in
> terms of a general reference or to introduce it for the first time, and
> then (iirc) 'Crux' by itself only in a very clear Apache Royale context,
> which avoids naming conflicts. As I understand it, this type of issue is
> similar to some other things from the past.
>
> So far I don't see anything holding back a merge. But please let me know if
> there is anything else.
>
> Thanks,
> -Greg
>
>
>
> On Sat, Jul 6, 2019 at 3:35 AM Josh Tynjala 
> wrote:
>
> > Interesting! I didn't know that the capture phase worked for non-bubbling
> > events. Good to know. Thanks for looking into it and sharing your
> findings,
> > Greg.
> >
> > - Josh
> >
> >
> > On Thu, Jul 4, 2019, 11:12 PM Greg Dove  wrote:
> >
> > > Hi Josh,
> > >
> > > For the addedToStage stuff:
> > > You made me look! Swiz does not actually use the ADDED event, it
> > definitely
> > > does use ADDED_TO_STAGE by default, but you're absolutely right, this
> > does
> > > not bubble.
> > >
> > > I did not pay too much attention to the 'bubbling' side of things
> > because I
> > > could see it working in flash and just assumed that's what was
> happening.
> > > But it is actually being listened to as a capture phase event. And that
> > > does give the same outward impression (without looking too closely) as
> if
> > > it were bubbling in this case.
> > >
> > > I even resorted to a quick test in Adobe Animate to verify:
> > >
> > > import flash.display.Sprite;
> > > import flash.events.Event;
> > >
> > > var sprite:Sprite = new Sprite();
> > > sprite.name ='1';
> > > function onAdded(event:Event):void{
> > > trace('added' ,event.target.name)
> > > }
> > > function onRemoved(event:Event):void{
> > > trace('removed' ,event.target.name)
> > > }
> > >
> > > sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
> > > sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);
> > >
> > > var sprite2:Sprite = new Sprite();
> > > sprite2.name = '2'
> > >
> > > var sprite3:Sprite = new Sprite();
> > > sprite3.name = '3'
> > >
> > > addChild(sprite);
> > > sprite.addChild(sprite2)
> > >
> > >
> > > sprite2.addChild(sprite3);
> > >
> > > //remove the child tree
> > > sprite.removeChild(sprite2)
> > >
> > > /*
> > > trace output:
> > > added 2
> > > added 3
> > > removed 2
> > > removed 3
> > > */
> > >
> > > So I updated the stage events emulator to support this.
> > 'removedFromStage'
> > > now also works in capture phase on the strand that the bead is on for
> > child
> > > event targets that were removed.
> > > In terms of the names of the events... that is quite easy to change.
> But
> > > whatever we decide on, I just need to add as a  COMPILE::JS variation
> to
> > > the 'default' setupEventType/teardownEventType in the Config class for
> > Crux
> > > to account for what would now be a difference between SWF and JS (which
> > is
> > > fine by me, I only started with the same names by trying to match how
> > > things worked in swf as they were). So far it does work the same
> between
> > > swf and js builds, although there is only one simple example that
> builds
> > > for both which I have tested with.
> > >
> > > In terms of the name of the bead, also that can be whatever people
> think
> > > makes sense. I put JS in the name because one of the builds works for
> > both
> > > swf and js. And seeing that a bead is for JS only is maybe helpful to
> > > know.. although I have always wondered whether it would make sense to
> > have
> > > compiler switches in mxml - some sort of 'transparent' enclosing tag
> > > similar to how a COMPILE::JS {  code here } compile block works in
> > > actionscript. I don't know it that makes sense something like that
> > > could mean that the swf build does not get the unnecessary bead (which
> > does
> > > nothing in swf anyway)
> > >
> > > Thanks heaps for the prompts on these things.
> > >
> > >
> > > -Greg
> > >
> > >
> > > On 

Re: Crux Branch

[Greg Dove]

Just a quick update...

I just fixed the ant builds for the 3 simple crux examples in the branch,
which were not working yet.

There will continue to be improvements and fixes over time, but I actually
think it's at a state where it could be merged into develop. Unless there
is a reason not to, I plan to do this by start of next week.
This should not impact anyone else because it is something new, there are
no changes to anything already present.

In terms of the name as 'Crux', so far I had feedback from one person to
give the naming some more thought, mainly because of the possibility for
name conflicts with other libraries.
Carlos suggested to me that we should always use 'Apache Royale Crux' in
terms of a general reference or to introduce it for the first time, and
then (iirc) 'Crux' by itself only in a very clear Apache Royale context,
which avoids naming conflicts. As I understand it, this type of issue is
similar to some other things from the past.

So far I don't see anything holding back a merge. But please let me know if
there is anything else.

Thanks,
-Greg



On Sat, Jul 6, 2019 at 3:35 AM Josh Tynjala 
wrote:

> Interesting! I didn't know that the capture phase worked for non-bubbling
> events. Good to know. Thanks for looking into it and sharing your findings,
> Greg.
>
> - Josh
>
>
> On Thu, Jul 4, 2019, 11:12 PM Greg Dove  wrote:
>
> > Hi Josh,
> >
> > For the addedToStage stuff:
> > You made me look! Swiz does not actually use the ADDED event, it
> definitely
> > does use ADDED_TO_STAGE by default, but you're absolutely right, this
> does
> > not bubble.
> >
> > I did not pay too much attention to the 'bubbling' side of things
> because I
> > could see it working in flash and just assumed that's what was happening.
> > But it is actually being listened to as a capture phase event. And that
> > does give the same outward impression (without looking too closely) as if
> > it were bubbling in this case.
> >
> > I even resorted to a quick test in Adobe Animate to verify:
> >
> > import flash.display.Sprite;
> > import flash.events.Event;
> >
> > var sprite:Sprite = new Sprite();
> > sprite.name ='1';
> > function onAdded(event:Event):void{
> > trace('added' ,event.target.name)
> > }
> > function onRemoved(event:Event):void{
> > trace('removed' ,event.target.name)
> > }
> >
> > sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
> > sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);
> >
> > var sprite2:Sprite = new Sprite();
> > sprite2.name = '2'
> >
> > var sprite3:Sprite = new Sprite();
> > sprite3.name = '3'
> >
> > addChild(sprite);
> > sprite.addChild(sprite2)
> >
> >
> > sprite2.addChild(sprite3);
> >
> > //remove the child tree
> > sprite.removeChild(sprite2)
> >
> > /*
> > trace output:
> > added 2
> > added 3
> > removed 2
> > removed 3
> > */
> >
> > So I updated the stage events emulator to support this.
> 'removedFromStage'
> > now also works in capture phase on the strand that the bead is on for
> child
> > event targets that were removed.
> > In terms of the names of the events... that is quite easy to change. But
> > whatever we decide on, I just need to add as a  COMPILE::JS variation to
> > the 'default' setupEventType/teardownEventType in the Config class for
> Crux
> > to account for what would now be a difference between SWF and JS (which
> is
> > fine by me, I only started with the same names by trying to match how
> > things worked in swf as they were). So far it does work the same between
> > swf and js builds, although there is only one simple example that builds
> > for both which I have tested with.
> >
> > In terms of the name of the bead, also that can be whatever people think
> > makes sense. I put JS in the name because one of the builds works for
> both
> > swf and js. And seeing that a bead is for JS only is maybe helpful to
> > know.. although I have always wondered whether it would make sense to
> have
> > compiler switches in mxml - some sort of 'transparent' enclosing tag
> > similar to how a COMPILE::JS {  code here } compile block works in
> > actionscript. I don't know it that makes sense something like that
> > could mean that the swf build does not get the unnecessary bead (which
> does
> > nothing in swf anyway)
> >
> > Thanks heaps for the prompts on these things.
> >
> >
> > -Greg
> >
> >
> > On Fri, Jul 5, 2019 at 5:49 AM Carlos Rovira 
> > wrote:
> >
> > > Hi Andrew,
> > >
> > > good point! That's without doubt another new point to bring to :
> > >
> > > - Royale-docs: We can follow most of the documentation available here
> [1]
> > > - Examples: In this case I don't see a Tour app since the use cases are
> > > very direct and can be exposed in few examples.
> > > Greg already provide 3 examples that shows all the things currently
> > > developed here [2]. I think we'll need to do soon a blog example
> > > covering Crux too that could be one of those or a new one. For example
> > TODO
> > > List example would be a 

Re: Crux Branch

[Josh Tynjala]

Interesting! I didn't know that the capture phase worked for non-bubbling
events. Good to know. Thanks for looking into it and sharing your findings,
Greg.

- Josh


On Thu, Jul 4, 2019, 11:12 PM Greg Dove  wrote:

> Hi Josh,
>
> For the addedToStage stuff:
> You made me look! Swiz does not actually use the ADDED event, it definitely
> does use ADDED_TO_STAGE by default, but you're absolutely right, this does
> not bubble.
>
> I did not pay too much attention to the 'bubbling' side of things because I
> could see it working in flash and just assumed that's what was happening.
> But it is actually being listened to as a capture phase event. And that
> does give the same outward impression (without looking too closely) as if
> it were bubbling in this case.
>
> I even resorted to a quick test in Adobe Animate to verify:
>
> import flash.display.Sprite;
> import flash.events.Event;
>
> var sprite:Sprite = new Sprite();
> sprite.name ='1';
> function onAdded(event:Event):void{
> trace('added' ,event.target.name)
> }
> function onRemoved(event:Event):void{
> trace('removed' ,event.target.name)
> }
>
> sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
> sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);
>
> var sprite2:Sprite = new Sprite();
> sprite2.name = '2'
>
> var sprite3:Sprite = new Sprite();
> sprite3.name = '3'
>
> addChild(sprite);
> sprite.addChild(sprite2)
>
>
> sprite2.addChild(sprite3);
>
> //remove the child tree
> sprite.removeChild(sprite2)
>
> /*
> trace output:
> added 2
> added 3
> removed 2
> removed 3
> */
>
> So I updated the stage events emulator to support this. 'removedFromStage'
> now also works in capture phase on the strand that the bead is on for child
> event targets that were removed.
> In terms of the names of the events... that is quite easy to change. But
> whatever we decide on, I just need to add as a  COMPILE::JS variation to
> the 'default' setupEventType/teardownEventType in the Config class for Crux
> to account for what would now be a difference between SWF and JS (which is
> fine by me, I only started with the same names by trying to match how
> things worked in swf as they were). So far it does work the same between
> swf and js builds, although there is only one simple example that builds
> for both which I have tested with.
>
> In terms of the name of the bead, also that can be whatever people think
> makes sense. I put JS in the name because one of the builds works for both
> swf and js. And seeing that a bead is for JS only is maybe helpful to
> know.. although I have always wondered whether it would make sense to have
> compiler switches in mxml - some sort of 'transparent' enclosing tag
> similar to how a COMPILE::JS {  code here } compile block works in
> actionscript. I don't know it that makes sense something like that
> could mean that the swf build does not get the unnecessary bead (which does
> nothing in swf anyway)
>
> Thanks heaps for the prompts on these things.
>
>
> -Greg
>
>
> On Fri, Jul 5, 2019 at 5:49 AM Carlos Rovira 
> wrote:
>
> > Hi Andrew,
> >
> > good point! That's without doubt another new point to bring to :
> >
> > - Royale-docs: We can follow most of the documentation available here [1]
> > - Examples: In this case I don't see a Tour app since the use cases are
> > very direct and can be exposed in few examples.
> > Greg already provide 3 examples that shows all the things currently
> > developed here [2]. I think we'll need to do soon a blog example
> > covering Crux too that could be one of those or a new one. For example
> TODO
> > List example would be a good one to apply Crux ;)
> >
> > [1] https://swizframework.jira.com/wiki/spaces/SWIZ/overview
> > [2]
> https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux
> >
> > So many work there too to make it all avaialble to Apache Royale users as
> > easy as possible ;)
> >
> >
> >
> > El jue., 4 jul. 2019 a las 18:46, Andrew Wetmore ()
> > escribió:
> >
> > > This is great.
> > >
> > > However, even with the original Swiz I found the documentation quite
> thin
> > > and that it made a lot of assumptions about what a general developer
> > might
> > > know and need to know. This site [1] made an attempt about ten years
> ago
> > to
> > > improve on an intro to Swiz. What plans are in the works to not only
> > > provide Crux, but make it welcoming and accessible? Tour de Crux??
> > >
> > > a
> > >
> > > [1] https://deshartman.wordpress.com/2010/02/07/first-swiz/
> > >
> > > On Thu, Jul 4, 2019 at 1:17 PM Josh Tynjala  >
> > > wrote:
> > >
> > > > Cool stuff, Greg and Carlos!
> > > >
> > > > One concern: In Flash, the "addedToStage" event does not bubble. It's
> > > > actually the "added" event that bubbles and is used by frameworks
> like
> > > > Swiz, Cairngorm, Robotlegs, etc.
> > > >
> > > > To avoid potential confusion for people migrating an existing app
> from
> > > > Flex/Flash that might already listen for that event (and wouldn't
> 

Re: Crux Branch

[Greg Dove]

Hi Josh,

For the addedToStage stuff:
You made me look! Swiz does not actually use the ADDED event, it definitely
does use ADDED_TO_STAGE by default, but you're absolutely right, this does
not bubble.

I did not pay too much attention to the 'bubbling' side of things because I
could see it working in flash and just assumed that's what was happening.
But it is actually being listened to as a capture phase event. And that
does give the same outward impression (without looking too closely) as if
it were bubbling in this case.

I even resorted to a quick test in Adobe Animate to verify:

import flash.display.Sprite;
import flash.events.Event;

var sprite:Sprite = new Sprite();
sprite.name ='1';
function onAdded(event:Event):void{
trace('added' ,event.target.name)
}
function onRemoved(event:Event):void{
trace('removed' ,event.target.name)
}

sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);

var sprite2:Sprite = new Sprite();
sprite2.name = '2'

var sprite3:Sprite = new Sprite();
sprite3.name = '3'

addChild(sprite);
sprite.addChild(sprite2)


sprite2.addChild(sprite3);

//remove the child tree
sprite.removeChild(sprite2)

/*
trace output:
added 2
added 3
removed 2
removed 3
*/

So I updated the stage events emulator to support this. 'removedFromStage'
now also works in capture phase on the strand that the bead is on for child
event targets that were removed.
In terms of the names of the events... that is quite easy to change. But
whatever we decide on, I just need to add as a  COMPILE::JS variation to
the 'default' setupEventType/teardownEventType in the Config class for Crux
to account for what would now be a difference between SWF and JS (which is
fine by me, I only started with the same names by trying to match how
things worked in swf as they were). So far it does work the same between
swf and js builds, although there is only one simple example that builds
for both which I have tested with.

In terms of the name of the bead, also that can be whatever people think
makes sense. I put JS in the name because one of the builds works for both
swf and js. And seeing that a bead is for JS only is maybe helpful to
know.. although I have always wondered whether it would make sense to have
compiler switches in mxml - some sort of 'transparent' enclosing tag
similar to how a COMPILE::JS {  code here } compile block works in
actionscript. I don't know it that makes sense something like that
could mean that the swf build does not get the unnecessary bead (which does
nothing in swf anyway)

Thanks heaps for the prompts on these things.


-Greg


On Fri, Jul 5, 2019 at 5:49 AM Carlos Rovira 
wrote:

> Hi Andrew,
>
> good point! That's without doubt another new point to bring to :
>
> - Royale-docs: We can follow most of the documentation available here [1]
> - Examples: In this case I don't see a Tour app since the use cases are
> very direct and can be exposed in few examples.
> Greg already provide 3 examples that shows all the things currently
> developed here [2]. I think we'll need to do soon a blog example
> covering Crux too that could be one of those or a new one. For example TODO
> List example would be a good one to apply Crux ;)
>
> [1] https://swizframework.jira.com/wiki/spaces/SWIZ/overview
> [2] https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux
>
> So many work there too to make it all avaialble to Apache Royale users as
> easy as possible ;)
>
>
>
> El jue., 4 jul. 2019 a las 18:46, Andrew Wetmore ()
> escribió:
>
> > This is great.
> >
> > However, even with the original Swiz I found the documentation quite thin
> > and that it made a lot of assumptions about what a general developer
> might
> > know and need to know. This site [1] made an attempt about ten years ago
> to
> > improve on an intro to Swiz. What plans are in the works to not only
> > provide Crux, but make it welcoming and accessible? Tour de Crux??
> >
> > a
> >
> > [1] https://deshartman.wordpress.com/2010/02/07/first-swiz/
> >
> > On Thu, Jul 4, 2019 at 1:17 PM Josh Tynjala 
> > wrote:
> >
> > > Cool stuff, Greg and Carlos!
> > >
> > > One concern: In Flash, the "addedToStage" event does not bubble. It's
> > > actually the "added" event that bubbles and is used by frameworks like
> > > Swiz, Cairngorm, Robotlegs, etc.
> > >
> > > To avoid potential confusion for people migrating an existing app from
> > > Flex/Flash that might already listen for that event (and wouldn't
> expect
> > it
> > > to bubble), I'd recommend using a different name than "addedToStage".
> It
> > > could be "added", like Flash. Or it could even have a new name that's
> > > similar to "addedToStage", but is more relevant to Royale. Royale
> doesn't
> > > have a "stage", so that name feels a bit out of place to me anyway.
> Maybe
> > > "addedToApplication" or something like that.
> > >
> > > - Josh
> > >
> > >
> > > On Wed, Jul 3, 2019, 11:11 PM Greg Dove  wrote:
> 

Re: Crux Branch

[Carlos Rovira]

Hi Andrew,

good point! That's without doubt another new point to bring to :

- Royale-docs: We can follow most of the documentation available here [1]
- Examples: In this case I don't see a Tour app since the use cases are
very direct and can be exposed in few examples.
Greg already provide 3 examples that shows all the things currently
developed here [2]. I think we'll need to do soon a blog example
covering Crux too that could be one of those or a new one. For example TODO
List example would be a good one to apply Crux ;)

[1] https://swizframework.jira.com/wiki/spaces/SWIZ/overview
[2] https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux

So many work there too to make it all avaialble to Apache Royale users as
easy as possible ;)



El jue., 4 jul. 2019 a las 18:46, Andrew Wetmore ()
escribió:

> This is great.
>
> However, even with the original Swiz I found the documentation quite thin
> and that it made a lot of assumptions about what a general developer might
> know and need to know. This site [1] made an attempt about ten years ago to
> improve on an intro to Swiz. What plans are in the works to not only
> provide Crux, but make it welcoming and accessible? Tour de Crux??
>
> a
>
> [1] https://deshartman.wordpress.com/2010/02/07/first-swiz/
>
> On Thu, Jul 4, 2019 at 1:17 PM Josh Tynjala 
> wrote:
>
> > Cool stuff, Greg and Carlos!
> >
> > One concern: In Flash, the "addedToStage" event does not bubble. It's
> > actually the "added" event that bubbles and is used by frameworks like
> > Swiz, Cairngorm, Robotlegs, etc.
> >
> > To avoid potential confusion for people migrating an existing app from
> > Flex/Flash that might already listen for that event (and wouldn't expect
> it
> > to bubble), I'd recommend using a different name than "addedToStage". It
> > could be "added", like Flash. Or it could even have a new name that's
> > similar to "addedToStage", but is more relevant to Royale. Royale doesn't
> > have a "stage", so that name feels a bit out of place to me anyway. Maybe
> > "addedToApplication" or something like that.
> >
> > - Josh
> >
> >
> > On Wed, Jul 3, 2019, 11:11 PM Greg Dove  wrote:
> >
> > > Hi all,
> > >
> > > Just a quick advance notice that we are getting something very similar
> to
> > > Swiz before too long.
> > > There is a new branch called feature/Crux
> > >
> > > We can still explore other possible ways to incorporate Swiz code in
> > Royale
> > > (we have looked at having the code donated in the past), but for now at
> > > least it is as a derivative work, differentiated by name as 'Crux' and
> > > hence the name of the branch. 'Crux' means a main or pivotal point -
> > > something important - and a common English expression that can express
> > that
> > > is when someone says ""the crux of the matter" - it means an important
> > > thing to focus on.
> > >
> > > The name is what it is now - it is short and has a powerful meaning.
> But
> > > certainly we can review that too.
> > >
> > > The branch has the beginnings of the original Swiz functionality which
> > > supports metadata driven Injection (including runtime Binding
> Injection),
> > > EventHandlers, main Dispatcher etc.
> > > Those things are already shown in 3 examples [1] in examples/crux in
> the
> > > branch, (but I did not check the ant builds for those yet- I will get
> to
> > > that). Beyond those features, I have not ventured far yet, and perhaps
> > some
> > > of the others may not be relevant for Royale.
> > >
> > > In case it's useful elsewhere, there is also a new JSStageEvents
> 'stage
> > > events' simulator bead which works from the main application level, and
> > > provides bubbling 'addedToStage' events which Crux listens to at the
> top
> > > level. These can be filtered (so not everything generates the events,
> for
> > > example). Not sure if that might be useful for other things, just
> > > mentioning it for now... It does dispatch 'removedFromStage' as well,
> but
> > > too late for bubbling, so I will investigate if I can do something a
> bit
> > > sneaky to see if I can make that work. Otherwise it is always possible
> to
> > > add  removedFromStage  listeners directly to the target of interest
> > inside
> > > an 'addedToStage' listener.
> > >
> > > I expect there will be bugs, and I of course there will be many things
> I
> > > can continue to improve, so this is just an early announcement for your
> > > awareness. Carlos sponsored a large chunk of my time on this, so you
> have
> > > him to thank for that, but I have also contributed a lot of my own
> time,
> > > and will continue to do so. Thanks also to Alex for recent guidance on
> > > licencing issues, this was uncharted territory for me.
> > >
> > > Anyhow, Carlos will, I am sure, provide more info, he is very familiar
> > with
> > > Swiz from the past.
> > >
> > > -Greg
> > >
> > >
> > > 1.
> https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux
> > >
> >
>
>
> --
> Andrew Wetmore
>
> 

Re: Crux Branch

[Carlos Rovira]

Hi Josh,

thanks for the words! very appreciated :)

I think you're right, and the new name seems ok for me too
(addedToApplication),
maybe event JSStageEvents, should be rethinked too. @Greg Dove
 should we need the JS
prefix? what about "ApplicationEvents"

if maybe Application is very generic, we can think in other options like:

- addedToCrux - CruxEvents
- addedToDisplay - DisplayEvents
...

or maybe other one that others bring on the table

Thanks!







El jue., 4 jul. 2019 a las 18:17, Josh Tynjala ()
escribió:

> Cool stuff, Greg and Carlos!
>
> One concern: In Flash, the "addedToStage" event does not bubble. It's
> actually the "added" event that bubbles and is used by frameworks like
> Swiz, Cairngorm, Robotlegs, etc.
>
> To avoid potential confusion for people migrating an existing app from
> Flex/Flash that might already listen for that event (and wouldn't expect it
> to bubble), I'd recommend using a different name than "addedToStage". It
> could be "added", like Flash. Or it could even have a new name that's
> similar to "addedToStage", but is more relevant to Royale. Royale doesn't
> have a "stage", so that name feels a bit out of place to me anyway. Maybe
> "addedToApplication" or something like that.
>
> - Josh
>
>
> On Wed, Jul 3, 2019, 11:11 PM Greg Dove  wrote:
>
> > Hi all,
> >
> > Just a quick advance notice that we are getting something very similar to
> > Swiz before too long.
> > There is a new branch called feature/Crux
> >
> > We can still explore other possible ways to incorporate Swiz code in
> Royale
> > (we have looked at having the code donated in the past), but for now at
> > least it is as a derivative work, differentiated by name as 'Crux' and
> > hence the name of the branch. 'Crux' means a main or pivotal point -
> > something important - and a common English expression that can express
> that
> > is when someone says ""the crux of the matter" - it means an important
> > thing to focus on.
> >
> > The name is what it is now - it is short and has a powerful meaning. But
> > certainly we can review that too.
> >
> > The branch has the beginnings of the original Swiz functionality which
> > supports metadata driven Injection (including runtime Binding Injection),
> > EventHandlers, main Dispatcher etc.
> > Those things are already shown in 3 examples [1] in examples/crux in the
> > branch, (but I did not check the ant builds for those yet- I will get to
> > that). Beyond those features, I have not ventured far yet, and perhaps
> some
> > of the others may not be relevant for Royale.
> >
> > In case it's useful elsewhere, there is also a new JSStageEvents  'stage
> > events' simulator bead which works from the main application level, and
> > provides bubbling 'addedToStage' events which Crux listens to at the top
> > level. These can be filtered (so not everything generates the events, for
> > example). Not sure if that might be useful for other things, just
> > mentioning it for now... It does dispatch 'removedFromStage' as well, but
> > too late for bubbling, so I will investigate if I can do something a bit
> > sneaky to see if I can make that work. Otherwise it is always possible to
> > add  removedFromStage  listeners directly to the target of interest
> inside
> > an 'addedToStage' listener.
> >
> > I expect there will be bugs, and I of course there will be many things I
> > can continue to improve, so this is just an early announcement for your
> > awareness. Carlos sponsored a large chunk of my time on this, so you have
> > him to thank for that, but I have also contributed a lot of my own time,
> > and will continue to do so. Thanks also to Alex for recent guidance on
> > licencing issues, this was uncharted territory for me.
> >
> > Anyhow, Carlos will, I am sure, provide more info, he is very familiar
> with
> > Swiz from the past.
> >
> > -Greg
> >
> >
> > 1. https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux
> >
>


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

Re: Crux Branch

[Andrew Wetmore]

This is great.

However, even with the original Swiz I found the documentation quite thin
and that it made a lot of assumptions about what a general developer might
know and need to know. This site [1] made an attempt about ten years ago to
improve on an intro to Swiz. What plans are in the works to not only
provide Crux, but make it welcoming and accessible? Tour de Crux??

a

[1] https://deshartman.wordpress.com/2010/02/07/first-swiz/

On Thu, Jul 4, 2019 at 1:17 PM Josh Tynjala 
wrote:

> Cool stuff, Greg and Carlos!
>
> One concern: In Flash, the "addedToStage" event does not bubble. It's
> actually the "added" event that bubbles and is used by frameworks like
> Swiz, Cairngorm, Robotlegs, etc.
>
> To avoid potential confusion for people migrating an existing app from
> Flex/Flash that might already listen for that event (and wouldn't expect it
> to bubble), I'd recommend using a different name than "addedToStage". It
> could be "added", like Flash. Or it could even have a new name that's
> similar to "addedToStage", but is more relevant to Royale. Royale doesn't
> have a "stage", so that name feels a bit out of place to me anyway. Maybe
> "addedToApplication" or something like that.
>
> - Josh
>
>
> On Wed, Jul 3, 2019, 11:11 PM Greg Dove  wrote:
>
> > Hi all,
> >
> > Just a quick advance notice that we are getting something very similar to
> > Swiz before too long.
> > There is a new branch called feature/Crux
> >
> > We can still explore other possible ways to incorporate Swiz code in
> Royale
> > (we have looked at having the code donated in the past), but for now at
> > least it is as a derivative work, differentiated by name as 'Crux' and
> > hence the name of the branch. 'Crux' means a main or pivotal point -
> > something important - and a common English expression that can express
> that
> > is when someone says ""the crux of the matter" - it means an important
> > thing to focus on.
> >
> > The name is what it is now - it is short and has a powerful meaning. But
> > certainly we can review that too.
> >
> > The branch has the beginnings of the original Swiz functionality which
> > supports metadata driven Injection (including runtime Binding Injection),
> > EventHandlers, main Dispatcher etc.
> > Those things are already shown in 3 examples [1] in examples/crux in the
> > branch, (but I did not check the ant builds for those yet- I will get to
> > that). Beyond those features, I have not ventured far yet, and perhaps
> some
> > of the others may not be relevant for Royale.
> >
> > In case it's useful elsewhere, there is also a new JSStageEvents  'stage
> > events' simulator bead which works from the main application level, and
> > provides bubbling 'addedToStage' events which Crux listens to at the top
> > level. These can be filtered (so not everything generates the events, for
> > example). Not sure if that might be useful for other things, just
> > mentioning it for now... It does dispatch 'removedFromStage' as well, but
> > too late for bubbling, so I will investigate if I can do something a bit
> > sneaky to see if I can make that work. Otherwise it is always possible to
> > add  removedFromStage  listeners directly to the target of interest
> inside
> > an 'addedToStage' listener.
> >
> > I expect there will be bugs, and I of course there will be many things I
> > can continue to improve, so this is just an early announcement for your
> > awareness. Carlos sponsored a large chunk of my time on this, so you have
> > him to thank for that, but I have also contributed a lot of my own time,
> > and will continue to do so. Thanks also to Alex for recent guidance on
> > licencing issues, this was uncharted territory for me.
> >
> > Anyhow, Carlos will, I am sure, provide more info, he is very familiar
> with
> > Swiz from the past.
> >
> > -Greg
> >
> >
> > 1. https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux
> >
>


-- 
Andrew Wetmore

http://cottage14.blogspot.com/

Re: Crux Branch

[Josh Tynjala]

Cool stuff, Greg and Carlos!

One concern: In Flash, the "addedToStage" event does not bubble. It's
actually the "added" event that bubbles and is used by frameworks like
Swiz, Cairngorm, Robotlegs, etc.

To avoid potential confusion for people migrating an existing app from
Flex/Flash that might already listen for that event (and wouldn't expect it
to bubble), I'd recommend using a different name than "addedToStage". It
could be "added", like Flash. Or it could even have a new name that's
similar to "addedToStage", but is more relevant to Royale. Royale doesn't
have a "stage", so that name feels a bit out of place to me anyway. Maybe
"addedToApplication" or something like that.

- Josh


On Wed, Jul 3, 2019, 11:11 PM Greg Dove  wrote:

> Hi all,
>
> Just a quick advance notice that we are getting something very similar to
> Swiz before too long.
> There is a new branch called feature/Crux
>
> We can still explore other possible ways to incorporate Swiz code in Royale
> (we have looked at having the code donated in the past), but for now at
> least it is as a derivative work, differentiated by name as 'Crux' and
> hence the name of the branch. 'Crux' means a main or pivotal point -
> something important - and a common English expression that can express that
> is when someone says ""the crux of the matter" - it means an important
> thing to focus on.
>
> The name is what it is now - it is short and has a powerful meaning. But
> certainly we can review that too.
>
> The branch has the beginnings of the original Swiz functionality which
> supports metadata driven Injection (including runtime Binding Injection),
> EventHandlers, main Dispatcher etc.
> Those things are already shown in 3 examples [1] in examples/crux in the
> branch, (but I did not check the ant builds for those yet- I will get to
> that). Beyond those features, I have not ventured far yet, and perhaps some
> of the others may not be relevant for Royale.
>
> In case it's useful elsewhere, there is also a new JSStageEvents  'stage
> events' simulator bead which works from the main application level, and
> provides bubbling 'addedToStage' events which Crux listens to at the top
> level. These can be filtered (so not everything generates the events, for
> example). Not sure if that might be useful for other things, just
> mentioning it for now... It does dispatch 'removedFromStage' as well, but
> too late for bubbling, so I will investigate if I can do something a bit
> sneaky to see if I can make that work. Otherwise it is always possible to
> add  removedFromStage  listeners directly to the target of interest inside
> an 'addedToStage' listener.
>
> I expect there will be bugs, and I of course there will be many things I
> can continue to improve, so this is just an early announcement for your
> awareness. Carlos sponsored a large chunk of my time on this, so you have
> him to thank for that, but I have also contributed a lot of my own time,
> and will continue to do so. Thanks also to Alex for recent guidance on
> licencing issues, this was uncharted territory for me.
>
> Anyhow, Carlos will, I am sure, provide more info, he is very familiar with
> Swiz from the past.
>
> -Greg
>
>
> 1. https://github.com/apache/royale-asjs/tree/feature/Crux/examples/crux
>

Re: Crux Branch

[Carlos Rovira]

Hi all,

thanks Greg for the introduction and for the great work here.
I think you made an excellent task in bringing this project to live :).

Crux is an important piece for all of us trying to make a complex
application.
Until now the Royale option for this kind of "microarquitecture" was
PureMVC (I think the only MVC available out there).
In Flex we had Cairngorm too, but then other frameworks based on Metadata,
IoC and Injection of dependencies
came to dominate this kind of necessity, I think Parsley and Swiz was two
of the most known and used but many others
was there to fill that gap.

These days JS frameworks bring something similar with libraries very well
crafted like Redux (for React).
We needed this kind of library so much to grow our codes in the right way.
While doing our first Royale
real app we tried other ways (like using a bead system), but finally it was
clear that we needed a framework
to fill the gap. So in other to grow we found that we need to bring
something like this before continue expanding the code
in our real Royale app.

The main problem we discover is that while beads works great at component
level, and to hold a model for a concrete instance,
we need to "inject" instances to share models, controllers and communicate
different parts of the application with events
but sharing different unique models, controllers and other application
unique instances.
So the problem is certainly different at component level we want to
dispatch events and communicate via strand.
At application level we want different parts of application have common
pieces and be able to share
events across all different application pieces. And all of this with the
less code possible.
So here comes Swiz "Inject", "Dispatcher" and "EventHandler" are the key
metadata that make all very easy.

I always liked Swiz due to its simplicity, tiny code that does great things
and solve many problems and want to have something like that here
in Royale.

In 2016 we tried to bring Swiz to Apache Flex. We even had Chris Scott
(original Swiz author) baking this movement. But was a problem
since we needed the rest of the authors agreement although Swiz was in
ALv2. what was nearly impossible since most of the authors were
unavailable vía the email accounts we could gather for them.

This time is different. We're not trying to bring/donate Swiz to Apache
Royale. Swiz does not run at all in Royale. If we still want to try that
we still need to do that in Apache Flex since Swiz is for Flex.

We need to create a new framework (hence the new name Crux) but based on
parts of Swiz (thanks to ALv2). So Crux looks in many aspects like Swiz,
but is not Swiz anymore. IOW, if Swiz will be live this days we wouldn't
able to add this big changes to the latest Swiz version, since Swiz was for
Flex and this new framework is for Royale. So this is an important point
that we all need to know. Crux is derivative work from Swiz that changes
many internal things to make it work in Royale and shares names and in most
of the cases internal structure but its target is a completely different
technology, so Swiz could continue (if someone resurrect it) evolve on its
own to continue working for Apache Flex, while Crux will need its own
roadmap, changes and evolution to work for Apache Royale.

In the other hand, in this process we was again in contact with Chris Scott
(I want to thank him for begin so collaborative with us) that is aware of
our intention of creating this new codebase based on his Swiz called Crux
and are supporting it. He's completely aligned with the movement, and we
want to give him and the rest of the original Swiz team the credit and want
to make all know(in our docs, examples, and social networks as we can share
this news) that Crux comes from the concepts and original code of Swiz, and
we was able to have this today thanks to the current work done by Greg, and
of course to the work Swiz developers did in the past for Flex.

To end. I think this is a first commit and I'm sure there will be many
issues as normal. Hope we can merge this branch soon and continue finding
and fixing issues we found and as well looking at the scenarios still not
tested. For example, will work Modules with Crux?...there's still things to
be cleared, but this is a great starting point without doubt. For me this
was the latest needed piece to use Royale in big applications and systems,
and I think we can start using it as today :).

Thanks!

Carlos





El jue., 4 jul. 2019 a las 8:11, Greg Dove () escribió:

> Hi all,
>
> Just a quick advance notice that we are getting something very similar to
> Swiz before too long.
> There is a new branch called feature/Crux
>
> We can still explore other possible ways to incorporate Swiz code in Royale
> (we have looked at having the code donated in the past), but for now at
> least it is as a derivative work, differentiated by name as 'Crux' and
> hence the name of the branch. 'Crux' means a main or pivotal point -
>