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 > > > >
