Reflex Component Roadmap

5 views
Skip to first unread message

RickB

unread,
Apr 10, 2010, 10:17:41 AM4/10/10
to Reflex Platform
Arguably, one of the shortcomings of Flex 4 is the lack of a
comprehensive set of Spark components when compared to their Halo/Flex
3 peers. It would be a bummer if Reflex was similarly disadvantaged
in terms of breadth of components over the long term. Out of
curiosity, is there a roadmap/plan for specific UI components?

Also, in the context of functional parity with the Flex SDK, are there
any plans to collaborate with the Degrafa team to allow Degrafa to
play an FXG-like role along with Reflex? And on a related topic, is
anyone contemplating a graphing/charting framework for Reflex?

These are all areas we would be willing to support and contribute to,
but I wanted to get a quick pulse as to what other activities were
underway already.

Thanks.

Rick

Jacob Wright

unread,
Apr 10, 2010, 11:30:35 AM4/10/10
to reflex-...@googlegroups.com
Arguably, one of the shortcomings of Flex 4 is the lack of a
comprehensive set of Spark components when compared to their Halo/Flex
3 peers.  It would be a bummer if Reflex was similarly disadvantaged
in terms of breadth of components over the long term.   Out of
curiosity, is there a roadmap/plan for specific UI components?

We don't. We do plan on providing as many different types of components as possible. I personally won't be satisfied until we have more than Spark and Halo.

 
Also, in the context of functional parity with the Flex SDK, are there
any plans to collaborate with the Degrafa team to allow Degrafa to
play an FXG-like role along with Reflex?  And on a related topic, is
anyone contemplating a graphing/charting framework for Reflex?

Yes, we have had talks with some members on the Degrafa team about putting together a Flex-independent FXG/graphics library that is lighter than Degrafa. They seem very interested to collaborate on that.
 
These are all areas we would be willing to support and contribute to,
but I wanted to get a quick pulse as to what other activities were
underway already.

We love contributions! Anything you can do to help with the project is welcome. It's still early so getting into things does take a bit more effort.

Jacob

Tyler Wright

unread,
Apr 10, 2010, 11:53:21 AM4/10/10
to reflex-...@googlegroups.com
I also intend to contribute to a light-but-powerful graphics framework. I would like to use it in Flex, Reflex and ActionScript-only projects.

Should this be part of the Reflex code-base or something else? Degrafa is more powerful than what I need, I'd rather start with a simpler and lighter base that can be extended. I would also like to see it designed under the FXG specification to be standardized and familiar going into the future.

Tyler

James Ward

unread,
Apr 10, 2010, 12:34:48 PM4/10/10
to reflex-...@googlegroups.com
There other benefit of FXG is the native FP support (swftags). Super fast graphics primitives can have a big impact on overall app performance and memory usage. Another benefit of going FXG is the integration with the CS.

-James


From: Tyler Wright <xty...@gmail.com>
Date: Sat, 10 Apr 2010 09:53:21 -0600
Subject: Re: Reflex Component Roadmap

RickB

unread,
Apr 16, 2010, 10:43:59 AM4/16/10
to Reflex Platform
That's an interesting dilemma, James. A couple of weeks ago, I would
have said the same thing. However, with Microsoft's recent
announcement of support for SVG in IE9, I think the situation has
changed dramatically. Personally, I thought it a mistake for Adobe to
create FXG instead of leveraging a subset/profile of SVG. Most of the
arguments for creating FXG weren't all that convincing. Perhaps as
part of the Reflex planning process we could explore an alternative
option (SVG, perhaps leveraging the Degrafa engine). I expect SVG
tooling to grow as well over the next couple years. I really would
prefer a cross-platform/cross-UI standard.

On Apr 10, 12:34 pm, "James Ward" <ja...@jamesward.org> wrote:
> There other benefit of FXG is the native FP support (swftags).  Super fast graphics primitives can have a big impact on overall app performance and memory usage.  Another benefit of going FXG is the integration with the CS.
>
> -James
>
>
>
> -----Original Message-----
> From: Tyler Wright <xty...@gmail.com>
> Date: Sat, 10 Apr 2010 09:53:21
> To: <reflex-...@googlegroups.com>
> Subject: Re: Reflex Component Roadmap
>
> I also intend to contribute to a light-but-powerful graphics framework. I
> would like to use it in Flex, Reflex and ActionScript-only projects.
>
> Should this be part of the Reflex code-base or something else? Degrafa is
> more powerful than what I need, I'd rather start with a simpler and lighter
> base that can be extended. I would also like to see it designed under the
> FXG specification to be standardized and familiar going into the future.
>
> Tyler
>
> On Sat, Apr 10, 2010 at 9:30 AM, Jacob Wright <jacwri...@gmail.com> wrote:
>
> > Arguably, one of the shortcomings of Flex 4 is the lack of a
> >> comprehensive set of Spark components when compared to their Halo/Flex
> >> 3 peers.  It would be a bummer if Reflex was similarly disadvantaged
> >> in terms of breadth of components over the long term.   Out of
> >> curiosity, is there a roadmap/plan for specific UI components?
>
> > We don't. We do plan on providing as many different types of components as
> > possible. I personally won't be satisfied until we have more than Spark and
> > Halo.
>
> >> Also, in the context of functional parity with the Flex SDK, are there
> >> any plans to collaborate with the Degrafa team to allow Degrafa to
> >> play an FXG-like role along with Reflex?  And on a related topic, is
> >> anyone contemplating a graphing/charting framework for Reflex?
>
> > Yes, we have had talks with some members on the Degrafa team about putting
> > together a Flex-independent FXG/graphics library that is lighter than
> > Degrafa. They seem very interested to collaborate on that.
>
> >> These are all areas we would be willing to support and contribute to,
> >> but I wanted to get a quick pulse as to what other activities were
> >> underway already.
>
> > We love contributions! Anything you can do to help with the project is
> > welcome. It's still early so getting into things does take a bit more
> > effort.
>
> > Jacob
>
> --
> To unsubscribe, reply using "remove me" as the subject.- Hide quoted text -
>
> - Show quoted text -

Tyler Wright

unread,
Apr 16, 2010, 11:46:15 AM4/16/10
to reflex-...@googlegroups.com
That's an interesting dilemma, James.  A couple of weeks ago, I would
have said the same thing.  However, with Microsoft's recent
announcement of support for SVG in IE9, I think the situation has
changed dramatically.  Personally, I thought it a mistake for Adobe to
create FXG instead of leveraging a subset/profile of SVG.  Most of the
arguments for creating FXG weren't all that convincing.  Perhaps as
part of the Reflex planning process we could explore an alternative
option (SVG, perhaps leveraging the Degrafa engine).  I expect SVG
tooling to grow as well over the next couple years.  I really would
prefer a cross-platform/cross-UI standard.

Reflex is capable of supporting any graphical approach the Flash Player can handle: FXG, SVG, timeline graphics, Degrafa. Because ISkin and Skin are non-denominational instructions for rendering Sprites it will be a simple matter to create an SVGSkin that ties in an AS3 SVG library.

Tyler

Reply all
Reply to author
Forward
0 new messages