1 person found this helpful
1. The main premise of Spark is that you have a development workflow that
involves a graphic designer who can draw but can't code. That's why there
are fewer styles. Instead of having the designer learn all of the style
properties, they just draw what they want it to look like and that becomes a
new skin or a portion of a new skin. There are Spark styles for things that
you commonly change at runtime, but not as many for tweaking every aspect of
If you like the old workflow where we have code-based skins with lots of
styles that affect most of the visual aspects, you can revert the MX
components to use the Halo theme or design your own theme with programmatic
skins and lots of styles.
So, the alternative for "missing styles" is custom skins.
2. Assuming you have a graphic designer available, there are still a couple
of common workflows that involve designers. Catalyst is a tool for a
particular development workflow where the designer draws what the app should
look like and then the designer or someone else carves up the drawing into
components. There is little support for writing tons of code as the
Catalyst user is not expected to be a programmer. Not all apps can be
created this way, and not all components are serviced by Catalyst partly
because the configuration of some components didn't map well to the Catalyst
workflow and partly because we ran out of time.
The alternative workflow where you write code and solicit input from a
graphic designer along the way is still supported by Flash Builder 4.
3. Spark Scroller is a container and Charts are MX controls. I don't think
we support putting containers in MX controls. I'm not sure what you are
trying to achieve, but normally, you would put the Chart in a Spark
Scroller, not the other way around.
4. Spark is built as a layer on top of the MX UIComponent infrastructure
and has new capabilities like support for rotation and z, and the new
FTE/TLF text engine. There is a cost to being a layer, but in general, we
haven't seen it to be significant. If you have a simple test case, please
file a bug so we can track the investigation.
We have seen measurable performance issues with FTE/TLF as it has to do more
thinking in order to be able to handle right-to-left languages so if your
app is heavily text-driven, you might be seeing that. 4.1 should contain
significant improvements in FTE/TLF performance, although it still may be a
bit slower than the old TextField. But that's the going price of bi-di
Thank you very much for your detailed and helpful reply.
Tough, we are still confused about how should it all work.
We have a large group of experienced Flex developers and we also have a pretty large group of Graphical designers, experienced working with Illustrator, Photoshop and Fireworks.
If not Catalyst what would you say be the most comprehensive tool for them to use in order to produce Spark Skins? By comprehensive I mean contains the more components and can edit most of their properties?
Ideally, from our perspective, the designer should produce the skin without a programmer having to edit it- all the programmer would have to do is import the files the designer created in CS4 or the like.
What should be then the recommended workflow in the case of Spark?