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://greensock.com/gsap <https://greensock.com/gsap> > 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 >> http://about.me/carlosrovira >> >> >> >>
