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&amp;data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684334180&amp;sdata=L%2F9IvTJMCfHCShsWdMfqEI4cwtHCKR%2Fuplhw98MkYVM%3D&amp;reserved=0
    > > > > > [2]
    > > > >
    > 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Ffeature%2FCrux%2Fexamples%2Fcrux&amp;data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684334180&amp;sdata=bNyYr8j%2Bzd7b9pfgWh1YZjkoaykLIPlXkn3OvFHTDBM%3D&amp;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&amp;data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684334180&amp;sdata=c%2FozLDlAKqhuTfUTmtodH868g5%2BHoJ1OCX2z6T47DpE%3D&amp;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&amp;data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684334180&amp;sdata=bNyYr8j%2Bzd7b9pfgWh1YZjkoaykLIPlXkn3OvFHTDBM%3D&amp;reserved=0
    > > > > > > > >
    > > > > > > >
    > > > > > >
    > > > > > >
    > > > > > > --
    > > > > > > Andrew Wetmore
    > > > > > >
    > > > > > > 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&amp;data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&amp;sdata=4EP7gIFpNPp8Rr%2FY1ERyDEulDZ57u6wdMfy2SrE9pDU%3D&amp;reserved=0
    > > > > > >
    > > > > >
    > > > > >
    > > > > > --
    > > > > > Carlos Rovira
    > > > > > 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&amp;sdata=IP6M8EGdel0m2VTao7xjlwcOThJf9sbIlyPb6e9iGlM%3D&amp;reserved=0
    > > > > >
    > > > >
    > > >
    > >
    >
    >
    > --
    >
    > Piotr Zarzycki
    >
    > Patreon: 
*https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&amp;sdata=x7QeUYMQsplBRKeCchiDNpY366ZbLLHc2TSH05XrI2A%3D&amp;reserved=0
    > 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&amp;sdata=x7QeUYMQsplBRKeCchiDNpY366ZbLLHc2TSH05XrI2A%3D&amp;reserved=0>*
    >
    
    
    -- 
    Carlos Rovira
    
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C035b7ab7f40c4131de8e08d706b57003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636985248684344178&amp;sdata=IP6M8EGdel0m2VTao7xjlwcOThJf9sbIlyPb6e9iGlM%3D&amp;reserved=0
    

Reply via email to