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://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 > >> > >> > >> > >> > > -- Carlos Rovira http://about.me/carlosrovira
