incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: Halo x Spark
Date Sat, 24 Mar 2012 10:49:05 GMT
Oleg,

I'm not saying that the problems you are point are not there, but if we are
commeting between halo vs spark. I think the later is the way to go. MX was
a component set brought from the Flash MX and MX 2004 days. It has many
problems, more than spark.

If this discussion is about to choose a way. We should think about make
spark better, since make mx better is not an option. The other way should
be a third new component set that address from scratch all problems. But
that could happen in the long term since that should required lots of work,
and that would not require to be called Flex and all the hard work to move
flex from adobe to apache. That could be done from scratch as a new Apache
project.

So we should discuss things that could be done and should be possible.
Spark is the recommended component set in flex right now. we should work to
make it better. Take other way could definitely kill flex since we should
end doing nothing.

Maybe a better component set could be make in the following years but to
make it happen we first need to make apache flex success...



2012/3/24 Left Right <olegsivokon@gmail.com>

> Carlos,
> I've just explained why using Spark skins sometimes is absolutely
> impossible - they are literary order of magnitude bigger and slower then
> their Halo counterparts. This may be a weak argument in the light of how
> the entire framework is slow and bloated, but there are always certain
> requirements and at times it just becomes the straw that breaks the neck of
> the proverbial camel.
>
> I'm not trying to protect Halo components in particular - I don't think
> they were better designed or anything. It just happened so by chance that
> they were smaller and there was a shorter tool chain that made it possible
> to skin them. I think that ignoring the problem introduced by the change is
> short sighted. There is a problem: a longer tool chain, a more complicated
> development process, a less optimal outcome - you can't really ignore
> that...
>
> Best.
>
> Oleg
>



-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid

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