incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jude <flexcapaci...@gmail.com>
Subject Re: Petition: Flash Catalyst must survive
Date Fri, 13 Jan 2012 10:17:28 GMT
Geez guys. Why is everyone against design views? I'm all for Flash
Catalyst. I'm all for what it was trying to solve. I agree, it wasn't
complete but neither is Flash Builder or the Spark Flex SDK.

I don't know about you but I'm tired of writing out Path data="M 0 0 L 0 16
L 16 8 L 0 0 Z" to create a simple triangle. You shouldn't have to do that.
In Ps and Ai what you see is what you get. It's setup so you can change a
property or effect and see the change instantly. It's fast. How much time
do you waste by the change property, style or effect, compile (+/- 15s),
preview in browser, rinse, repeat process? It's sooooo agonizingly slow. I
mean I think most of us come from a design background and designer tools???

Fc had a timeline and effects preview. It let you see the different states
and skins. It created the FXG and MXML and import and export of Ps and Ai
art. I don't like having to create 5 skins to change the look of a scroll
bar button. With Flash Catalyst I didn't have to worry about that.

I think that's been an advantage of Flex and Flash over HTML / JS is that
there is a design / debugging tool with declarative markup or the promise
of one (or there was).
<http://www.youtube.com/watch?v=-brqopywIB0&feature=youtube_gdata>
In time I think it would have been a kick ass tool. I'm glad they kept a
design builder tool in mind for Spark. I know a lot of coders that get so
comfortable in coding and doing everything in code including design
elements that they forget the benefits of a design tool and design first
approach.

On Tue, Jan 10, 2012 at 12:01 PM, Doug McCune <doug@dougmccune.com> wrote:

> The saddest thing to me is how much time and effort went into building an
> entirely new (yet still incomplete) component model (Spark) that was built
> all around the idea of Catalyst. That's not to say that the Spark
> architecture doesn't have good ideas when you remove Catalyst from the
> picture, but the amount of time that went into designing it to work with
> the Fc tooling was all for naught. I have to believe many decisions would
> have been made differently, and a lot of time would have been invested
> differently had the Catalyst tooling support not been the priority.
>
> Personally I'm happy to see Catalyst go, and would have been happier to see
> it go long ago.
>

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