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 (<greg.d...@gmail.com>) 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 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 <aha...@adobe.com.invalid> > 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 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" <carlosrov...@apache.org> 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 > (<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%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904204068&sdata=OY6kNAiQ6DCyYec%2FhoEpIak7cN06H%2FBMJfgv5BYO1FM%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%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904214063&sdata=97LlN7PjHOKk61bq1uK48NGA%2FSyUoB6QZLTBaUaZ3zA%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%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904214063&sdata=sgPaqbExKNgVCk2coQbF%2Fc3wW0cvHHklDjBd1BgREPA%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%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904214063&sdata=97LlN7PjHOKk61bq1uK48NGA%2FSyUoB6QZLTBaUaZ3zA%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%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904214063&sdata=ZcyjbKrdRC78UyX7Zuei9JGr%2FZLgS5ZzqNJcS3cBxCo%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Carlos Rovira > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904214063&sdata=GRAeUEFlSzk8c9vEgUUObXpbi8KQSpuSQ3Ioom6Qhug%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%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904214063&sdata=LESJabBWS0G0gb%2B8mscII4GCHk9OiLWCLcEQMRY1jP4%3D&reserved=0 > > > > < > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904214063&sdata=LESJabBWS0G0gb%2B8mscII4GCHk9OiLWCLcEQMRY1jP4%3D&reserved=0 > > > >* > > > > > > > > > > > > > -- > > > Carlos Rovira > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904214063&sdata=GRAeUEFlSzk8c9vEgUUObXpbi8KQSpuSQ3Ioom6Qhug%3D&reserved=0 > > > > > > > > > > > > > -- > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C45f931bc41084fa4c0ab08d709028f22%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636987778904224058&sdata=his5FHxegkIjj8mqR6H2hqWpt%2BTPN7orwas7CQxt6T8%3D&reserved=0 > > > > > > > -- Carlos Rovira http://about.me/carlosrovira
