royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenny Lerma <ke...@kennylerma.com>
Subject Re: Royale Transitions, Effects, States infrastructure [was: Re: [royale-asjs] branch develop updated: I think this fixes Menu]
Date Fri, 14 Sep 2018 16:30:34 GMT
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.
http://hosted.zeh.com.br/tweener/docs/en-us/




On Fri, Sep 14, 2018 at 11:23 AM Alex Harui <aharui@adobe.com.invalid>
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" <carlosrovira@apache.org> 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 (<harbs.lists@gmail.com>)
>     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&amp;data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735947429&amp;sdata=mCQxXT6%2FzwI35gAhDoBbfPWkEUSwUGBUvFyZwME3i94%3D&amp;reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&amp;data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735957438&amp;sdata=7kGIZpj4g6bFkWXKyz%2BDwDG0x4VGhFQbEeDgeQnPWPI%3D&amp;reserved=0
> >
>     >
>     > > On Sep 14, 2018, at 10:36 AM, Carlos Rovira <
> carlosrovira@apache.org>
>     > 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
> (<aharui@adobe.com.invalid
>     > >)
>     > > 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" <carlosrovira@apache.org>
> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735957438&amp;sdata=GaQKQ9ia22sYICn5XY26T8DYbgbtnBstHc%2FshO%2F%2F4Rw%3D&amp;reserved=0
>     > >>
>     > >>
>     > >>
>     > >>
>     >
>     >
>
>     --
>     Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735957438&amp;sdata=GaQKQ9ia22sYICn5XY26T8DYbgbtnBstHc%2FshO%2F%2F4Rw%3D&amp;reserved=0
>
>
>

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