On 3/14/13 12:55 PM, "Om" <bigosma...@gmail.com> wrote:
> On Thu, Mar 14, 2013 at 12:07 PM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>>
>>
>> On 3/14/13 10:36 AM, "Om" <bigosma...@gmail.com> wrote:
>>
>>>> FWIW, the new framework I'm working on is probably going to be less
>> vector
>>>> graphic oriented and rely on bitmaps since I think bitmaps are how most
>>>> things get "skinned" in html/js/css
>>>>
>>>>
>>> This really worries me. Are you saying that we dont want to support FXG
>> in
>>> FlexJS?
>> I eventually want to support everything, but time is of the essence, and I
>> am going to prioritize stuff that we can get done quickly and that performs
>> well. I'm not an expert, but I'm told that bitmaps work better in the GPU
>> than vectors.
>>
>
> It does not have to be an either-or choice. As I said, FXG supports
> capability of skinning with just bitmaps.
I guess I don't understand what you mean. I've haven't seen too many FXG
files, but what percentage are bitmap only? I don't think I've seen that.
> Why not work with that as the
> primary use case.
Because you said that only modern browsers support SVG skinning of HTML5
elements. I also believe in setting expectations low and exceeding them.
If you say you support FXG, you'd better be able to support the 80% case,
and that sounds like a bunch of work that I don't want to take on, but would
love to see someone else take on.
My personal goal is to find at least one large Adobe customer to adopt
FlexJS this year. This will help increase my chances of continuing to work
on Apache Flex full time. IIRC, last time we asked, many of these same
large Adobe customers are not using modern browsers.
It is either-or in the sense that I cannot do both at once so I am picking
bitmaps. But if the large Adobe customer needs vector skinning I will
certainly change course. But remember, you do not have to convince me. You
can code up the vector skinning yourself.
>>> Spark skinning paradigm is one of the best out there.
>> Aside from the fact there is a consistent way to skin components and you
>> can
>> sort of declare a skin in MXML, what else is a must-have for FlexJS?
>>
>
> Not sure if I understand your question, but here goes: I care about the
> workflow most importantly. In my mind, the idea workflow would be this:
>
> 1. Designers create visual designs of the app in tools they are
> comfortable with (Fireworks, Photoshop, etc.)
> 2. We export it to simpler assets (FXG or SVG + pngs, etc.)
> 3. We bring all the assets into the Flex project and skin the app
> 4. Users can chose Compile to SWF or Compile to HTML
>
> And the end results should be as close to each other in terms of the
> skinning of the app (in this scenario, I am less concerned about the
> business logic, etc.)
IMO, nothing you listed here requires FXG, so I would probably choose SVG.
>>
>>> Are we willing to
>>> throw it out because HTML/JS cant support it? That is not a vision of
>> Flex
>>> that existing developers would like (including me)
>>>
>>> At the very minimum, we should support the BitmapImage (and related
>>> classes) That would be better than no FXG support at all.
>> If you want to take it on, go ahead, but I'm not sure how many Adobe tools
>> will output FXG going forward. Are you willing to run an older version to
>> keep FXG around? Especially if it doesn't perform well?
>>
>
> Older version of the tool, or older version of Flex? I dont mind if I have
> to use the older version of the tool just so that I have support for FXG.
Older version of the tool.
>
> But when working with a large team with UX designers, UI designers, I want
> the ability Flex 4 skinning paradigm. In other words, to get buy in from
> large teams with established workflows, lack of FXG skinning would be a
> deal breaker.
I don't develop pretty apps for a living, so I am still trying to get what
the important things are about Flex 4 skinning. Is it just that the
designer can draw the skin in a popular drawing tool and you can plug it
into the app?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
