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 <carlosrov...@apache.org> 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 (<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 >
