I totally agree and I can wrap up a SWC of Tweener for sure as I'm using it already, but will need to ensure it's compatibility with Royale.
On Fri, Sep 14, 2018 at 11:38 AM Alex Harui <[email protected]> wrote: > 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 > > > > > > > > >
