IMO, we want people to be able to choose Greensock, Tweener, or anything they want.
Really, Royale is in the business of making it easier/more efficient/more productive to integrate pieces of Javascript into an application. We are writing our own framework so we know that the baseline is in terms of size and performance. But people are way more likely to use heavier but richer libraries if they don't need to save bytes or cpu cycles. So, if you know folks involved with Tweener and can convince them to wrap up their code in a Royale SWC, or want to do it yourself, that's great. The more choices, the better Royale is. My 2 cents, -Alex On 9/14/18, 9:30 AM, "Kenny Lerma" <[email protected]> wrote: Have you considered using Tweener? I'm incorporating this into SpriteFlexjs and It's what I've always used at other companies for years since it's free and open-source. I realize greensock has a javascript version already and is a great library. However, unless they have changed their license, you need to buy a license to you use it for commercial projects. It's for that reason that companies in the past switched to Tweener. https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhosted.zeh.com.br%2Ftweener%2Fdocs%2Fen-us%2F&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=%2F3S3iqsK4gBNgWoJx9cxpu0w95iDTY1JR7T%2FAREQOAA%3D&reserved=0 On Fri, Sep 14, 2018 at 11:23 AM Alex Harui <[email protected]> wrote: > Greensock was quite popular among Flex developers. Does anyone on this > list have contacts at Greensock? We might want to see if they will create > a Royale SWC for their code. > > Regarding class selectors and states, I guess I don't understand the > issue. The code behind Royale (and Flex) states should be capturing values > of properties changed by the state before they get changed, then restoring > those properties. IOW, if you were to have > > <js:states> > <js:state name="normal" /> > <js:state name="important" /> > <js:states> > <j:Button id="myButton" emphasis.normal="primary" > emphasis.important="emphasized" /> > > Then the myButton.emphasis="primary" at startup and when the state > changes to "important" the States impl should read myButton.emphasis and > store that value away before setting myButton.emphasis="emphasized". Then, > when the state changes back to "normal", the States impl should set > myButton.emphasis="primary" again. > > In the implementation for the emphasis property, if it involves changing > classLists, the implementation must do so in a way that handles having the > emphasis property changes at runtime. The States impl isn't really doing > anything application developer code might do, so the implementation must > support properties being set and re-set. > > My 2 cents, > -Alex > > On 9/14/18, 4:07 AM, "Carlos Rovira" <[email protected]> wrote: > > Hi Harbs, > > for me is ok, but I'm more worried about how to accommodate this and > the > underlying architecture. The events systems that Alex propose, > About implementation, I'm sure can do something on the lines of GASP, > but > as you say, we should be able to plug other options as we do with > layouts > currently. > > But first of all, for me, we should solve the problem with > addition/removal > of class selectors in the core of UIBase. I at least don't know other > way > to deal with it without the need of adding lots of unnecessary code > like I > had to do in Jewel for something that is so "core" to us. > > Thanks > > > > El vie., 14 sept. 2018 a las 11:34, Harbs (<[email protected]>) > escribió: > > > Well, my point of view on animation would be that GSAP is the > industry > > standard.[1] > > > > Making GSAP a dependency is a no-go because the license is not > compatible, > > but I’d say that the approach should be similar (although I don’t > expect > > we’d get nearly to the level of complete-ness / robustness that GSAP > has). > > Extra points would be to allow GSAP to be easily substituted for the > > default implementation. > > > > I’m not sure about states. > > > > My $0.02, > > Harbs > > > > [1] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=QTIFnkaLVawza7nlHXmShHctuRW6f5Kif9NmEdq55YE%3D&reserved=0 > < > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=QTIFnkaLVawza7nlHXmShHctuRW6f5Kif9NmEdq55YE%3D&reserved=0 > > > > > > > On Sep 14, 2018, at 10:36 AM, Carlos Rovira < > [email protected]> > > wrote: > > > > > > Hi Alex, > > > > > > renaming this to other thread since I think this deserves its > space to > > > planning. > > > > > > Right now, in Jewel, we try to get most of "eye candy" things > through CSS > > > class selectors. This means that we defer this to the CSS > "engine". The > > > same happens with Jewel layouts, that are based on add the proper > class > > > selectors. > > > > > > This for now is working, but I think is not the Royale way, since > I see > > > some drawbacks: > > > > > > - you don't have control in Royale of the things deferred to CSS. > > > - targets like SWF, or future targets, could be left since this > strategy > > is > > > platform dependent > > > > > > And some issues: > > > > > > - States subsystems is not playing nicely with class selectors. It > can't > > > recreate the class selectors the component has before the state > change > > > - As I stated in other thread recently, although we introduced a > way to > > > deal with classList, since is not part of UIBase, we can see it's > not > > > playing nicely with the rest of Royale and it's causing to > introduce more > > > code in lost of classes (checking for ClassSelectorList in Jewel > and > > Basic > > > Code will discover all places where I had to inject the same code, > what > > > seems not optimal. > > > > > > So, I think we should refactor now (post release) how we deal with > class > > > names (before the ball gets bigger), and think a way to play with > > > transitions and effects in a more Royale way. I think first is very > > needed, > > > and second can wait a bit more... > > > > > > For example for HTML, I envision using StatesWithTransitionImpl to > deal > > > with class selectors that will play, in HTML, transitions, so > > effectStart, > > > transitionStart, or effectEnd, or transitionEnd, could make an > > "addClass", > > > "removeClass" or "toggleClass" and the those class selectors will > define > > > the platform (in this case CSS) way to deal with the effect, and > avoid > > hard > > > coding that in AS3 code. > > > > > > Another side problem here is that we need to include @keyframe in > > compiler > > > since Royale, as today, don't know how to deal with this. > > > > > > Thoughts? > > > > > > > > > > > > El vie., 14 sept. 2018 a las 8:45, Alex Harui > (<[email protected] > > >) > > > escribió: > > > > > >> Hi Carlos, > > >> > > >> We have not devoted much time and energy to an effects subsystem, > so > > maybe > > >> you will be the pioneer in this area. > > >> > > >> In my mind, there will be at least two kinds of effects subsystem: > > >> planned and unplanned. > > >> > > >> In a planned effects subsystem, the assumption is that most users > will > > >> want to implement an effect/transition. The > StatesWithTransitionsImpl > > is > > >> an early example of that. Such a subsystem should have a > "lifecycle". > > A > > >> known set of events should be dispatched that provide useful > > opportunities > > >> to change the effects start and end conditions. For state > changes, the > > >> events should be something like transitionStart, transitionEnd, > > >> stateChanged. For your cases, the events might be something like > > >> effectStart, effectEnd, open/close. If you get the right set of > events, > > >> then the work you want to defer should happen on an lifecycle > event > > instead > > >> of a timer event. > > >> > > >> In an unplanned effects subsystem, the event system is more > > >> sophisticated. The assumption is that it will be rare to have an > > effect in > > >> response to some change in the component. So hide/show effects, > > selection > > >> and focus effects and things like that would be "unplanned". I > hope we > > >> can find a way to do this in a PAYG way with different/heavier > beads, > > but > > >> that is a bit tricky for hide/show since it is built into > UIBase. In an > > >> unplanned system, there will either be cancelable "ing" events or > the > > >> target classes have to be able to reverse a property change > without > > >> flicker. > > >> > > >> For example, right now if you set the UIBase visible property to > false, > > >> the component becomes invisible immediately. And similarly if > you set > > >> visible=true, the component becomes visible immediately. Adding > > unplanned > > >> effect support to visible would require dispatching a cancelable > > >> visibleChanging event before actually setting the browser's CSS > display > > >> property that an effect instance would listen for and cancel, > then wait > > for > > >> the effectEnd event and then finally actually set the visible > > property. Or > > >> we'd have to be confident that you can set the CSS display > property and > > set > > >> it back without flicker. > > >> > > >> In summary, having the right events should eliminate the need for > timing > > >> events. > > >> > > >> My 2 cents, > > >> -Alex > > >> > > >> > > >> On 9/13/18, 2:34 PM, "Carlos Rovira" <[email protected]> > wrote: > > >> > > >> Hi Alex, > > >> I'm with you. Don't like setTimeOut. But I needed in Jewel in > at > > least > > >> 3 > > >> scenearios. I'd love to change it sometime in the future, but > for now > > >> don't > > >> know how. > > >> I think the actual ways to defer something are: > > >> -setTimeOut > > >> -setInterval > > >> -requestAnimationFrame > > >> > > >> the first one is in SWF, so the solution is cross SWF/JS, > although if > > >> we > > >> add other targets, maybe will require changes. > > >> the second seems to be the worse. > > >> the latest seems the actual way to do things in JS, but I > tried and > > >> didn't > > >> work for me, and I suppose we'll need to abstract it to > something > > >> usable in > > >> SWF and future targets. > > >> > > >> My concrete case in the three ocassions is when I instantiate a > > >> component > > >> and add a class name to make the component animate > (transition) > > >> through > > >> CSS. For example Alert, DateField and ComboBox popups > components and > > >> then > > >> add a class ".open" in CSS, so we need at least 300-400ms so > the > > >> transition > > >> can play. > > >> > > >> Any other way to do it would be good to know in order to > upgrade this > > >> implementations. > > >> > > >> Thanks > > >> > > >> Carlos > > >> > > >> -- > > >> Carlos Rovira > > >> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=CKs33Ct8MEVeGy6s6Ce3Gywbylnsj1qdRn4jS%2F7G8cA%3D&reserved=0 > > >> > > >> > > >> > > >> > > > > > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=CKs33Ct8MEVeGy6s6Ce3Gywbylnsj1qdRn4jS%2F7G8cA%3D&reserved=0 > > >
