You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Sebastian Mohr <fl...@gmail.com> on 2013/03/14 19:35:02 UTC
FXG 2.0 donation progress concerns and Adobe design tool support
Hi,
In regards to FXG, I have a couple of questions:
I wonder about the current state of the FXG 2.0 donation
process [1]. Is FXG 2.0 already part of Apache Flex? If not,
does Adobe still plan to donate it?
What would happen if FXG 2.0 would be part of Apache Flex?
Would Adobe still support the FXG 2.0 format in the existing
Adobe tools [2]? What would happen if Apache Flex would decide
to work on a new version of FXG ... e.g. FXG 3.0? Would Adobe
still be interested to support the forthcoming versions of FXG if
FXG would be in the hands of Apache Flex?
I also wonder how closely FXG 2.0 is interweaved with the
current Flashplayer 11.6? If FXG 2.0 is so tightly interweaved
with the Flashplayer, wouldn't it be better if Adobe takes
care of FXG 2.0 instead of us?
Thanks for your answers!
[1] http://sourceforge.net/adobe/flexsdk/wiki/FXG%202.0%20Specification/
[2]
https://cwiki.apache.org/confluence/display/FLEX/Designer+&+Developer+Tools
--
Sebastian (PPMC)
Interaction Designer
Looking for a Login Example with Apache Flex? Please check out this code:
http://code.google.com/p/masuland/wiki/LoginExample
Re: FXG 2.0 donation progress concerns and Adobe design tool
support
Posted by Michael Schmalle <ap...@teotigraphix.com>.
The Falcon compiler has an FXG parser/compiler and transcoder.
Currently covers FXG 1.0 and FXG 2.0 for the
"http://ns.adobe.com/fxg/2008" namespace.
Mike
Quoting Sebastian Mohr <fl...@gmail.com>:
> Hi,
>
> In regards to FXG, I have a couple of questions:
>
> I wonder about the current state of the FXG 2.0 donation
> process [1]. Is FXG 2.0 already part of Apache Flex? If not,
> does Adobe still plan to donate it?
>
> What would happen if FXG 2.0 would be part of Apache Flex?
> Would Adobe still support the FXG 2.0 format in the existing
> Adobe tools [2]? What would happen if Apache Flex would decide
> to work on a new version of FXG ... e.g. FXG 3.0? Would Adobe
> still be interested to support the forthcoming versions of FXG if
> FXG would be in the hands of Apache Flex?
>
> I also wonder how closely FXG 2.0 is interweaved with the
> current Flashplayer 11.6? If FXG 2.0 is so tightly interweaved
> with the Flashplayer, wouldn't it be better if Adobe takes
> care of FXG 2.0 instead of us?
>
> Thanks for your answers!
>
> [1] http://sourceforge.net/adobe/flexsdk/wiki/FXG%202.0%20Specification/
> [2]
> https://cwiki.apache.org/confluence/display/FLEX/Designer+&+Developer+Tools
>
>
> --
> Sebastian (PPMC)
> Interaction Designer
>
> Looking for a Login Example with Apache Flex? Please check out this code:
> http://code.google.com/p/masuland/wiki/LoginExample
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Sebastian Mohr <fl...@gmail.com>.
@Nicholas ...
*> Dosen't FXG also support bitmaps, effects, and other things as well?
[...] *
*> Would those elements be able to be supported with SVG? (I really am
asking*
*> on that one. The last time I dealt with SVG was in 2002 for a mapping
application).
*
SVG 1.1 document [1] recommends the Image Element [2], Filter Effects [3],
SMIL Animations [4] ... etc., but, am not sure which web browser supports
it.
*> FXG was only supported in CS 5.0 and 5.5. 6.0 and 6.1 *
*> no longer support FXG without a hard-to-find plugin)
*
Which FXG "hard-to-find plugin" for CS6 are you referring to? I haven't
had the chance to work with CS6, but, I am pretty happy with my CS5.5.
[1] http://www.w3.org/TR/SVG/single-page.html
[2] http://www.w3.org/TR/SVG/single-page.html#chapter-filters
[3] http://www.w3.org/TR/SVG/single-page.html#struct-ImageElement
[4] http://www.w3.org/TR/SVG/single-page.html#chapter-animate
--
Sebastian (PPMC)
Interaction Designer
Looking for a Login Example with Apache Flex? Please check out this code:
http://code.google.com/p/masuland/wiki/LoginExample
On Mon, Mar 18, 2013 at 4:51 PM, Nicholas Kwiatkowski <ni...@spoon.as>wrote:
> Dosen't FXG also support bitmaps, effects, and other things as well? I
> thought that is how the support with Photoshop worked (btw, FXG was only
> supported in CS 5.0 and 5.5. 6.0 and 6.1 no longer support FXG without a
> hard-to-find plugin). Would those elements be able to be supported with
> SVG? (I really am asking on that one. The last time I dealt with SVG was
> in 2002 for a mapping application).
>
> -Nick
>
> On Thu, Mar 14, 2013 at 6:14 PM, Om <bi...@gmail.com> wrote:
>
> > On Thu, Mar 14, 2013 at 1:24 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> > >
> > >
> > >
> > > On 3/14/13 1:02 PM, "Om" <bi...@gmail.com> wrote:
> > >
> > > >> Don't PhotoShop and Illustrator output SVG as well? What is it
> about
> > > FXG
> > > >> that is a must-have especially if you are targeting HTML and not
> > Flash?
> > > >
> > > >
> > > > This implies that I need to decide on the target (HTML vs. Flash)
> > before
> > > I
> > > > even start designing the skin for the app. Is that what you expect
> > > > developers to do with FlexJS?
> > > Nope, I think they should just choose SVG, and FlexJS and its compiler
> > > should try to convert it into Flash assets when running on Flash.
> >
> >
> > Right, except that when the user chooses the SVG route, that eliminates
> > support for older browsers.
> >
> >
> > > Frankly,
> > > I'm not sure if it has to do a great job in terms of fidelity or
> > > performance. For most folks, the end goal is to get a great HTML/JS
> app.
> > > The SWF version is so you can develop and test as much as possible
> before
> > > cross-compiling.
> > >
> > >
> > If I may suggest an alternative approach, I would use the SWF version to
> > support older browsers. Remember, Flash Player for Desktop is still very
> > prevalent.
> >
> > For the newer browsers that support do support inline SVG, we can convert
> > FXG to SVG and we have a viable non-swf alternative. This is a more
> > future-safe approach, IMHO.
> >
> > >
> > > > My point is that we have tools that create FXG, we have AS code that
> > can
> > > > work with FXG. I believe it is a more efficient approach run with
> FXG
> > > and
> > > > make it work with HTML/JS. The end result would make the SDK users
> > that
> > > > much happier.
> > > The AS code that works with FXG probably uses a lot of Flash APIs, so
> it
> > > can't be cross-compiled efficiently to JS. If you can write an
> efficient
> > > FXG renderer on the JS side, please do so.
> > >
> >
> > No, thats not what I meant. I said "AS code can work *with *FXG". This
> > can be translated to JS code working with SVG. AS to JS translation is
> > what you guys are working on. FXG to SVG XMSLT transformation is
> > (hopefully) the only missing link.
> >
> >
> >
> > > >
> > > > On the flip side, you have not convinced me that we should drop FXG.
> > > I am not trying to convince you to drop FXG, I am just saying that I
> > would
> > > rather write code to support SVG instead and may do so after I get
> bitmap
> > > skinning working. IMO, every year, fewer and fewer new releases of
> tools
> > > will output FXG unless we can show the world a reason it is better than
> > > SVG.
> > >
> > > But again, you or anyone is welcome to write the FXG support, and I
> will
> > > welcome it.
> > >
> >
> > I will hopefully get to work on it sooner than later. I want to put this
> > idea out and let you guys kick the tires to see if I am missing something
> > obvious.
> >
> > Thanks,
> > Om
> >
>
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
Dosen't FXG also support bitmaps, effects, and other things as well? I
thought that is how the support with Photoshop worked (btw, FXG was only
supported in CS 5.0 and 5.5. 6.0 and 6.1 no longer support FXG without a
hard-to-find plugin). Would those elements be able to be supported with
SVG? (I really am asking on that one. The last time I dealt with SVG was
in 2002 for a mapping application).
-Nick
On Thu, Mar 14, 2013 at 6:14 PM, Om <bi...@gmail.com> wrote:
> On Thu, Mar 14, 2013 at 1:24 PM, Alex Harui <ah...@adobe.com> wrote:
>
> >
> >
> >
> > On 3/14/13 1:02 PM, "Om" <bi...@gmail.com> wrote:
> >
> > >> Don't PhotoShop and Illustrator output SVG as well? What is it about
> > FXG
> > >> that is a must-have especially if you are targeting HTML and not
> Flash?
> > >
> > >
> > > This implies that I need to decide on the target (HTML vs. Flash)
> before
> > I
> > > even start designing the skin for the app. Is that what you expect
> > > developers to do with FlexJS?
> > Nope, I think they should just choose SVG, and FlexJS and its compiler
> > should try to convert it into Flash assets when running on Flash.
>
>
> Right, except that when the user chooses the SVG route, that eliminates
> support for older browsers.
>
>
> > Frankly,
> > I'm not sure if it has to do a great job in terms of fidelity or
> > performance. For most folks, the end goal is to get a great HTML/JS app.
> > The SWF version is so you can develop and test as much as possible before
> > cross-compiling.
> >
> >
> If I may suggest an alternative approach, I would use the SWF version to
> support older browsers. Remember, Flash Player for Desktop is still very
> prevalent.
>
> For the newer browsers that support do support inline SVG, we can convert
> FXG to SVG and we have a viable non-swf alternative. This is a more
> future-safe approach, IMHO.
>
> >
> > > My point is that we have tools that create FXG, we have AS code that
> can
> > > work with FXG. I believe it is a more efficient approach run with FXG
> > and
> > > make it work with HTML/JS. The end result would make the SDK users
> that
> > > much happier.
> > The AS code that works with FXG probably uses a lot of Flash APIs, so it
> > can't be cross-compiled efficiently to JS. If you can write an efficient
> > FXG renderer on the JS side, please do so.
> >
>
> No, thats not what I meant. I said "AS code can work *with *FXG". This
> can be translated to JS code working with SVG. AS to JS translation is
> what you guys are working on. FXG to SVG XMSLT transformation is
> (hopefully) the only missing link.
>
>
>
> > >
> > > On the flip side, you have not convinced me that we should drop FXG.
> > I am not trying to convince you to drop FXG, I am just saying that I
> would
> > rather write code to support SVG instead and may do so after I get bitmap
> > skinning working. IMO, every year, fewer and fewer new releases of tools
> > will output FXG unless we can show the world a reason it is better than
> > SVG.
> >
> > But again, you or anyone is welcome to write the FXG support, and I will
> > welcome it.
> >
>
> I will hopefully get to work on it sooner than later. I want to put this
> idea out and let you guys kick the tires to see if I am missing something
> obvious.
>
> Thanks,
> Om
>
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Alex Harui <ah...@adobe.com>.
Falcon is made up of sub-compilers. There is one for FXG. Just because it
spits out AS of a certain format right now doesn't the JS output will be a
straight up translation of it. I can be anything.
I think Om and I are waiting to see if the HTML5 button with skinning really
does have rendering differences between browsers.
In my view of FlexJS there will be multiple buttons to choose from. If you
want to code up one that isn't accessible but uses Canvas, feel free. I'm
coding up buttons that leverage DOM widgets because it is small and fast so
I can get something out there for folks to try.
On 3/17/13 2:26 PM, "jude" <fl...@gmail.com> wrote:
> Om,
>
> There's FXG and SVG but there's also HTML5 canvas element.
>
> You probably already know this but FXG is made up of graphic primitives
> such as Rect, Path, Ellipse, Stroke, Fill and BitmapFill and so on. We also
> know that MXML / XML gets converted into ActionScript. In the case of FXG
> it gets converted into graphics commands.
>
> So this FXG:
>
> <s:Group>
> <s:Path data="Q 75 75 50 0" width="132" height="150" />
> </s:Group>
> gets converted into something like this the MXMLC compiler:
>
> var sprite:Sprite = new Sprite();
> sprite.width = 132;
> sprite.height = 150;
> sprite.graphics.drawPath(75,75,50,0);
> stage.addChild(sprite);
>
> And that gets converted into something lower level later on. What I was
> mentioning to Alex about is that when we go through the AS to JS
> translation we could translate graphics calls like above to the canvas
> element below:
>
> // Create canvas element
> canvas = document.createElement('canvas');
> canvas.setAttribute('width',132);
> canvas.setAttribute('height',150);
>
> var graphics = canvas.getContext('2d');
> graphics.beginPath();
> graphics.arc(75,75,50,0,Math.PI*2,true); // Outer circle
> document.addElement(canvas);
>
>
> It's not a 1 to 1 conversion but it's pretty close. Whoever spec'd out the
> canvas element took some notes from the Flash API or took some notes from
> whoever Flash took some notes from. I think we could get a much better
> representation with it than going the current way which is to use the stock
> browser and OS browser component set.
>
> The Flex button component is drawn using graphic primitives. We know that's
> always going to look the same because we control what's drawn and where. If
> we just create wrappers around the HTML controls we don't know what we will
> get and we're going to inherit all of HTML's problems. If we draw to the
> canvas what you draw is what you get.
>
> To make this work we'd have to create our own graphics api class in JS that
> was included. It could be really basic and allow use to use Flex skins,
> graphics calls and skins. The downside might be it sacrifices
> accessibility. But if it were up to me and that was the only reason why we
> hesitate to use it I'd say let's output an accessible version at the same
> time. We can do that now. We didn't have that option before. Then screen
> readers will be satisfied and we can avoid a whole mess of problems.
>
> It was brought up before but if we could choose the abstract out the
> renderer we could probably we might be able to solve a few more problems.
> When I saw Starling running the first time it was like seeing the iPhone
> retina display the first time. It's night and day. Maybe we can have a
> flash display list renderer (current), Starling 2d display list renderer,
> canvas display list renderer, webgl render or some raster bitmap display
> list renderer. These would just translate the original drawing api to the
> target api. Ok I know that's a lot of work and I'm rambling : P
>
>
> On Thu, Mar 14, 2013 at 5:14 PM, Om <bi...@gmail.com> wrote:
>
>> On Thu, Mar 14, 2013 at 1:24 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>>
>>>
>>>
>>> On 3/14/13 1:02 PM, "Om" <bi...@gmail.com> wrote:
>>>
>>>>> Don't PhotoShop and Illustrator output SVG as well? What is it about
>>> FXG
>>>>> that is a must-have especially if you are targeting HTML and not
>> Flash?
>>>>
>>>>
>>>> This implies that I need to decide on the target (HTML vs. Flash)
>> before
>>> I
>>>> even start designing the skin for the app. Is that what you expect
>>>> developers to do with FlexJS?
>>> Nope, I think they should just choose SVG, and FlexJS and its compiler
>>> should try to convert it into Flash assets when running on Flash.
>>
>>
>> Right, except that when the user chooses the SVG route, that eliminates
>> support for older browsers.
>>
>>
>>> Frankly,
>>> I'm not sure if it has to do a great job in terms of fidelity or
>>> performance. For most folks, the end goal is to get a great HTML/JS app.
>>> The SWF version is so you can develop and test as much as possible before
>>> cross-compiling.
>>>
>>>
>> If I may suggest an alternative approach, I would use the SWF version to
>> support older browsers. Remember, Flash Player for Desktop is still very
>> prevalent.
>>
>> For the newer browsers that support do support inline SVG, we can convert
>> FXG to SVG and we have a viable non-swf alternative. This is a more
>> future-safe approach, IMHO.
>>
>>>
>>>> My point is that we have tools that create FXG, we have AS code that
>> can
>>>> work with FXG. I believe it is a more efficient approach run with FXG
>>> and
>>>> make it work with HTML/JS. The end result would make the SDK users
>> that
>>>> much happier.
>>> The AS code that works with FXG probably uses a lot of Flash APIs, so it
>>> can't be cross-compiled efficiently to JS. If you can write an efficient
>>> FXG renderer on the JS side, please do so.
>>>
>>
>> No, thats not what I meant. I said "AS code can work *with *FXG". This
>> can be translated to JS code working with SVG. AS to JS translation is
>> what you guys are working on. FXG to SVG XMSLT transformation is
>> (hopefully) the only missing link.
>>
>>
>>
>>>>
>>>> On the flip side, you have not convinced me that we should drop FXG.
>>> I am not trying to convince you to drop FXG, I am just saying that I
>> would
>>> rather write code to support SVG instead and may do so after I get bitmap
>>> skinning working. IMO, every year, fewer and fewer new releases of tools
>>> will output FXG unless we can show the world a reason it is better than
>>> SVG.
>>>
>>> But again, you or anyone is welcome to write the FXG support, and I will
>>> welcome it.
>>>
>>
>> I will hopefully get to work on it sooner than later. I want to put this
>> idea out and let you guys kick the tires to see if I am missing something
>> obvious.
>>
>> Thanks,
>> Om
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by jude <fl...@gmail.com>.
Om,
There's FXG and SVG but there's also HTML5 canvas element.
You probably already know this but FXG is made up of graphic primitives
such as Rect, Path, Ellipse, Stroke, Fill and BitmapFill and so on. We also
know that MXML / XML gets converted into ActionScript. In the case of FXG
it gets converted into graphics commands.
So this FXG:
<s:Group>
<s:Path data="Q 75 75 50 0" width="132" height="150" />
</s:Group>
gets converted into something like this the MXMLC compiler:
var sprite:Sprite = new Sprite();
sprite.width = 132;
sprite.height = 150;
sprite.graphics.drawPath(75,75,50,0);
stage.addChild(sprite);
And that gets converted into something lower level later on. What I was
mentioning to Alex about is that when we go through the AS to JS
translation we could translate graphics calls like above to the canvas
element below:
// Create canvas element
canvas = document.createElement('canvas');
canvas.setAttribute('width',132);
canvas.setAttribute('height',150);
var graphics = canvas.getContext('2d');
graphics.beginPath();
graphics.arc(75,75,50,0,Math.PI*2,true); // Outer circle
document.addElement(canvas);
It's not a 1 to 1 conversion but it's pretty close. Whoever spec'd out the
canvas element took some notes from the Flash API or took some notes from
whoever Flash took some notes from. I think we could get a much better
representation with it than going the current way which is to use the stock
browser and OS browser component set.
The Flex button component is drawn using graphic primitives. We know that's
always going to look the same because we control what's drawn and where. If
we just create wrappers around the HTML controls we don't know what we will
get and we're going to inherit all of HTML's problems. If we draw to the
canvas what you draw is what you get.
To make this work we'd have to create our own graphics api class in JS that
was included. It could be really basic and allow use to use Flex skins,
graphics calls and skins. The downside might be it sacrifices
accessibility. But if it were up to me and that was the only reason why we
hesitate to use it I'd say let's output an accessible version at the same
time. We can do that now. We didn't have that option before. Then screen
readers will be satisfied and we can avoid a whole mess of problems.
It was brought up before but if we could choose the abstract out the
renderer we could probably we might be able to solve a few more problems.
When I saw Starling running the first time it was like seeing the iPhone
retina display the first time. It's night and day. Maybe we can have a
flash display list renderer (current), Starling 2d display list renderer,
canvas display list renderer, webgl render or some raster bitmap display
list renderer. These would just translate the original drawing api to the
target api. Ok I know that's a lot of work and I'm rambling : P
On Thu, Mar 14, 2013 at 5:14 PM, Om <bi...@gmail.com> wrote:
> On Thu, Mar 14, 2013 at 1:24 PM, Alex Harui <ah...@adobe.com> wrote:
>
> >
> >
> >
> > On 3/14/13 1:02 PM, "Om" <bi...@gmail.com> wrote:
> >
> > >> Don't PhotoShop and Illustrator output SVG as well? What is it about
> > FXG
> > >> that is a must-have especially if you are targeting HTML and not
> Flash?
> > >
> > >
> > > This implies that I need to decide on the target (HTML vs. Flash)
> before
> > I
> > > even start designing the skin for the app. Is that what you expect
> > > developers to do with FlexJS?
> > Nope, I think they should just choose SVG, and FlexJS and its compiler
> > should try to convert it into Flash assets when running on Flash.
>
>
> Right, except that when the user chooses the SVG route, that eliminates
> support for older browsers.
>
>
> > Frankly,
> > I'm not sure if it has to do a great job in terms of fidelity or
> > performance. For most folks, the end goal is to get a great HTML/JS app.
> > The SWF version is so you can develop and test as much as possible before
> > cross-compiling.
> >
> >
> If I may suggest an alternative approach, I would use the SWF version to
> support older browsers. Remember, Flash Player for Desktop is still very
> prevalent.
>
> For the newer browsers that support do support inline SVG, we can convert
> FXG to SVG and we have a viable non-swf alternative. This is a more
> future-safe approach, IMHO.
>
> >
> > > My point is that we have tools that create FXG, we have AS code that
> can
> > > work with FXG. I believe it is a more efficient approach run with FXG
> > and
> > > make it work with HTML/JS. The end result would make the SDK users
> that
> > > much happier.
> > The AS code that works with FXG probably uses a lot of Flash APIs, so it
> > can't be cross-compiled efficiently to JS. If you can write an efficient
> > FXG renderer on the JS side, please do so.
> >
>
> No, thats not what I meant. I said "AS code can work *with *FXG". This
> can be translated to JS code working with SVG. AS to JS translation is
> what you guys are working on. FXG to SVG XMSLT transformation is
> (hopefully) the only missing link.
>
>
>
> > >
> > > On the flip side, you have not convinced me that we should drop FXG.
> > I am not trying to convince you to drop FXG, I am just saying that I
> would
> > rather write code to support SVG instead and may do so after I get bitmap
> > skinning working. IMO, every year, fewer and fewer new releases of tools
> > will output FXG unless we can show the world a reason it is better than
> > SVG.
> >
> > But again, you or anyone is welcome to write the FXG support, and I will
> > welcome it.
> >
>
> I will hopefully get to work on it sooner than later. I want to put this
> idea out and let you guys kick the tires to see if I am missing something
> obvious.
>
> Thanks,
> Om
>
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Alex Harui <ah...@adobe.com>.
On 3/14/13 3:41 PM, "Jeffry Houser" <je...@dot-com-it.com> wrote:
> On 3/14/2013 6:38 PM, Alex Harui wrote:
>> This web-page [1] makes me more certain that bitmaps will be my first
>> attempt at a skinning model and someone else can do SVG or FXG.
>
>
> I think your [1] link appears to have been stripped out as I couldn't
> find the link in your email.
[1] http://www.codedread.com/svg-support.php
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 3/14/2013 6:38 PM, Alex Harui wrote:
> This web-page [1] makes me more certain that bitmaps will be my first
> attempt at a skinning model and someone else can do SVG or FXG.
I think your [1] link appears to have been stripped out as I couldn't
find the link in your email.
--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Alex Harui <ah...@adobe.com>.
On 3/14/13 3:14 PM, "Om" <bi...@gmail.com> wrote:
> On Thu, Mar 14, 2013 at 1:24 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 3/14/13 1:02 PM, "Om" <bi...@gmail.com> wrote:
>>
>>>> Don't PhotoShop and Illustrator output SVG as well? What is it about
>> FXG
>>>> that is a must-have especially if you are targeting HTML and not Flash?
>>>
>>>
>>> This implies that I need to decide on the target (HTML vs. Flash) before
>> I
>>> even start designing the skin for the app. Is that what you expect
>>> developers to do with FlexJS?
>> Nope, I think they should just choose SVG, and FlexJS and its compiler
>> should try to convert it into Flash assets when running on Flash.
>
>
> Right, except that when the user chooses the SVG route, that eliminates
> support for older browsers.
Are you planning on writing FXG support for older browsers?
>
>
>> Frankly,
>> I'm not sure if it has to do a great job in terms of fidelity or
>> performance. For most folks, the end goal is to get a great HTML/JS app.
>> The SWF version is so you can develop and test as much as possible before
>> cross-compiling.
>>
>>
> If I may suggest an alternative approach, I would use the SWF version to
> support older browsers. Remember, Flash Player for Desktop is still very
> prevalent.
You are welcome to code up what you think is ibest.
>
> For the newer browsers that support do support inline SVG, we can convert
> FXG to SVG and we have a viable non-swf alternative. This is a more
> future-safe approach, IMHO.
This web-page [1] makes me more certain that bitmaps will be my first
attempt at a skinning model and someone else can do SVG or FXG.
>
>>
>>> My point is that we have tools that create FXG, we have AS code that can
>>> work with FXG. I believe it is a more efficient approach run with FXG
>> and
>>> make it work with HTML/JS. The end result would make the SDK users that
>>> much happier.
>> The AS code that works with FXG probably uses a lot of Flash APIs, so it
>> can't be cross-compiled efficiently to JS. If you can write an efficient
>> FXG renderer on the JS side, please do so.
>>
>
> No, thats not what I meant. I said "AS code can work *with *FXG". This
> can be translated to JS code working with SVG. AS to JS translation is
> what you guys are working on. FXG to SVG XMSLT transformation is
> (hopefully) the only missing link.
I'm not sure it is just an XSLT, but hey, it sounds like it'll be your
problem to figure out, not mine.
>
>
>
>>>
>>> On the flip side, you have not convinced me that we should drop FXG.
>> I am not trying to convince you to drop FXG, I am just saying that I would
>> rather write code to support SVG instead and may do so after I get bitmap
>> skinning working. IMO, every year, fewer and fewer new releases of tools
>> will output FXG unless we can show the world a reason it is better than
>> SVG.
>>
>> But again, you or anyone is welcome to write the FXG support, and I will
>> welcome it.
>>
>
> I will hopefully get to work on it sooner than later. I want to put this
> idea out and let you guys kick the tires to see if I am missing something
> obvious.
>
I don't see any obvious flaws. I just think I can get some sort of skinning
working with bitmaps more quickly than by dealing with a whole lot of
vectors.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Om <bi...@gmail.com>.
On Thu, Mar 14, 2013 at 1:24 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 3/14/13 1:02 PM, "Om" <bi...@gmail.com> wrote:
>
> >> Don't PhotoShop and Illustrator output SVG as well? What is it about
> FXG
> >> that is a must-have especially if you are targeting HTML and not Flash?
> >
> >
> > This implies that I need to decide on the target (HTML vs. Flash) before
> I
> > even start designing the skin for the app. Is that what you expect
> > developers to do with FlexJS?
> Nope, I think they should just choose SVG, and FlexJS and its compiler
> should try to convert it into Flash assets when running on Flash.
Right, except that when the user chooses the SVG route, that eliminates
support for older browsers.
> Frankly,
> I'm not sure if it has to do a great job in terms of fidelity or
> performance. For most folks, the end goal is to get a great HTML/JS app.
> The SWF version is so you can develop and test as much as possible before
> cross-compiling.
>
>
If I may suggest an alternative approach, I would use the SWF version to
support older browsers. Remember, Flash Player for Desktop is still very
prevalent.
For the newer browsers that support do support inline SVG, we can convert
FXG to SVG and we have a viable non-swf alternative. This is a more
future-safe approach, IMHO.
>
> > My point is that we have tools that create FXG, we have AS code that can
> > work with FXG. I believe it is a more efficient approach run with FXG
> and
> > make it work with HTML/JS. The end result would make the SDK users that
> > much happier.
> The AS code that works with FXG probably uses a lot of Flash APIs, so it
> can't be cross-compiled efficiently to JS. If you can write an efficient
> FXG renderer on the JS side, please do so.
>
No, thats not what I meant. I said "AS code can work *with *FXG". This
can be translated to JS code working with SVG. AS to JS translation is
what you guys are working on. FXG to SVG XMSLT transformation is
(hopefully) the only missing link.
> >
> > On the flip side, you have not convinced me that we should drop FXG.
> I am not trying to convince you to drop FXG, I am just saying that I would
> rather write code to support SVG instead and may do so after I get bitmap
> skinning working. IMO, every year, fewer and fewer new releases of tools
> will output FXG unless we can show the world a reason it is better than
> SVG.
>
> But again, you or anyone is welcome to write the FXG support, and I will
> welcome it.
>
I will hopefully get to work on it sooner than later. I want to put this
idea out and let you guys kick the tires to see if I am missing something
obvious.
Thanks,
Om
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Alex Harui <ah...@adobe.com>.
On 3/14/13 1:02 PM, "Om" <bi...@gmail.com> wrote:
>> Don't PhotoShop and Illustrator output SVG as well? What is it about FXG
>> that is a must-have especially if you are targeting HTML and not Flash?
>
>
> This implies that I need to decide on the target (HTML vs. Flash) before I
> even start designing the skin for the app. Is that what you expect
> developers to do with FlexJS?
Nope, I think they should just choose SVG, and FlexJS and its compiler
should try to convert it into Flash assets when running on Flash. Frankly,
I'm not sure if it has to do a great job in terms of fidelity or
performance. For most folks, the end goal is to get a great HTML/JS app.
The SWF version is so you can develop and test as much as possible before
cross-compiling.
>
> My point is that we have tools that create FXG, we have AS code that can
> work with FXG. I believe it is a more efficient approach run with FXG and
> make it work with HTML/JS. The end result would make the SDK users that
> much happier.
The AS code that works with FXG probably uses a lot of Flash APIs, so it
can't be cross-compiled efficiently to JS. If you can write an efficient
FXG renderer on the JS side, please do so.
>
> On the flip side, you have not convinced me that we should drop FXG.
I am not trying to convince you to drop FXG, I am just saying that I would
rather write code to support SVG instead and may do so after I get bitmap
skinning working. IMO, every year, fewer and fewer new releases of tools
will output FXG unless we can show the world a reason it is better than SVG.
But again, you or anyone is welcome to write the FXG support, and I will
welcome it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Om <bi...@gmail.com>.
On Thu, Mar 14, 2013 at 12:43 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 3/14/13 12:33 PM, "Om" <bi...@gmail.com> wrote:
>
> >>
> >> I'm not sure what Adobe gains by continuing to
> >> spend resources on FXG support at this time. If you can show there
> would
> >> be
> >> a significant upside, I will try to bring that case to the right people
> in
> >> Adobe.
> >>
> >
> >
> > I am not sure how I can convince Adobe, but here is my reasoning: At my
> > current and previous companies, Fireworks is used just because of its
> > ability to convert visual designs into FXG. We dabbled with Catalyst,
> > but we found that the tool was too complicated to use for Designers, but
> > too elementary for Developers. But, the ability to serialize visual
> assets
> > as FXG turned out to be the best way to skin Flex apps.
> >
> > On the other side, I am very proficient with Photoshop and not too
> familiar
> > with Fireworks. For my simple apps, I choose to create the skins in
> > Photoshop and spit it out as FXG and just import it into Flex.
> >
> > I know other folks that used Illustrator for the same purpose. (BTW,
> > Illustrator CS6 still supports the "Save As... > FXG > FXG 2.0" option.
> I
> > just tried it out last night. Not sure what to make of this. )
> >
> > Thats the possibility of three different tools Adobe could make money of
> > off from customers who don't necessarily use these tools without FXG
> > support.
> >
> > And frankly, the absence of this utility could potentially hurt my chance
> > of making sure we dont move away from Flex where I work.
> Don't PhotoShop and Illustrator output SVG as well? What is it about FXG
> that is a must-have especially if you are targeting HTML and not Flash?
This implies that I need to decide on the target (HTML vs. Flash) before I
even start designing the skin for the app. Is that what you expect
developers to do with FlexJS?
My point is that we have tools that create FXG, we have AS code that can
work with FXG. I believe it is a more efficient approach run with FXG and
make it work with HTML/JS. The end result would make the SDK users that
much happier.
On the flip side, you have not convinced me that we should drop FXG.
Thanks,
Om
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Alex Harui <ah...@adobe.com>.
On 3/14/13 12:33 PM, "Om" <bi...@gmail.com> wrote:
>>
>> I'm not sure what Adobe gains by continuing to
>> spend resources on FXG support at this time. If you can show there would
>> be
>> a significant upside, I will try to bring that case to the right people in
>> Adobe.
>>
>
>
> I am not sure how I can convince Adobe, but here is my reasoning: At my
> current and previous companies, Fireworks is used just because of its
> ability to convert visual designs into FXG. We dabbled with Catalyst,
> but we found that the tool was too complicated to use for Designers, but
> too elementary for Developers. But, the ability to serialize visual assets
> as FXG turned out to be the best way to skin Flex apps.
>
> On the other side, I am very proficient with Photoshop and not too familiar
> with Fireworks. For my simple apps, I choose to create the skins in
> Photoshop and spit it out as FXG and just import it into Flex.
>
> I know other folks that used Illustrator for the same purpose. (BTW,
> Illustrator CS6 still supports the "Save As... > FXG > FXG 2.0" option. I
> just tried it out last night. Not sure what to make of this. )
>
> Thats the possibility of three different tools Adobe could make money of
> off from customers who don't necessarily use these tools without FXG
> support.
>
> And frankly, the absence of this utility could potentially hurt my chance
> of making sure we dont move away from Flex where I work.
Don't PhotoShop and Illustrator output SVG as well? What is it about FXG
that is a must-have especially if you are targeting HTML and not Flash?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Om <bi...@gmail.com>.
>
> I'm not sure what Adobe gains by continuing to
> spend resources on FXG support at this time. If you can show there would
> be
> a significant upside, I will try to bring that case to the right people in
> Adobe.
>
I am not sure how I can convince Adobe, but here is my reasoning: At my
current and previous companies, Fireworks is used just because of its
ability to convert visual designs into FXG. We dabbled with Catalyst,
but we found that the tool was too complicated to use for Designers, but
too elementary for Developers. But, the ability to serialize visual assets
as FXG turned out to be the best way to skin Flex apps.
On the other side, I am very proficient with Photoshop and not too familiar
with Fireworks. For my simple apps, I choose to create the skins in
Photoshop and spit it out as FXG and just import it into Flex.
I know other folks that used Illustrator for the same purpose. (BTW,
Illustrator CS6 still supports the "Save As... > FXG > FXG 2.0" option. I
just tried it out last night. Not sure what to make of this. )
Thats the possibility of three different tools Adobe could make money of
off from customers who don't necessarily use these tools without FXG
support.
And frankly, the absence of this utility could potentially hurt my chance
of making sure we dont move away from Flex where I work.
Thanks,
Om
Re: FXG 2.0 donation progress concerns and Adobe design tool support
Posted by Alex Harui <ah...@adobe.com>.
On 3/14/13 11:35 AM, "Sebastian Mohr" <fl...@gmail.com> wrote:
> Hi,
>
> In regards to FXG, I have a couple of questions:
>
> I wonder about the current state of the FXG 2.0 donation
> process [1]. Is FXG 2.0 already part of Apache Flex? If not,
> does Adobe still plan to donate it?
We have the code that compiles FXG into SWF assets.
>
> What would happen if FXG 2.0 would be part of Apache Flex?
> Would Adobe still support the FXG 2.0 format in the existing
> Adobe tools [2]?
I'm hearing it isn't in PS CS6.
> What would happen if Apache Flex would decide
> to work on a new version of FXG ... e.g. FXG 3.0? Would Adobe
> still be interested to support the forthcoming versions of FXG if
> FXG would be in the hands of Apache Flex?
Doubt it, but I can't speak for Adobe on these matters.
>
> I also wonder how closely FXG 2.0 is interweaved with the
> current Flashplayer 11.6? If FXG 2.0 is so tightly interweaved
> with the Flashplayer, wouldn't it be better if Adobe takes
> care of FXG 2.0 instead of us?
FXG has nothing to do with Flash. Flash has no idea how to process FXG.
The Flex compiler converts FXG into Flash assets. It can also convert SVG
into a bitmap or something. I'm not sure what Adobe gains by continuing to
spend resources on FXG support at this time. If you can show there would be
a significant upside, I will try to bring that case to the right people in
Adobe.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui