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 (<aha...@adobe.com.invalid>)
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" <carlosrov...@apache.org> 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 branch.
> >
> > Thanks,
> > Piotr
> >
> > pt., 12 lip 2019 o 07:26 Greg Dove <greg.d...@gmail.com> 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 <
> joshtynj...@bowlerhat.dev>
> > > 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 <greg.d...@gmail.com>
> 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 <
> > carlosrov...@apache.org>
> > > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fswizframework.jira.com%2Fwiki%2Fspaces%2FSWIZ%2Foverview&data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684334180&sdata=L%2F9IvTJMCfHCShsWdMfqEI4cwtHCKR%2Fuplhw98MkYVM%3D&reserved=0
> > > > > > [2]
> > > > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Ffeature%2FCrux%2Fexamples%2Fcrux&data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684334180&sdata=bNyYr8j%2Bzd7b9pfgWh1YZjkoaykLIPlXkn3OvFHTDBM%3D&reserved=0
> > > > > >
> > > > > > 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 (<
> > > cottag...@gmail.com
> > > > >)
> > > > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeshartman.wordpress.com%2F2010%2F02%2F07%2Ffirst-swiz%2F&data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684334180&sdata=c%2FozLDlAKqhuTfUTmtodH868g5%2BHoJ1OCX2z6T47DpE%3D&reserved=0
> > > > > > >
> > > > > > > On Thu, Jul 4, 2019 at 1:17 PM Josh Tynjala <
> > > > joshtynj...@bowlerhat.dev
> > > > > >
> > > > > > > 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 <
> greg.d...@gmail.com>
> > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Ffeature%2FCrux%2Fexamples%2Fcrux&data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684334180&sdata=bNyYr8j%2Bzd7b9pfgWh1YZjkoaykLIPlXkn3OvFHTDBM%3D&reserved=0
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Andrew Wetmore
> > > > > > >
> > > > > > >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&sdata=4EP7gIFpNPp8Rr%2FY1ERyDEulDZ57u6wdMfy2SrE9pDU%3D&reserved=0
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Carlos Rovira
> > > > > >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&sdata=IP6M8EGdel0m2VTao7xjlwcOThJf9sbIlyPb6e9iGlM%3D&reserved=0
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&sdata=x7QeUYMQsplBRKeCchiDNpY366ZbLLHc2TSH05XrI2A%3D&reserved=0
> > <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&sdata=x7QeUYMQsplBRKeCchiDNpY366ZbLLHc2TSH05XrI2A%3D&reserved=0
> >*
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&sdata=IP6M8EGdel0m2VTao7xjlwcOThJf9sbIlyPb6e9iGlM%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
