IMHO I wouldn't invest more time in themes. How is it that hey can change behavior or break your app by switching between them. Specifically because when I went from the mx theme to the Spark theme features, styles and behavior I was expecting to be there wasn't. In took a lot to upgrade an app to Spark. I think maybe that was a implementation issue. I would rather they just focused on wrapping up a style sheet and skins.
Another couple issues that relate to it. Warning...this turned out to be a really long email... With mx Components they had almost every property and style I ever needed. The downside in a way was when you wanted to change the visuals you had to find all the graphics draw commands, sometimes buried across methods in actionscript. With Spark you could separate the view but it wasn't well... ...I've rewrote this paragraph 5 times now and.... I'm just going to summarize *what I had trouble with*: • *When creating a Spark skin how do you expose custom styles to the host component?* On the other side of it --> • *How do you set custom styles on a Spark component in MXML (for the purpose of passing those values to the skin)? * -- In my experience to get style values to the skin you have to create a new component that declares those styles -- Or create a style for the component type in the main application file (which would apply to all instances unless you give it a style name) and set the style and value there (what if the value is in another document?). -- Or create a style rule in the document and set the styleName property of the component to that style. I don't really like doing the style rule method in Spark. In HTML style rules work to some degree but then in HTML the layout rules are different. And also you can set size and positioning properties in addition to styles. But you can't set any property in a style rule in Spark. So then you end up using two or more locations to define the look and feel. This doesn't mean I'm against style rules. They work great for font and text related purposes. But specifically having to create a style rule or a new component to get a value into a skin just seems I don't know. In my experience the designs have been custom enough that you end up creating a one off skin or end up setting all the styles on the component instance. Also, does a style rule support bindings? I just thought of this. In summary, I would like to be able to add custom styles on the component instance. Having said all that - it completely changes if you have *tooling*. If you can see the style tree and navigate to those locations it makes all the difference. And if you have something that can create all the components and skin files you would need when creating a skin then that also changes the game. Which makes me wonder if this was ever a problem Adobe recognized and wanted to solve. *A couple more random thoughts*: • I had struggled a lot with the above before realizing I could call getStyle() in the skin it will get styles from the host component. I used hostComponent.getStyle(). I didn't fully understand skin inherited the styles from the host component. In skinnable component the styleName property is able to accept an object and inherit the styles defined on that object. So when the skin is created the skin styleName is to the host component. • Skins seem to have different component life cycle. So I expected things to behave the same. You have to know a lot about the framework. * Skins and components still have draw commands scatter about that interfere with look and feel. In skins you have the updateDisplayList but I think it should be all defined by MXML. For example, a designer should be able to create a skin without using actionscript. I say with care that Flash Catalyst accomplished aspects of this. It needed more time and more components and more states exposed as well as supporting or exposing styles in some way etc. but what took a few days took before now took a few minutes AND (a huge and) YOU COULD SEE IT! RT Photoshop creating spark component skins. * Oh it drove me nuts when the compiler didn't let me set styles because it wasn't part of the theme. Ex. Add a DataGrid to a mobile application then try to set styles on it (styles that work). The compiler won't allow it to be compiled. * Excluded styles drove me nuts too. In some class some styles were excluded possibly because it wasn't supported. The problem is you might create a skin that does support that style and so you now need to be able to set that style. * Skins can't be defined inline. This would make them much more readable. * spark skins removed styles (that I used regularly) that were in the mx components (see Spark Datagrid) *Solutions* * support setting custom styles on components. possibly "styles" array or object <styles><myStyle>#FF00FF</myStyle><borderColor></borderColor></styles> * allow excluded styles * allow styles from other themes (mobile theme excludes spark styles that actually work) * allow skins to inherit from itemrenderer or make skins as simple as item renderers * allow skins inline * add more styles on the skins or at least the same that were in the mx counter parts On Sat, Feb 25, 2012 at 11:54 PM, David Francis Buhler < davidbuh...@gmail.com> wrote: > I suppose my biggest issue is with the Zen theme and the Wood theme. They > seem so silly; perhaps more gimmicky than they should be given the typical > use-cases for [Adobe] Flex. > > Each client I've had used Flex for Transactional Software except 1. Most of > the projects [except 1], have built internal-facing products. I can't think > of many use-cases where a Flex Application will be spruced up with a "Wood" > theme or where my client reaches a state of peace with a "Zen" theme. > > [1] > > http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7f85.html#WS2db454920e96a9e51e63e3d11c0bf69084-7e8c > > >
