incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jude <flexcapaci...@gmail.com>
Subject Re: [IDEAS] Flex: New user interface design
Date Tue, 28 Feb 2012 06:16:18 GMT
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 <
davidbuhler@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
>
>
>

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