royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <>
Subject Re: Royale Transitions, Effects, States infrastructure [was: Re: [royale-asjs] branch develop updated: I think this fixes Menu]
Date Fri, 14 Sep 2018 09:34:15 GMT
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,

[1] <>

> On Sep 14, 2018, at 10:36 AM, Carlos Rovira <> 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 (<>)
> 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" <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message